Why most multi-agent systems fail before they ship (and it's not the model)

The pitch for multi-agent systems is intuitive: one agent researches, one agent writes, one agent checks the work, and a fourth one coordinates. Split up the way a real team would split up the same task, and you should get better results than one model trying to do everything in a single pass. Sometimes that's true. Often, what you actually get is four agents that are each individually competent, wired together in a way that fails in ways none of them would fail alone.

The most common failure we see isn't a bad model call. It's what researchers cataloguing these systems have started calling the handoff loop: agent A hands a task to B, B decides it needs something from C, C hands it back to A, and nobody in the loop actually owns getting the task to a finished state. Each agent is reasoning correctly about its own narrow slice. None of them has visibility into the fact that the task has now been "in progress" for six hops and zero net progress. It doesn't crash — crashes are easy to spot. It just quietly burns tokens and time while looking, from the outside, like work is happening.

A close cousin is what you could call false agreement: two or three agents converge on an answer because converging satisfies whatever objective they're each individually optimizing for, not because the answer is actually correct. In a document-review pipeline we looked at, a summarizer agent and a fact-checking agent "agreed" on a number that was wrong in the source document, because the fact-checker's job was to confirm the summarizer's claim matched a number somewhere in the context, and a wrong number happened to be present. Agreement isn't the same thing as correctness, and a system optimizing for two agents to stop disagreeing will happily converge on the wrong answer just to end the conversation.

Two more failure modes round out the list worth knowing before you design one of these systems. Context fragmentation happens when each agent only sees its own slice of the conversation and none of them has the full picture — a customer mentions a constraint to agent A that turns out to matter to a decision agent C makes three hops later, and because that context never got passed along, C makes a locally reasonable choice that's wrong given information it never had access to. And cost explosion is exactly what it sounds like: a five-agent pipeline that reprocesses shared context at every hop can burn five to ten times the tokens of the single-agent equivalent, for a task that didn't get five to ten times better, and this rarely gets caught until a bill arrives that doesn't match the value delivered.

The pattern underneath all four of these is the same: reliability breaks at the handoff, not inside any single agent's reasoning. That's a structural problem, and it needs a structural fix, not a better prompt for the agent that's misbehaving. What actually holds up in production is having exactly one agent — or one deterministic piece of orchestration code, not another LLM call — own the decision about when a task is actually done, with a hard limit on how many times work can bounce between agents before it gets escalated to a person instead of looping again.

None of this means multi-agent architectures are always wrong. They earn their complexity in a specific situation: when different steps in a workflow genuinely benefit from different tools, different context, or different levels of oversight, and — this part matters — when the handoffs between them are few, well-defined, and owned by something deterministic rather than another round of LLM judgment. A pipeline where one agent drafts a document and a completely separate, rules-based validation step checks it against a fixed set of criteria before anything ships is a legitimate multi-agent-adjacent pattern, because the "second agent" isn't really reasoning — it's checking. What tends to fail is chaining several agents that are all doing open-ended reasoning and all expected to negotiate the result between themselves.

We once inherited a four-agent research-and-summarize pipeline — a query planner, a web-search agent, a synthesis agent, and a final QA agent — that was taking upward of ninety seconds and regularly producing summaries that quietly dropped a source the synthesis step should have included. Collapsing it into a single agent with three well-scoped tools (search, fetch, and a deterministic citation-count check that didn't involve another model call) cut latency by more than half and eliminated the dropped-source problem entirely, because there was no longer a handoff for a source to get lost across. The output quality didn't drop. It was never actually the four-agent split doing the work — it was one agent doing the reasoning regardless, just with three extra opportunities to lose the thread along the way.

If you do need more than one agent, the one piece of infrastructure worth building before anything else is a hop counter with a hard ceiling — a task that's bounced between agents more than two or three times gets pulled out and handed to a person automatically, not left to keep looping in the hope it resolves itself. It's a small piece of deterministic code sitting outside any individual agent's reasoning, and it's usually the single change that turns an occasionally-runaway multi-agent system into one that fails safely and visibly instead of failing expensively and quietly.

Our own rule, after building a handful of these systems, is to default to fewer agents than the architecture diagram suggests you need. Every additional agent is another handoff, and every handoff is another place false agreement or an infinite loop can form. Before adding a second agent to a system, we ask what's actually failing about the single-agent version — usually it's context, not capability, and the fix from context engineering solves it more reliably than splitting the work across agents that now have to coordinate with each other on top of doing the work itself.

It's worth being honest that this diagnosis cuts against a lot of the current enthusiasm for agent swarms and elaborate multi-agent frameworks, several of which are explicitly built around the assumption that more agents, coordinating more elaborately, is the way forward. Some of that enthusiasm is warranted for genuinely parallel work — running the same research task across several independent agents and picking the best result is a different, much safer pattern than sequential handoffs, because there's no coordination for a false agreement or a loop to form in. The failure modes here are specifically about sequential, coordinating architectures where agents depend on each other's output and have to negotiate a shared understanding of a task. That's the pattern worth being skeptical of by default, not multi-agent systems in general.