Law 16 · Scope & Design
Narrow Beats General
Three sharp tools beat thirty dull ones.
The principle
A scoped agent with a handful of well-chosen tools outperforms a generalist drowning in options. Every extra tool is another way to choose wrong, another branch to test, another failure to debug. Capability surface is liability surface — breadth you don't need is just risk you took on.
Why it happens
Every tool added to an agent enlarges the decision space it must reason over on each turn, and because tool choice is a selection problem the model performs from descriptions in context, more options means more confusable near-duplicates and more ways to pick wrong. Controlled experiments on tool overload show this is not a gentle slope but a cliff: in one study, models were near-perfect at around 10 tools, still strong at 20, and collapsed at roughly 100, where task success fell apart. The mechanism is twofold: the long list of definitions consumes context budget and dilutes attention, and semantically overlapping tools blur together so the model cannot distinguish them. That is why, when selection gets unreliable, removing tools usually beats writing longer instructions to nag the model into choosing better.
Watch for
- The agent calls a plausible-but-wrong tool, like web search when a local query tool was the right one.
- Several tools have overlapping descriptions and the model confuses them.
- Your first fix for bad tool selection is a longer system prompt rather than fewer tools.
In practice
You hand your agent 28 tools so it can handle anything, and it starts calling search_web when it should call query_orders, then mixes up three nearly identical lookup tools. Every tool you added was another wrong branch it could take. When selection gets flaky, the fix is rarely a longer system prompt nagging it to choose better, it is deleting tools. Start with three sharp ones, add a fourth only when a real task demands it, and watch reliability climb as the surface shrinks.
Apply it
- Start with a minimal set of sharply distinct tools and add one only when a real task demands it.
- When selection gets unreliable, remove or merge overlapping tools before rewriting instructions.
- Keep each tool's purpose non-overlapping so the model never has to disambiguate near-duplicates.
The takeaway
Start narrow. Add a tool only when a real task demands it, not because it might be handy someday. When selection gets unreliable, the first move is usually fewer tools, not better instructions.