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 beats a generalist drowning in options. Every extra tool is another way to choose wrong, another branch to test, another failure to debug. More capability surface means more liability surface, so breadth you don't need is just risk you signed up for.
Why it happens
Tool use is a selection problem over text descriptions. Every extra tool adds another branch, another description to read, and another possible wrong choice. Tool-overload experiments show the threshold moves by model and task, but the pattern is stable: small, distinct toolsets work better than large overlapping menus. The failure is not only context length. Similar tools blur together, so the model picks the plausible one instead of the right one. When selection gets flaky, remove or merge tools before adding more instructions.
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 needs it, not because it might come in handy someday. When tool selection gets flaky, the fix is usually fewer tools, not better instructions.