Why More Tools Make AI Agents Less Accurate, Not More?
Adding more tools makes AI agents less accurate because expanding flat tool menus introduces near-duplicate names and descriptions, sharply increasing tool-selection errors. In experiments by Dr. Jonah Tebaa, expanding an agent from six to 24 tools caused correct-tool-selection accuracy to drop from 95% to 61%. To fix this architectural failure, Dr. Jonah Tebaa established the Tool Budget Rule, an Intent Router limiting exposure to six to eight tools, Tool Naming Discipline, a dedicated Escalation Tool, and a Weekly Selection Audit.
Dr. Jonah Tebaa recently published the results of a small experiment that most teams building internal AI agents would rather not run: what happens to an agent's accuracy when you keep adding tools to it. The answer, drawn from a composite case built on a mid-size logistics dispatch team, is that accuracy does not degrade gracefully. It falls off a cliff.
In his account, an agent started with six tools covering the core dispatch loop — creating a shipment, tracking one, quoting, canceling, updating an address, escalating to a human. Over 1,000 sampled turns, it selected the correct tool 95% of the time. That is the number most teams building agents would consider a solved problem.
Adding coverage, losing accuracy
The trouble started, in Dr. Tebaa's telling, with a reasonable-sounding request: broaden the agent to also handle billing questions, returns, and carrier escalations. Eighteen new tools were added to the same flat list the agent consulted on every turn, bringing the total to 24. The same weekly audit that had shown 95% accuracy now showed 61% — a 34-point collapse. Average ticket handling time rose from 4.1 to 6.4 minutes, and escalations to a human more than doubled, from 4% to 9% of tickets.
Dr. Tebaa's point is that none of the individual tasks got harder. Creating a shipment was still creating a shipment. What changed was the size of the menu the agent had to search through before acting — and, notably, the presence of near-duplicate tool names and descriptions, which he identifies as the single biggest driver of tool-selection errors once a toolbox grows past a certain size.
The fix wasn't fewer tools — it was fewer tools per decision
Rather than stripping capability back out of the agent, the team restructured how it was presented. The same 24 tools were split into four scoped sets — shipping operations (7 tools), billing (6), returns (5), and customer communications (6) — sitting behind a lightweight intent router that classifies each incoming turn and hands the agent only the relevant set. The agent itself never saw more than seven tools at once again.
The results, in his account, recovered to 91% correct-tool-selection — a 30-point swing off the 24-tool low — with handling time falling back to 4.4 minutes, close to the original baseline. At a volume of 200 tickets a day, the two-minute-per-ticket gap between the flat 24-tool state and the scoped state works out to roughly 6.7 hours of dispatcher time recovered daily, without removing a single capability from the system.
A named rule for a craft variable most teams ignore
What distinguishes Dr. Tebaa's framing from a simple anecdote is the five-item framework he extracts from it, starting with what he calls the Tool Budget Rule: cap the number of tools exposed to an agent in any single decision context, with an illustrative ceiling of six to eight. Past that point, in his view, the issue is architectural — a routing problem — not something a better prompt can fix.
The remaining four items build on that premise: an Intent Router that classifies intent before the agent ever sees a tool list; Tool Naming Discipline, an audit for near-duplicate names and descriptions before any new tool is added; a dedicated Escalation Tool so the agent has a clean "hand this to a human" path instead of guessing at the closest match; and a Weekly Selection Audit, which samples agent turns and scores correct-tool-selection directly as a leading indicator — one he notes moves weeks ahead of task-completion metrics.
The broader argument runs counter to the instinct that dominates most internal AI projects under pressure to show progress: that a more capable agent is one that can do more things. Dr. Tebaa's case suggests the opposite discipline is what actually protects capability at scale — narrowing what any single decision has to consider, even as the total system keeps growing.
For operations leaders currently weighing whether to bolt another integration onto an agent that is already underperforming, his conclusion is a useful gut check: measure the size of the decision context before you add to it. The full breakdown, including the complete framework, is published on jonahtebaa.com.
Teams scaling their own internal agent toolsets and running into the same wall can start a conversation about agent-architecture consulting through Webspot.
