Why narrow specialists beat one 30-tool agent

There's a rite of passage in building agents where you keep adding tools to one model. Search the CRM. Draft the email. Query the warehouse. Create the invoice. Read the transcripts. It feels like progress — every new tool is a new thing the agent can do. Then, somewhere north of a dozen tools, it quietly gets worse: it reaches for the wrong tool, chains them in odd orders, or freezes on a request a five-tool agent would have handled cleanly. You've met the 30-tool wall, and it's one of the most reliable ways to strand an agent in the pilot.

The instinct is to fix it with prompting — a longer system prompt explaining when to use what. That treats a structural problem as a wording problem. The real fix is architectural: stop building one generalist, and build a small team of narrow specialists instead.

Why more tools makes an agent dumber

Every tool you expose is more than a capability — it's another entry in the model's decision space on every single turn. Tools with overlapping purposes ("search_docs" vs "find_files" vs "lookup_record") force a judgement call the model makes probabilistically, and the odds of the right pick fall as the list grows. The tool descriptions crowd the context window. And the blast radius of a wrong choice widens with every tool that can write. More tools, more surface, more ways to be confidently wrong.

A generalist with thirty tools is mediocre at all of them. The same model, given one job and three tools, is an expert — because there's barely a wrong move to make.

The shape that ships: an orchestrator and specialists

Split the work. Each specialist owns one domain and carries a short, hand-picked tool-list — the CRM specialist gets CRM tools and nothing else; the document specialist reads and cites, but can't touch the ERP. An orchestrator holds the plan and delegates to whichever specialist fits the step, calling it as a tool over the open A2A protocol. No single model ever sees more than a handful of tools at once.

In code, a specialist is just a tool with a tiny surface. The orchestrator's "tools" are the specialists themselves — delegation, not a thirty-entry switchboard.

 // Each specialist is defined by a NARROW tool-list — the constraint is the // feature. The doc specialist literally cannot write to the ERP, because the // tool isn't in its registry. Least privilege by construction, not by prompt. var crmSpecialist = Specialist{ Name: "crm", Tools: []Tool{crmSearch, crmReadDeal, crmUpdateStage}, // 3, all CRM } var docSpecialist = Specialist{ Name: "docs", Tools: []Tool{docSearch, docCite}, // 2, read-only } // The orchestrator delegates; its "tools" are the specialists. It never holds // the union of everyone's tools — it holds a short menu of experts to call. func (o *Orchestrator) tools() []Tool { return []Tool{ delegateTo(crmSpecialist), delegateTo(docSpecialist), delegateTo(erpSpecialist), } } 

What you get back for the extra structure

• Better tool selection. A model choosing among three relevant tools is far more reliable than one choosing among thirty — the single biggest quality win.
• Auditability. A short, fixed tool-list per specialist is something a human can actually review and sign off. "What can the ERP agent do?" has a three-line answer.
• Least privilege. Scope and permissions attach to the specialist, so a compromise or a bad turn is contained to one domain — it lines up exactly with forwarded identity and per-tool validation.
• Testability & parallelism. Small agents are easy to evaluate in isolation, and independent specialists can run at once — the pattern behind a fan-out research agent that dispatches several sub-agents and merges their cited results.

The counterintuitive part

Constraining each agent makes the system more capable, not less. The whole can do anything on your list — it just never asks one model to be the expert on all of it at once. That's why "add another tool" is usually the wrong reflex and "add another specialist" is usually the right one — it's why the agents we build arrive as small teams rather than one all-purpose model, and it's one of the concrete decisions that separates an agent that reaches production from one that impresses in a demo and then quietly falls over on the messy real thing.