Why Fewer Tools Make a Better AI Agent

Give an AI agent ten tools and you usually get worse output, not more capability. Every tool you add is another place the model can pick wrong, pass bad arguments, or silently do the wrong thing while still returning a confident-sounding answer. The agents that actually work in production tend to run on two to five tools, each scoped to one job.

This isn't a theoretical preference. It shows up constantly in how well-built agents get described: a script that reads GitHub issues and dependency manifests and finds real advisories without touching the code, or a scanner that classifies subdomains as wildcard-likely using nothing but DNS lookups. The common thread isn't clever prompting. It's that each agent has a small, fixed toolbox and never has to guess which of fifteen options to reach for.

The tool-count trap

When you're scoping an agentic build, the instinct is to be generous: give the agent a search tool, a database tool, a file tool, an email tool, a calendar tool, "just in case" it needs them. This feels safe. It isn't — and the two examples above show why each failure mode is concrete, not hypothetical:

• Selection accuracy drops. The dependency-manifest scanner works because it only ever chooses between "read a manifest" and "read an issue." Add a third option, say, a general web-search tool, and now the model has to decide on every run whether the advisory it needs is in the repo or out on the web, and it will guess wrong often enough to matter.
• Argument errors compound. The DNS-based subdomain classifier takes one input: a hostname. That's the whole schema. The moment you bolt on a second tool with its own parameters, you've doubled the surface area for a malformed call, and on a write action the cost of that malformed call is no longer "wrong DNS answer" but "wrong record submitted."
• Failures go quiet. Both of those tools are read-only, so a wrong pick just produces a wrong classification you can spot in the output. An agent wired with a write tool alongside them can misuse it, log success, and move on, and nobody notices until a customer complains.
• Cost creeps up. Every tool definition rides along in the context window on every call, whether the manifest scanner ever touches its second or third tool or not. A bloated tool list is a bloated prompt on every single turn.

Anthropic's own guidance on agent design makes the same point from the build side: the most reliable agentic systems are composed of simple, well-tested components, not a single agent juggling every capability at once (see Anthropic's engineering write-up on building effective agents). Simplicity isn't a starting point you graduate out of. It's the thing that keeps working at scale.

What narrow scope looks like in practice

We run our own outbound engine this way. It scrapes a prospect's site, extracts the handful of facts that matter, and drafts one tailored email, all in a single focused call rather than a multi-step chain with a search tool, a CRM tool, and a drafting tool stitched together. Fewer moving parts meant fewer places for the process to quietly go wrong, and it was cheaper to run per lead. The lesson generalized past outreach: the fewer tools an agent needs to reach for, the easier it is to know exactly what it did and why. That's a different question from whether to use a single LLM call or an agent chain for a given task, but the same instinct applies at the tool layer: don't hand the model options it doesn't need.

How to audit your agent's tool list

If you're evaluating a build (in-house or from an agency), ask to see the tool list before you ask about the model or the prompt. A few checks:

• Can you name the one job this agent does? Our outbound engine passes this test in one sentence: it turns a prospect's site into one drafted email. If the answer for someone else's agent takes a paragraph instead, it's probably two agents wearing one trench coat.
• Does every tool get used on a normal run, or are some "just in case"? The scrape-extract-draft call has no unused tool sitting idle in the schema. Unused tools are pure downside: cost and confusion with no benefit.
• Are any two tools easy to confuse from their names and descriptions alone? If a human skimming the schema would hesitate, the model will too.
• What happens when the agent picks the wrong tool? If there's no logging that surfaces a wrong call, you won't find out until the customer does.
• Could this be two narrow agents with a router instead of one broad agent? Routing logic is boring and testable. A single model juggling twelve tools is neither.

When more tools genuinely make sense

None of this means every agent should be a single-tool script. Some jobs really do span multiple systems, a support agent that needs to look up an order, check a shipping carrier, and issue a refund is legitimately doing three things. The fix there usually isn't fewer tools on one agent, it's splitting the job across a workflow of smaller steps with explicit handoffs, rather than one model deciding among a dozen options on every turn. A deterministic workflow that calls three narrow agents in sequence is far easier to debug than one agent with nine tools trying to figure out the right order itself.

What to ask a vendor about this

If you're comparing agencies or in-house proposals for an agentic build, tool scope is a cheap, high-signal question to add to your vendor evaluation checklist. Ask them to walk through the tool list for the proposed agent and justify each one. A team that's thought this through will have a crisp answer for every tool. A team that hasn't will start explaining tools by describing scenarios, which is usually the sound of scope creep in real time.

Tool count is one of the few agent-design decisions you can sanity-check without reading a line of code, and it correlates strongly with how the whole system will behave once it's live and no one's watching it run.

If you're scoping an agentic build and want a second opinion on the tool list before you commit to it, let's talk.