Everybody wants a swarm. Almost nobody needs one.
I sit in the forward deployed seat, which means I show up after the demo has been sold and before the pager starts going off. And the pattern I see most often is this: a team had a single agent that worked, then split it into a planner, a researcher, a writer, and a critic because that felt more serious. They bought an org-chart metaphor. They paid for it in latency, failure surface, and debugging nights.
That is the coordination tax. You pay it on every request, whether or not the task ever asked for a committee.
The number that ends the argument
Here is the finding worth taping to your monitor. Google Research’s agent scaling study found multi-agent coordination delivers +81% improvement on parallelizable tasks but causes up to 70% degradation on sequential ones. Read that twice. Same technique, opposite outcomes, and the deciding variable is not model quality or prompt craft. It is the shape of the work.
The guide puts it plainly: task structure is the deciding factor for architecture choice, and single-agent workflows fit most coding tasks because code changes are usually sequential and stateful. Most real business workflows are exactly that. Stateful. Ordered. One thing depends on the last. When you fan that out to a swarm, you are not parallelizing, you are introducing handoffs where none existed and praying the context survives the trip.
And it usually does not. On agentic tasks with real interaction depth, coordination overhead does not stay flat. It compounds. On genuinely agentic benchmarks, coordination overhead scales with interaction depth, agents operate on increasingly divergent world states, and errors cascade rather than cancel. That last phrase is the whole ballgame. In a single agent, a mistake is a mistake. In a swarm, a mistake becomes the input to three other agents who confidently build on it.
What you are actually buying
Splitting a working agent buys you three new problems on day one.
Latency. Every agent is at least one more model call, often several, plus the round-trips to coordinate them. A four-agent essay grader is a clean example: the multi-agent system requires four LLM calls per essay, increasing API costs and latency by 4x. For a 4% relative accuracy bump. That is not an architecture decision, that is a tax you volunteered to pay.
Failure surface. One agent has one place to break. A swarm has N agents plus the orchestrator plus the message bus plus every serialization boundary between them. More moving parts, more nulls, more timeouts, more retries that fire mid-conversation.
Debuggability. This is the one that hurts in production. With a single agent you read a call stack. With a swarm you are reconstructing a conversation from logs, trying to figure out which agent poisoned the well and when. The research community has a polite way of saying this: while multi-agent systems are powerful in solving difficult problems in complex environments, the communication and interaction between agents remain one of the challenges compared to single agent systems.
When the tax is worth paying
I am not anti multi-agent. I am anti architecture cosplay. The tax is worth it under specific, testable conditions, and Microsoft’s own guidance is refreshingly blunt about this. Multi-agent architectures provide value only when parallelization delivers measurable performance gains, and coordination overhead can negate concurrency benefits in many scenarios, making single agents more efficient.
Notice the word measurable. Not plausible. Not elegant on a whiteboard. Measured, under load, against a single-agent baseline you actually built first. Begin with a single-agent prototype to establish baseline capabilities, and transition to a multi-agent architecture only when testing reveals limitations that cannot be resolved through single-agent optimization.
The strongest signal is genuine independence. Multi-agent systems outperform single agents only on tasks that are genuinely parallel, multi-role, or larger than one context window; on most standard business workflows, a single agent is faster, cheaper, and considerably easier to debug and govern. Parallel research fan-out across independent sources. Work that genuinely exceeds one context window. Distinct expert roles that must run at the same time, not just in sequence. Those pay off. A linear pipeline wearing a team costume does not.
Do not mistake role separation for a mandate. Do not assume role separation requires multiple agents; distinct roles such as planner, reviewer, executor might suggest multiple agents, but they do not automatically justify a multi-agent architecture. A single agent can wear four hats without four bills.
Here is the CODN framing I hand every team. The Cost of Doing Nothing is real: ship no agent and competitors eat your workflow. But there is a Cost of Doing Too Much, and it is quieter and more expensive. A swarm that hallucinates in four voices instead of one is not a moat. It is a bigger incident with a nicer diagram.
Ship one agent. Make it excellent. Earn the second only when the numbers, not the metaphor, demand it. The teams that win the next cycle will not be the ones with the most agents. They will be the ones who knew which agents to never build.