Adding more agents does not automatically add more capability. Without structure, it adds more ways to fail, more cost, and more confusion. Orchestration is the difference.
TL;DR
- Multiple specialized agents can outperform one generalist — when coordinated.
- Without structure, multi-agent systems get expensive, slow, and chaotic.
- Clear roles, a coordinator, and well-defined hand-offs are what make it work.
- Start with one agent; add more only when a real boundary justifies it.
Why more than one agent
A single agent holding the whole task in one context eventually strains: the context fills, responsibilities blur, and it juggles concerns it cannot all attend to at once. Splitting into specialists — a planner, a coder, a reviewer, a researcher — lets each focus, keeps each context lean, and mirrors how human teams divide labor.
The catch: coordination is not free, and done badly it costs more than it returns.
The failure modes
Multi-agent systems go wrong in predictable ways:
- Telephone game. Information degrades as it passes between agents, each summarizing the last.
- Cost explosion. Every agent is model calls; a chatty swarm burns tokens fast.
- Diffuse responsibility. When five agents touch a task, no one owns the outcome and errors slip through the gaps.
- Coordination overhead exceeding the work. Sometimes orchestrating five agents is slower than one agent just doing it.
More agents is not more intelligence. Five confused agents are worse than one focused one.
Patterns that work
- Coordinator / worker. One orchestrator decomposes the task, delegates to specialists, and integrates results. Clear ownership, clear flow.
- Sequential pipeline. Agents in a line, each transforming the output of the last — good when the task has natural stages (research → draft → review).
- Clear role boundaries. Each agent has one job and the minimum context and tools for it. Overlap breeds confusion.
- Structured hand-offs. Define exactly what passes between agents — a schema, not a vibe — so information does not degrade in transit.
┌─ Researcher ─┐
Coordinator ┼─ Implementer ┼─▶ integrate ─▶ result
└─ Reviewer ───┘
When NOT to go multi-agent
The honest default: start with one agent. Reach for multiple only when there is a genuine boundary that justifies the coordination cost:
- Distinct skills that benefit from distinct context (researching vs. coding vs. reviewing).
- Work that parallelizes cleanly into independent sub-tasks.
- A context-window pressure that splitting genuinely relieves.
If you cannot name the boundary, you do not need another agent — you need a better single one.
The takeaway
Multi-agent systems are an architecture, not a magic upgrade. The wins come from the same things that make human teams work: clear roles, a coordinator, and disciplined hand-offs. Add agents deliberately, give each a real job and a fence around it, and keep one source of accountability for the result. Otherwise you have not built a team — you have built a committee, and paid by the token for it.