Why chaining agents degrades reliability — compounding error, lossy handoffs, unattributable failure — and the four cases where the split genuinely earns its complexity.
- If each agent is 90% reliable, three in sequence are not 90% reliable.
- It does not earn it when the split is job titles, and job titles are what most frameworks encourage.
A "multi-agent" setup means splitting a job across several AIs that pass work to each other — one researches, one writes, one checks.
It looks efficient. The problem is that each handover loses a little, and the losses stack. Three AIs that are each right 9 times in 10 are, together, right closer to 7 times in 10.
Multi-agent setups are the most demonstrated and least reliable pattern in production. Both halves of that sentence are true, and the useful question is when the trade is worth it.
Why it degrades
Errors compound across handoffs
If each agent is 90% reliable, three in sequence are not 90% reliable. They are roughly 73% — and that is before the handoffs themselves introduce loss.
The arithmetic is unforgiving in a way a demo never shows, because a demo runs once and succeeds.
Each handoff is a lossy summary
Agent A passes agent B a summary of what it did, not what it saw. The nuance that mattered is exactly what gets compressed out, because summarising means deciding what is unimportant — and A does not know what B needs.
Failures become unattributable
A single agent that fails leaves one trace. Five agents leave five, plus the handoffs between them, and the wrong answer may have originated three steps upstream of where it became visible. See diagnosing a run — it is harder in exact proportion to the number of agents.
Job titles are not capability
Calling one agent "researcher" and another "editor" changes the tone of their output and nothing about what they can do. The role names are a convenience for you, not a capability boundary.
When it genuinely helps
- Genuinely parallel work — twenty independent items processed at once. No handoffs, so no compounding.
- A real permission boundary — one agent reads production, another writes to staging, and the split is enforced rather than described. That is a permission tier, not a persona.
- Different tools, not different personalities — one has web access, one has the database. The separation is capability, so it means something.
- Adversarial review — one produces, one checks against a fixed rubric. This works because checking is genuinely easier than generating, roughly by a factor of two.Kalai, Nachum, Vempala & Zhang, OpenAI, Sep 2025 (arXiv 2509.04664) — a formal bound, not an empirical measurement
The test before you build one
Could one agent do this with a longer brief? If yes, use one agent and a longer brief.
Multi-agent earns its complexity when the split is parallelism, permissions, or tools. It does not earn it when the split is job titles, and job titles are what most frameworks encourage.