How an agent finds a tool
An agent on this platform can reach hundreds of governed tools. Handing a model all of them is not an option: the schemas alone would consume most of a context window before the work starts, and a model choosing from an undifferentiated list of several hundred verbs chooses badly.
The answer is an old one, borrowed from anyone who works with their hands.
A carpenter has a toolbelt for what the job needs, a toolbox to go back to, and a shed when the job turns out to need everything.
The three tiers
| Tier | What it is | How the agent reaches it |
|---|---|---|
| Belt | The advertised core: the schemas actually placed in the prompt | Already there. The agent calls them directly |
| Box | An addressable drawer: every tool in one family | A search scoped to a family, for example everything under catalog |
| Shed | The entire registry, always searchable | An unscoped search over every registered tool |
The agent always carries one reserved meta-tool, a tool search, which is what keeps the narrowed surface discoverable. It is never taken off the belt, so an agent whose belt does not contain what it needs is never stuck; it goes looking.
Instead of the full schema list, the prompt carries a capability manifest: the family names plus a handful of example verbs in each. The agent sees the shape of what exists, and fetches detail only for what it decides to use.
Narrowing is measured, not assumed
Progressive disclosure is not free. A search round-trip costs a turn, and below a certain size dumping every schema is genuinely cheaper than making the agent look things up.
So the system narrows only when one of two bounds is crossed:
- A tool-count bound, in the low tens of tools.
- A schema-size bound in bytes, because twenty verbose schemas can cost more context than eighty terse ones.
Below both, everything is advertised directly. The measurement is of the actual serialized schemas rather than a guess, so the decision tracks what the prompt really costs.
The belt widens as the agent works
Two mechanisms grow the advertised set during a session, both bounded.
Pin-on-use. A tool the agent found by searching joins its advertised set for the rest of the session, so a tool discovered once does not have to be rediscovered on the next turn. Pinning is capped by its own schema-byte budget, so a long session cannot silently refill the context it was narrowing to protect.
Declared tools, from the brief. A field manual bound to the working space can declare the tools a job is expected to need, and those are pre-loaded onto the belt when the session starts. It is a packing list: the agent walks in already holding what the work calls for.
The rule that makes all of this safe
This is the part that matters, and it is worth stating on its own.
Surface is not authority.
Pinning a tool, declaring it in a brief, or finding it in the shed changes what the agent can see. None of them changes what it is permitted to invoke.
Three consequences follow, each deliberate:
| Rule | What it prevents |
|---|---|
| Surface is not authority | Discovery cannot become escalation. A tool appearing on the belt is not a grant |
| Declared is not granted | The loaded set is the declaration intersected with the live grant. If a brief could widen authority, then publishing content, a pull operation, would become an authority-escalation path |
| The brief is a floor, not a ceiling | Everything the agent is permitted to do stays executable and findable through search, whether or not the brief mentioned it. A packing list does not shrink the toolbox |
A tool an agent is not permitted to call is refused at the call, by the same authorization path that governs every other action, whether or not the agent could see it.
One policy, both entry points
Tool tiering applies to chat turns and unattended runs alike: a crew step, a coding run, a scheduled agent job and a conversational turn all resolve their surface through the same policy.
That sounds obvious and was not always true. The policy originally lived in the chat wiring, which meant every unattended run, the majority of the work the platform does, executed against a full un-narrowed surface. Moving it to a shared location is why an agent's context budget now behaves the same way whether or not a human is watching.
The same policy is projected into the edge runtime through a generated cross-language fixture, with a test that fails if the two drift, so a device makes the same disclosure decisions as a cell.
Where the tools come from
The registry is the node's Model Context Protocol server. Registration is explicit and enumerated rather than magic:
- Tools are registered by family, in an enumerated list. There is no self-registration decorator, so nothing appears in the registry by accident.
- Boot fails loudly if a required family cannot load. A cell that came up missing a third of its tools would otherwise look healthy and behave mysteriously.
- Every tool name is
family.verb, and a name collision across families is a boot failure rather than a last-one-wins surprise. - Governance declarations are validated at registration time, not at first call. A tool declared consequential must supply the means to identify who it affects; an impact estimate must be within bounds; contradictory declarations are refused. A misdeclared tool never reaches a running cell.
External tools reached over an outbound Model Context Protocol connector are projected into the same skills catalog as everything else, so a remote tool is required by a team exactly the way a local one is. There is no second binding mechanism to learn or to govern separately.
Related topics
- The tool surface as a whole, and the Model Context Protocol server: Tools and MCP.
- What the families contain: Tool families.
- Where a brief comes from, and the admission loop around it: Studio.
- What happens at the moment of a call: Alignment.