Tools Are the Agent's Hands
An agent can only do what its tools let it do. The design of those tools — how many, how clear, how safe — drives reliability more than the model does. Teams that pile on tools to seem powerful usually build something flakier.
A tool is a specific action you allow the agent to take: look up an order, send an email, run a query. Two instincts fail here. The first is more is better — give the agent forty tools so it "can do anything." In practice, overlapping and confusingly-named tools make the agent pick the wrong one, and every extra tool is extra surface for mistakes. The second is ignoring error messages — a tool that fails with a cryptic error leaves the agent stuck, while one that fails with a clear, actionable message ("not found: check the ID") lets it recover.
You don't design tools yourself, but you can ask the right questions: are there a few sharp tools or a sprawling pile? Are dangerous actions separated from safe ones? When a tool fails, does the agent get something it can act on? Good tool design is quiet and boring, and it's where a lot of reliability is won or lost.
The forty-tool proposal
An engineer proudly reports the agent now has access to 40 tools — "it can do almost anything." Completion, oddly, went down. What's likely happening, and what do you suggest?
More tools gave the agent more ways to pick the wrong one. Overlapping, similarly-named tools confuse it, so it calls the wrong action or passes bad arguments — reliability drops even as capability rises. Suggest curating down to a small set of sharp, non-overlapping tools with clear descriptions and good error messages, and separating anything destructive. Ask, "how many of these overlap, and can we merge or cut them?" Counterintuitively, fewer, cleaner tools usually raise completion — it's tool design, not tool count, that matters.
Fjord: forty tools, mostly wrong ones
Fjord equipped its agent with 41 tools, many overlapping — three ways to search, three to send a message. The theory was maximum capability; the reality was an agent that constantly chose the wrong tool or passed malformed arguments. About 30% of its failures traced directly to tool confusion rather than any reasoning problem — a self-inflicted wound from the toolbox itself.
They cut to 8 clearly-named, non-overlapping tools, each with a tight description and actionable error messages, and separated the destructive ones. Wrong-tool errors fell by more than half and completion rose — with no change to the model. The leadership takeaway: when someone proposes adding tools "so it can do more," the reliability question is whether each new tool is sharp and distinct, because a sprawling toolbox makes the agent worse, not better.
Tessera gives its agent five sharp tools — look up a request, check inventory, grant standard access, update the ticket, escalate — rather than exposing its whole internal toolkit. The one destructive action (revoking access) is kept separate and, later, gated. Small and clear beats big and powerful.
Quiz · Chapter 4
- What drives an agent's reliability most is:
- Giving an agent 40 overlapping tools tends to:
- A tool that fails should return:
- "The more tools, the better" is: