What a tool means here
First the term. In an AI agent, a tool is an outside capability that does what the model cannot do on its own — search the web, read a file, query a database, send mail.
The standard way to attach them now is MCP (Model Context Protocol). Adding a few lines of server config gets you more tools, so the effort of attaching is close to zero. Which is why they keep accumulating.
But attaching a tool is not only lengthening a list. Every attached tool's name, description and argument schema gets read by the model every time. Twenty tools means starting each conversation with twenty manuals already laid out in front.
And the model has to pick one from that list every time. When there is more to pick from, the choice wobbles — the same way it does for people.
The line — four or five, or one or two
The number appears twice in the talk with different values. The slide puts the line at four or five tools; the speaker said one or two out loud.
Either way the direction is the same. Past that line, reasoning quality drops and tool selection gets unstable. "Unstable" here does not mean errors — it means picking a different tool for the same request each time, or picking the wrong one, more often.
You do not need to memorise the number. In practical form it becomes: "are only the tools this agent will actually use in this conversation still attached?" If half of them never get used, you are already past the line.
The carpenter analogy — why splitting wins
The analogy in the talk is exact. You hire a carpenter, and he shows up carrying plumbing tools, carpentry tools and electrical tools, announcing that he can do anything.
You probably do not want that person. You wanted a proper carpenter. Being able to do anything is not the same as being particularly good at one thing.
So the prescription is: do not grow the tool belt, split the agent. Make each one do a single thing and hand it only the one or two tools that job needs. It is the old functional-programming rule that a function should do one thing, carried straight over.
There is a version of this for people who do not write code. When you build custom GPTs or projects, do not put every role into one — make a separate one for research, for drafting, and for review. Same idea.
What comes free — keeping subagent context out of the main one
Splitting agents brings one benefit along with it: the intermediate work each agent accumulates does not flow back into the main conversation.
This matters because context is tokens and tokens are money. But there is a more important reason: the more context there is, the more confused the model gets and the less accurate the answer.
So a subagent receives only what it needs to solve its task, and returns only the result. The process stays inside.
The critic agent — built to verify, and given less
This was the most striking code in the talk. A critic agent, built to check earlier work, receives exactly two things: the claim and the evidence.
The reasoning that produced the claim is deliberately withheld. Giving less to the party you assigned verification to looks backwards at first.
The reason is groupthink. Gather several agents and let them talk to each other and they converge on one idea. The speaker's analogy: at a party everyone wants pizza except you, and rather than spoil it you go along. Agents behave the same way.
Show the verifier the path by which the earlier agent reached its conclusion, and the verifier walks that path and arrives at the same conclusion. That is not verification, it is endorsement. So you hand over only the conclusion and the evidence and ask it to judge afresh.
It is the same logic as not handing the original author's conclusion notes to a cross-reviewer in a human organisation.
One thing to try today
Open the agent, custom GPT or MCP setup you are using and count the tools attached.
Past five, odds are half of them have not been used once in the last month. Detach that half and ask for the same work. The accuracy of tool selection changes noticeably.
If detaching feels wasteful, do not delete — move them to another agent. Search and web reading go to the research agent; file read and write go to the drafting agent.
Next up is the fourth anti-pattern: where things go quietly wrong when you take the answer without looking at why the model stopped.