Multi-agent architecture is the default answer to problems that do not need it. Adding agents feels like adding capability, but the first thing it actually adds is coordination cost: state to synchronize, handoffs that can drop context, and failure modes that only show up when two agents disagree about what already happened. Most systems that call themselves multi-agent are one agent doing real work and several other processes waiting for permission to speak.
Coordination cost is not a rounding error
Every agent you add multiplies the number of handoffs, and each handoff is a place where context degrades or gets misread. A two-agent system has one handoff. A five-agent system, if they all need to check in with each other, has up to ten. Each of those is a place where agent B acts on a stale or incomplete summary of what agent A actually did, not what agent A intended. The failure does not look like a crash. It looks like an agent confidently doing the wrong thing based on correct-sounding but outdated information.
This cost is fixed regardless of task difficulty. A trivial task split across three agents pays the full coordination tax for no capability gain. That tax scales with the number of edges in the communication graph, not the number of nodes, which is why teams underestimate it — they count agents, not connections.
The actual argument for more than one agent
There is a real case for multiple agents, and it is narrower than most designs assume. It holds when subtasks require genuinely different context windows, different tool access, or isolation for safety — one agent should not have write access to production while another only reads. It does not hold just because a task has multiple steps. Steps are not agents. A single agent working through a checklist with good tool calls will usually outperform three agents negotiating who does which step, because negotiation is itself a task the system now has to get right, on top of the original task.
The tell is whether the subtasks need to run in parallel with independent judgment, or whether they just need to happen in order. Sequential steps with dependencies are a workflow, not a multi-agent system. If you can write the sequence down as a list, you have described a queue, and the fix is a single agent with that list and a state machine, not a second agent to hand it to. This is most of what actually ships — see the patterns in /workflows/ that hold up in production: one agent, a defined tool set, and a queue that survives restarts.
The one-agent-and-a-queue pattern
This is the design that keeps showing up under the multi-agent label without the label being accurate. A single agent pulls a task, does the work, writes the result, and pulls the next one. The queue holds state so the agent does not have to. There is no negotiation, no summary handed between two LLM contexts, no risk of agent B misreading agent A’s intent. When something fails, there is one place to look.
The queue is doing the coordination work that people assign to a second agent. It is dumber than a second agent, and that is the point — dumb infrastructure does not hallucinate, does not misread a handoff, and does not need its own error handling for miscommunication. If you need true parallelism, run several instances of the same agent against different queue items, with no cross-talk between them. That gets you throughput without paying for coordination you do not need.
What to check before adding an agent
Ask whether the bottleneck is reasoning capacity or sequencing. If a single agent is producing wrong answers because the task genuinely requires more judgment than one context window can hold at once, a second agent with different context might help. If the agent is producing correct answers slowly, or in the wrong order, that is a queue and orchestration problem, and a second agent will not fix it — it will add a handoff on top of the existing bottleneck.
The honest measurement here is task completion rate and time-to-completion before and after adding an agent, on the same task set. I don’t have a reliable published figure for how often multi-agent designs underperform single-agent equivalents in production, and I would not trust one if I saw it, because most teams do not run this comparison before committing to an architecture. If you are building this for a client or a product, run it yourself on a fixed benchmark before you ship the multi-agent version, and be willing to throw the second agent away if the numbers do not move.
If you want a second opinion on whether a specific design actually needs the agents it has, that is the kind of review we do in /services/ — usually the answer is fewer agents and a better queue.