How tools reach the model

Why it works this way

Every request to a model carries the description and argument schema of every tool the employee can use. That list only ever grew — each new feature added its own tools, and every unrelated turn paid for them. Before this change a single request carried around 21,000 tokens of tool definitions before the employee had a single Integration connected.

The cost was the smaller problem. The bigger one was that an employee doing a code review was handed the whole finance and mail surface too, and had to pick its way through tools that had nothing to do with the job.

The working set

Roughly twenty tools go out on every request — about 4,500 tokens. They are chosen by consequence, not by how often they are used:

• Coding tools — bash, read_file, write_file and the rest. Their arguments are large free-form strings, which survive better sent directly.
• Everything that writes — creating a Routine, a Project, a Todo, a journal entry. Models have a habit of saying they scheduled something without calling anything, and making the call harder than the sentence makes that worse.
• Browser tools, when the employee has the browser enabled.
• find_tools and call_tool — the door to everything else.

The catalogue

Everything else — mail, finance, Bases, Notes, Resources, charts, dashboards, workspace channels, handoffs, and every Integration tool — lives in the catalogue. The employee calls find_tools with what it is trying to do ("record a payment", "reply to that email", "read a spreadsheet") and gets back the matching tools with their exact arguments, then runs one.

Every search result also carries the complete list of catalogue tool names. So even when a search misses, the employee can see what exists — the difference between one extra step and a capability that has quietly vanished.

Skipping the search

Searching costs a round-trip, and a search can miss. If you already know which tools a procedure uses, say so: open a Skill, go to Settings → Tools, and pick them. Those tools are loaded up-front for any turn where that Skill applies, and the employee never searches for them.

This is the recommended fix if you ever find an employee saying it cannot do something it can. Declaring a tool does not grant access to it.

Reading the run log

Every run records how its catalogue was split, so you can tell "never used the tool" from "never saw the tool":

• [tools] 22 loaded, 89 in the catalogue behind find_tools — bases, mail, finance…
• When a Skill declared tools, they are named: [tools] 24 loaded (2 from Skills: send_invoice, record_payment), …

Turning it off

Set agent.toolDiscovery.enabled to false in App/config.ts and every tool is sent on every request again, exactly as before. Nothing else changes. The switch exists because a model that does not think to search is the one real risk this design carries, and an operator who hits it should not need to downgrade.

Older employees are unaffected in one specific way worth knowing: Skills written before this change often name grouped tools like mail or base_rows with an op argument. Those names still work and always will.