You need fewer agents than you think
Most multi-agent systems take one problem, split it into parts, and hand the coordination to a model at runtime. The glue is where reliability and cost go to die.
A multi-agent demo is easy to fall for. A planner hands off to a researcher, which hands off to a writer, which a critic reviews, and the whole thing narrates itself as it goes. It reads like a team working. But adding agents did not add capability. It took one task, cut it into pieces, and handed the job of putting the pieces back together to a language model at runtime. Most of the time, that is a step backwards dressed up as sophistication.
The glue is where it breaks
When you split a task across agents, the interesting failures stop being inside the agents and start living between them. Every handoff is a place where context gets dropped, summarized lossily, or misread. Every agent owns its own control flow, so the nondeterminism you already worry about with one model does not add across five — it multiplies.
One agent that is occasionally wrong is something you can catch and correct. Five agents in a chain, each passing its mistakes downstream as if they were facts, produce failures no single component is responsible for and no stack trace explains. "They misunderstood each other" is not a line you can grep for.
More cost, more surface, less insight
A swarm is also more expensive to run and harder to trust. Each agent is another prompt to maintain, another way to fail, another surface you have to evaluate and keep evaluating as models change. You end up debugging conversations between components instead of function calls with defined inputs and outputs.
For anyone shipping this under a fixed-price contract, that is a margin problem before it is a technical one: the coordination overhead is real work, and it is the kind of work that does not show up in the demo and does show up in the bill. More autonomous parts also mean more to log and supervise if the system falls under rules that ask for exactly that.
When multi-agent actually earns its place
None of this means multi-agent is never right. It earns its place when subtasks are genuinely independent and can run in parallel, so coordination is a fan-out and fan-in rather than a fragile relay. It earns its place when parts of the work need different tools, different permissions, or different trust boundaries — a component that can touch production separated by design from one that only drafts text.
Those are real architectural reasons. "It felt more agentic" is not one. Most problems that get reached for a swarm are better served by one capable agent with good tools and a fixed workflow around it: cheaper, testable, and possible to reason about after the fact.
Before you split a task across several agents, answer one question honestly: what does the extra agent buy you that a plain tool call wouldn't?