Every tool definition loaded into an agent’s context costs something before the task even starts, whether or not it’s ever called. Deferred loading and a real per-task budget beat connecting everything by default.
I went through a phase of connecting every integration I could find to my coding agent’s configuration, on the theory that more capability sitting available could only help. Browser automation, half a dozen cloud provider integrations, a calendar, an email client, a handful of internal tools — all loaded, all available, all the time, regardless of what the actual task in front of the agent happened to be. It felt like the generous version of setup: why would I ever want to withhold a capability the agent might need. What I hadn’t accounted for was that every one of those tools costs something the moment the session starts, whether or not it is ever called.
A tool’s definition — its name, its description, its parameter schema — has to sit in the model’s context before the model can decide whether to use it, and that is true even for tools that never get invoked in a given session. A kitchen-sink configuration with two hundred tool definitions loaded is two hundred definitions’ worth of context spent before the actual task has been read, on the off chance any one of them turns out to be relevant. I noticed this first as a vague sense that sessions felt more sluggish and less sharp than they used to, and only later traced it to the fact that I had been quietly stacking tool connections for months without ever removing one, because removing a capability feels like a loss and adding one feels like progress.
The fix that actually worked was deferred loading: keep the full catalogue of available tools out of the model’s working context by default, and let it search for and load only the specific tools a given task needs, on demand. This inverts the trade-off. Instead of paying the context cost of every tool up front regardless of use, you pay a small cost — a search call — only for the tools a task actually turns out to need, and nothing at all for the hundred and ninety you never touch that session. The capability is still there, reachable in a couple of calls if the task genuinely requires it. It just is not sitting in context, unused, the whole time.
The deeper fix, underneath the loading mechanism, is being honest about which tools a given agent or task actually needs versus which ones I connected because they were available and connecting them was easy. A calendar integration on an agent that only ever touches code review is not free optionality, it is a standing tax on every session that agent runs, paid whether or not the calendar ever comes up. Treating tool access like a budget — this task gets these tools, and no others, chosen deliberately rather than inherited from a global "everything’s connected" configuration — does the same job load-time deferral does, but earlier, by never putting the unnecessary tool in the catalogue for that task in the first place.
The instinct that more available capability is strictly better comes from thinking about tools the way you would think about a toolbox sitting in a garage — no cost to owning a wrench you do not currently need. A model’s context does not work like a garage. Every tool sitting in it is more like a person standing in the room while you are trying to think, whether or not they ever say anything. Cut the room down to who is actually needed for the job at hand, and the ones who are still in it get heard more clearly. The kitchen-sink instinct optimises for a capability I might one day want; the budgeted one optimises for the task actually in front of the agent right now, which is the only task that ever gets done.