A Smaller Toolset Is a More Capable Agent

Most agents end up holding more tools than they use. Each one seemed reasonable to add at the time, and none of them seemed expensive to keep. The place this reasoning breaks is in what a tool actually is to the model. A tool is not an action the agent reaches for only when the moment calls for it. It is a description the model reads in full before it decides anything at all, on every turn, whether or not that turn ends up using it. The whole registered set sits in front of the model on each request, part of the same field of text as the user’s actual ask. A tool the agent never calls still occupies that field. Its cost is not paid when it fires. It is paid on every decision the agent makes, because the model has to read past it to reach the tools that matter.

Once that is clear, the whole calculus inverts. Adding a tool does not give an agent a new option at no cost to the options it already had. It taxes every routing decision, enlarges the surface the model has to reason across, and, if the new tool resembles one already present, quietly makes the agent’s behavior less predictable. Narrowing the toolset is therefore not a limitation you accept reluctantly. It is a design act that makes the agent faster, cheaper, easier to test, and more consistent in production. The goal is not the smallest possible toolset for its own sake. It is a toolset scoped so tightly to the agent’s job that the right call is almost always obvious.

The toolset is present on every turn, not summoned when needed

The overlooked cost is a context cost, and unlike most costs it never fluctuates. What the model sees on any given turn includes the full text of every tool it has been given, not the subset it is about to use. So the overhead does not scale with how many tools the agent actually reaches for. It scales with how many exist. An agent that leans on a handful of its tools in normal operation still carries the descriptions of all the rest, on every turn, as a standing charge against everything it does.

That charge lands in two places. The first is plain: descriptions are tokens, tokens are processed on every request, and processing them costs money and time. The descriptions for tools that never fire are pure waste on both counts. The second cost is the one that actually degrades quality, and it is easy to miss because nothing about it looks like an error. A context window is finite. Every token spent on a tool the agent will not use is a token unavailable to the material it needs for the job in front of it. Unused descriptions are not free padding the model skips past at no cost. They enlarge the space the model has to search, and a decision made across a larger and noisier field is a worse decision on average, even on the turns where the model still lands on the right tool. It simply had to work harder to get there.

This is why the first move in scoping is subtractive and almost mechanical. Look at what the agent actually calls in normal operation and remove what it does not. The tools that survive are the ones the role genuinely needs. Everything else was optionality you were paying for and not using, and paying for it was making the agent worse.

Overlap turns routing into a coin flip the model never admits to

The context cost is the visible half of the problem. The subtler and more dangerous half surfaces when two of the registered tools both look like reasonable answers to the same request. A model choosing between tools does not run them and compare results. It scores each available description against the incoming request and calls the one that scores highest, committing to that choice before it sees any output. When two descriptions sit close enough that either could win, the outcome turns on small differences in wording, and the model can land on one tool this turn and the other next turn, swayed by variations in phrasing that a person would read as the same request.

The result is behavior that is nondeterministic in exactly the way production systems cannot tolerate, and it is uniquely painful to chase down because it never announces itself as a failure. Nothing throws. Nothing logs an error. The same intent simply comes out one way on some runs and another way on others, and when you go back to inspect the input that caused the split, it looks identical to the input that behaved correctly. What a user experiences is an agent that mostly does the expected thing and occasionally does a subtly different one, with no visible reason for the difference. The two tools were near-twins, the model picked between them by a hair, and the hair moved.

The cause is almost always an overlap that should never have existed. Two tools went into the catalog whose scopes were never cleanly separated, and the model was handed a distinction to arbitrate that the designer never actually made. The repair happens at design time, and it takes one of two forms. If the two tools are really doing one job, collapse them into one. If they are really distinct, the boundary has to be written into their descriptions until it is unambiguous, with each one stating not only what it covers but what it explicitly leaves to the other. A description that lists only what a tool does forces the model to guess at the edges. A description that also fences off what the tool is not for eliminates the ambiguity at its source. This is why description quality is not documentation. It is the single change that most improves how reliably an agent routes, and the first place to look when one misroutes.

Let the mission decide the tools

The cleanest way to hold a toolset small is to give the agent one job and let that job dictate the tools. When an agent has a single, well-defined mission, the tools it needs follow from the mission almost mechanically, and anything that does not follow from the mission is a candidate for removal. This is the specialist pattern, and it is the practical form the whole argument takes: rather than one general agent holding every tool in the system, the work is decomposed into roles, and each role gets a palette scoped exactly to it.

A role built for retrieval carries only what it needs to locate and pull information; it has no reason to hold anything that writes. A role responsible for persisting changes is the mirror image, equipped to commit to storage and deliberately blind to search. A coordinating role holds almost none of the domain tools at all, since its work is to direct the roles that do. Each of these agents sees a set small enough that the model can nearly always pick out the one obvious candidate for any request within the role, which is exactly the condition under which routing stops generating surprises. The overlap problem needs no management because it never forms. One right tool is in view, and the model finds it.

The benefits compound past routing. A specialist with a narrow palette is testable in isolation, because its behavior is a function of a small, comprehensible set of tools rather than the full catalog. When something goes wrong, the surface to inspect is small and the responsible tool is usually obvious. And because roles are isolated, one agent’s implementation can be changed or replaced without disturbing the others, which is the kind of operational flexibility that matters more as the system grows and matters most when it is under load. Specialization is an investment. It costs a little more design effort up front to draw the role boundaries, and it pays that back in reliability and in the ability to reason about the system one piece at a time.

There is a context benefit here too, specific to coordinated systems. When each specialist sees only its own tools, the coordinating agent’s window is not polluted with the domain tools of everything beneath it. Isolation keeps every part of the system lean, not just the leaves. The alternative, a single agent holding every capability, forces the entire catalog into one context and reproduces the bloat and overlap problems at the worst possible scale, in the one agent responsible for the whole workflow.

Tools accumulate unless something removes them

Left alone, an agent’s toolset grows. Tools get added during early development because adding one is the fastest way to unblock whatever is in front of you, and they are rarely removed afterward, because removing a tool that is not obviously causing harm never feels urgent. The drift is silent. Each individual addition is defensible in the moment, and the accumulated result is an agent carrying a catalog assembled by circumstance rather than by design, most of it left over from problems that no longer exist.

Holding the line against that drift takes two habits. The first is a rule for what gets in: a tool earns its place by covering a need no existing tool covers, not by seeming useful in the abstract. Speculative tools, added because they might help someday, are the raw material of bloat, and someday rarely comes while the description keeps loading on every turn in the meantime. The second habit is a rule for what stays: the catalog is reviewed periodically against what the agent actually calls, and tools that no longer earn their slot are removed. Usage is the evidence. A tool that does not get called in normal operation is not providing the coverage it was added for; it is providing overhead. Treating the toolset as something that is curated rather than something that only accumulates is what keeps an agent lean over its lifetime rather than only on the day it was designed.

Some tools belong everywhere, and that is not bloat

The argument for lean palettes has a real exception, and naming it precisely is what keeps the principle from being applied as dogma. Some tools legitimately belong on many agents at once, and their presence there is not drift. What separates the two cases is intent. A cross-cutting tool is shared on purpose, because its concern reaches across roles rather than living inside any one of them, and the clearest case is anything that serves observability. If every agent in a system is expected to emit structured logs, the logging tool belongs on every agent, and registering it everywhere is intentional architecture, not accidental accumulation. The same holds for a shared status facility that a coordinator and its specialists all write to, so the progress of a workflow can be read from one place.

The line between a cross-cutting tool and bloat is not how many agents carry the tool. It is why they carry it. A logging tool is on every agent because logging is a concern that genuinely spans every role, and that is a decision someone made and can defend. A stray database tool is on a retrieval agent because it was added during a prototype and no one removed it, and no one can say what it is for. The first is scope correctly recognized as broad. The second is scope never drawn at all. When you audit a toolset, the tools that appear on many agents are not automatically suspect. The question to ask of each is whether its breadth was chosen or inherited.

Scope is decided at configuration time, not at call time

The thread running through all of this is that an agent’s toolset is not a runtime convenience the model draws on as needed. It is a fixed part of the agent’s context that shapes every decision the agent makes, and it is set long before any particular call, at the moment the agent is configured. That is what makes scoping a design property rather than a runtime one. You cannot fix an overloaded, overlapping toolset by prompting the model to choose more carefully, because the cost was already paid, in context consumed and in ambiguity introduced, before the model read a single word of the request.

So the toolset is something you shape on purpose rather than let assemble itself. A palette kept tight spends less context on every turn, leaves routing with usually one plausible answer instead of several, and keeps each agent small enough to reason about on its own. Match an agent’s tools to its mission, admit a new one only when a real need has no existing cover, retire the ones usage data shows are dead, hold each description precise enough that no two tools contend for the same request, and let a tool span agents only when its reach is deliberate and defensible. The counterintuitive part, that fewer tools tends to make an agent more capable, stops being counterintuitive once you remember that the tools it never calls are still there on every turn, still described, still contending, still charged for. Capability was never the size of the catalog an agent held. It was how reliably it reached for the right tool, and you engineer that by taking tools away.