Multi-agent is an architecture tax. Pay it late.
A planner agent, a researcher agent and a writer agent look impressive in a demo. In production, each one is a new place for the system to fail.
The short version
5 things that decide this
- 01One agent with well-defined tools solves most business tasks. Add a second agent only when a measured bottleneck proves the first one cannot keep up.
- 02Every additional agent multiplies coordination paths, not capability. Two agents have one handoff to get wrong. Five agents have ten.
- 03Multi-agent failures compound silently: one agent's bad output becomes another agent's confident input, and nothing downstream questions it.
- 04Debugging a five-agent pipeline means reconstructing which agent said what to which other agent, in what order, before the wrong answer appeared.
- 05Split by task, not by title. A system needs two agents when it needs two different tool permissions or two different context windows, not because the org chart has a researcher and a writer.
Why multi-agent is the default answer
A multi-agent diagram is easy to sell. A planner agent breaks down the task. A researcher agent gathers information. A writer agent drafts the output. A reviewer agent checks it. Each box maps to a job title, so the diagram reads as an org chart, and org charts feel like how real work gets done.
The demo backs this up. Give each agent a narrow prompt and a small toolset, and it performs its slice well in isolation. Watching four agents pass a task between them, each one visibly doing its part, looks like specialization paying off.
What the demo does not show is the handoff. Every arrow between two boxes in that diagram is a place where one agent's output becomes another agent's input, unverified. In a five-minute demo run on a clean example, that handoff never fails. Run the same pipeline ten thousand times on real, messy input, and it does.
What each added agent actually costs
A single agent with three tools, search, database writes and email, has three failure points. Each tool call can fail, and the agent can call the wrong one. That is manageable. You can log every call and inspect every failure in one trace.
Split that agent into three, and the failure points do not stay at three. Each agent still has its own tool-call failures. On top of that, every one gains a handoff risk: the message it passes on can be incomplete, ambiguous or wrong, and nothing checks it by default. Coordination paths grow faster than agent count, the same way connections in a network grow faster than nodes.
The failure is also quieter. A single agent that misreads a tool result usually gives an obviously wrong final answer. Nothing sits between the mistake and the output to dress it up. A multi-agent pipeline can take a small error from the researcher agent and have the writer agent turn it into a fluent, confident paragraph. The mistake survives because nothing downstream is built to doubt it.
Observability gets harder in the same proportion. One agent means one trace to read when something breaks. Five agents means reconstructing which agent produced which message, in what order, before the wrong output appeared. Those five traces often live in separate logs with no shared timestamp format.
- 01Coordination paths grow faster than agent count.
- 02A bad handoff is invisible: the receiving agent has no reason to question it.
- 03Debugging time scales with the number of agents a failure could have passed through, not with the size of the mistake itself.
- One agent, three toolsOne trace. One place to look when it breaks.
- Split into three agentsThree traces, plus two handoffs neither agent checks.
- A bad handoffBecomes the next agent's confident input, not a flagged error.
- DebuggingNow means finding which agent, in which order, said what.
Nothing on this list appears in a demo run on a clean example. All of it shows up at production volume.
Start with one agent. Split only when it is measured
Build one agent, give it well-designed tools and a clear scope, and run it against real tasks before adding a second agent to anything. A single agent with good tool definitions handles more than most teams expect, because the limiting factor is usually tool quality, not agent count.
Split when you can point to a measured bottleneck, not a hunch. Two real reasons justify a second agent. First, the task needs two tool-permission sets that should never sit in the same context. Second, a single agent's context window is provably too small for the task, even after trimming. Both show up in logs. "This feels like it needs a planner and a writer" does not.
When a split is warranted, keep the handoff explicit and checkable. Define the exact shape of what one agent passes to the next, and validate it the same way you would validate a function's return type. An unchecked string passed between two agents is where the silent failure lives.
This order matters because reversing it is expensive. Collapsing a three-agent split back to one means undoing its prompts, logging and handoff format. Proving the split was necessary first costs far less.
Questions this raises
01Is multi-agent ever the right first design?
Rarely, and mostly on tasks that are already parallel, such as running several independent research queries and merging the results. Even there, a single agent with a fan-out tool often does the same job with one less coordination layer.
02What is the clearest sign a single agent has hit its limit?
Its context window stays too full for the task even after you cut what it does not need. Or it needs two tool-permission sets that should never be granted together for security reasons. Both show up in logs or a permissions review, not in a feeling that the prompt is getting long.
03Does more agents mean the system is more capable?
No. Agent count is not a capability metric. A single well-tooled agent often outperforms a multi-agent pipeline on the same task. Fewer handoffs means fewer chances to lose or distort information.
