One Agent or Many?
"Multi-agent system" sounds more sophisticated than "an agent," so teams reach for a team of agents by default. Usually that's a mistake — more agents means more coordination, more failure points, and harder debugging, for benefits a single well-built agent already delivers.
The pitch for multiple agents — a router, a researcher, a writer, a checker — is specialization. The hidden cost is that they must coordinate: pass context to each other (often garbling it), hand off at the right moment (often wrongly), and when something breaks, you now have several interacting loops to untangle instead of one. In practice, a single well-instrumented agent with the right tools handles most jobs more reliably and far more debuggably than a committee of them.
Multi-agent genuinely earns its place in narrow cases: when work splits into independent tracks that can run in parallel, or when parts need such different tools or context that one agent's "working memory" would overflow. Those are real but uncommon. The leadership instinct to cultivate: treat every extra agent like extra headcount — it has to justify its coordination cost with evidence, not vibes.
The committee of agents
A team proposes a five-agent system — router, researcher, writer, reviewer, supervisor — for a task a single agent currently does at 79% completion. What do you ask before approving the added complexity?
Ask: "what does the single agent fail at that five agents would fix, and is that failure about parallelism or context overflow — or just something we could fix in the one agent?" Multi-agent adds coordination cost, more failure points, and much harder debugging, so it needs to buy a real, measured improvement. If the honest answer is "it would feel more organized," that's not a reason. Start with the one agent, fix its actual weak spots, and only split when the work genuinely needs independent parallel tracks. Make them earn the complexity with numbers.
Chorus: five agents, one mess
Chorus built its customer-service system as five specialized agents because multi-agent was "more powerful." It was more fragile: agents passed garbled context to each other, the supervisor made confident wrong hand-offs, and debugging any failure meant untangling five interacting loops. Completion sat at 62%, and every incident took hours to trace.
They collapsed it to one well-instrumented agent with the same tools. Completion rose to 79%, cost dropped, and failures became debuggable because there was a single trajectory to read. The rule they adopted — and the one a leader should hold — is that multi-agent earns its keep only when work truly splits into parallel tracks or overflows one context; otherwise a single, measured, hardened agent wins. Sophistication isn't reliability.
Tessera is pitched a "triage agent plus resolution agent" design but starts with one agent and measures. It handles the whole request fine, so they keep it single-agent — simpler to run, cheaper, and far easier to debug when something goes wrong.
Quiz · Chapter 7
- The default choice should usually be:
- The hidden cost of multiple agents is:
- Multi-agent genuinely helps when:
- Extra agents should be treated like: