Article
Diagrams of AI systems have started to look like org charts: a planner agent, a researcher agent, a critic agent, a writer agent, all coordinated by an orchestrator agent. It is an appealing picture, and for most of the problems companies bring us, it is the wrong one. One agent with well-designed tools, clear stop conditions, and a good evaluation set beats five agents passing notes to each other, and it is a fraction of the cost to build and to run.
Why the org chart is tempting
Complex tasks do not fit in one context window, so it seems natural to split them across agents. Specialisation feels like it should improve quality. And a diagram with several boxes looks more like a product than a diagram with one.
Why it usually is not worth it
Every hand-off loses information. Agent A summarises what it found for agent B, and B works from the summary. Whatever A left out is gone. Most multi-agent failures we debug come down to one agent not knowing something another one knew.
Debugging gets much harder. A single agent's log is a list of steps. A multi-agent log is several interleaved lists, and the question "why did it do that" requires reconstructing what each one believed at the time.
Cost and latency multiply. Each agent re-reads its context. Five agents on a task means the task's context is paid for five times, plus the coordination traffic.
The coordinator becomes the problem. Orchestrators are agents too. Now the hardest part of the system is the one with the least specific job.
What to do instead
Give one agent better tools. Most of what people split into agents is better expressed as a tool the agent can call: "search the knowledge base" as a tool, not a librarian agent; "check this draft against the style guide" as a tool, not a critic agent. Tools are deterministic, testable, and cheap. Agents are none of those. A single agent with a dozen good tools handles remarkably complex tasks, and its harness stays simple.
Manage context deliberately. The window is finite, but it is large, and with summarisation and retrieval done well a single agent can carry a long task. We covered the techniques in context engineering.
When more than one agent is right
Two situations, in our experience.
Parallel, independent subtasks. Reviewing a codebase for bugs, performance, and accessibility at the same time: three agents, each with the whole codebase and one lens, whose findings are merged by code rather than by another agent. The subtasks share nothing during the work, so nothing is lost in hand-off.
Separation for safety. An agent that drafts and a separate, minimal checker that only validates against fixed rules, with different permissions, so the drafter can be creative and the checker cannot be talked around. Here the second agent exists for isolation, not for intelligence.
Both cases have a property in common: the agents do not converse. They run, and code combines the results. If your design has agents talking to each other in natural language, that is usually the point to redesign.
How we decide
Every agent engagement starts with one agent. We add a second only when the evaluation set shows a failure that tools and context cannot fix, and we can name the isolation or parallelism it buys. That has happened on a minority of projects. The rest shipped simpler, cheaper, and easier for the client's team to run, which was the point.