Multi-Agent Systems Are Failing in Production. Nobody Wants to Admit It.

The multi-agent demo is one of the most impressive things you can show someone right now.

Agents collaborating. One agent researching, another writing, another reviewing, another publishing. The orchestrator directing traffic. The whole system humming with what looks like coordinated intelligence.

The audience gasps. The funding rounds follow. The engineering teams go off to build it for real.

Six months later, the private conversations in the engineering communities sound nothing like the demo.

The coordination is not working the way the diagram suggested. The agents are stepping on each other. The orchestrator is making decisions that seemed logical in isolation and are catastrophic in sequence. The error handling in a multi-agent system is a combinatorial nightmare that nobody fully anticipated. The cost of running five agents on a task that one agent could handle with better prompting is producing invoices that make the CFO’s eyes widen.

The demo was real. The production system is something else.

The coordination problem the diagram hid

Every multi-agent architecture diagram looks clean.

Boxes with arrows. Agent A hands off to Agent B. Agent B produces output for Agent C. The orchestrator maintains state. The whole thing flows in a direction that produces the desired result.

What the diagram does not show is what happens when Agent A produces output that is ninety percent of what Agent B expected.

Not wrong. Ninety percent right. Close enough that Agent B proceeds. Close enough that Agent C accepts the handoff. Close enough that the error does not surface until the final output, where it has been amplified through three stages of processing into something significantly more wrong than the original ninety percent.

This is the failure mode that theory does not predict and production reveals immediately.

In a single-agent system, errors are local. The agent was wrong about something. The output reflects that wrongness. It is visible and correctable.

In a multi-agent system, errors compound. Each agent processes the accumulated output of the agents before it. Errors from early stages are inputs to later stages. The final output contains not one error but the product of every error in the chain.

The system got worse with more agents, not better.

The orchestrator that cannot orchestrate

The orchestrator agent is supposed to be the smart one.

It breaks the task down. It assigns work to the right agents. It monitors progress. It synthesises the results. It knows when to retry, when to escalate, when the work is done.

This is a reasonable description of what an orchestrator should do.

It is not a description of what current orchestrators reliably can do.

The task breakdown works when the task is well-defined. When the task is ambiguous, the breakdown reflects the orchestrator’s interpretation of the ambiguity, which may not match what the user intended. The specialised agents then work from that interpretation. The user gets a coherent response to the wrong question.

The monitoring works when agents produce well-structured outputs. When an agent produces an output that is technically valid but operationally wrong, the orchestrator often cannot detect it. It accepts the output and moves on. The problem is invisible until the user sees the final result.

The synthesis works when the component outputs fit together naturally. When they conflict, the orchestrator has to resolve the conflict. Current orchestrators do this inconsistently. Sometimes they flag it. Sometimes they choose one version silently. Sometimes they average the two in ways that satisfy neither.

The orchestrator is a model doing a job that models are not yet reliably good at.

The cost that nobody calculated

Multi-agent systems are significantly more expensive than single-agent systems. This is obvious in retrospect and consistently underestimated in planning.

Every agent in the pipeline runs model calls. Multiple model calls. The orchestrator call. The specialised agent calls. The verification calls. The retry calls when something does not look right.

A task that one well-prompted agent handles in two API calls becomes eight to fifteen API calls spread across multiple agents in a multi-agent system.

At frontier model prices, this difference is significant. At the scale of a real product with real users, it is often the difference between a feature that is economically viable and one that is not.

The teams that built multi-agent systems because the architecture seemed more powerful have mostly discovered this at billing time.

The architecture is more powerful for a specific class of problems. For the problems most production AI systems actually handle, it is more expensive and not more capable.

The debugging experience nobody described

When a single agent produces a wrong output, debugging is straightforward.

You look at the input. You look at the output. You identify where the reasoning went wrong. You adjust the prompt. You test again.

When a multi-agent system produces a wrong output, debugging is a different experience entirely.

Which agent introduced the error? The second one in the chain produced wrong output, but was that because its prompt was bad or because the first agent gave it bad input? If the first agent gave it bad input, was that because the first agent’s prompt was bad or because the orchestrator gave it a bad task description?

Every bug in a multi-agent system is potentially caused by any agent in the chain or by the orchestrator’s coordination decisions. The search space for root cause is proportional to the number of agents times the number of interactions between them.

The engineering teams that have been debugging multi-agent production systems for six months are not describing a pleasant experience.

They are describing a new category of debugging that requires new tools, new mental models, and a new relationship with probabilistic failure that traditional software engineering did not prepare them for.

What actually works

Here is what the honest post-mortems from teams that shipped multi-agent systems are converging on.

Multi-agent systems work for tasks that are genuinely parallelisable, where the subproblems are truly independent, where the outputs do not need to be reconciled into a single coherent whole, and where the cost of multiple agent calls is justified by the value of parallel processing.

Web research across multiple sources simultaneously. Running multiple independent evaluations on the same piece of work. Generating multiple creative variations in parallel for a human to select from.

These are the cases where the architecture matches the problem.

Multi-agent systems do not work reliably for tasks where the subproblems are sequential and dependent, where errors in early stages compound through later stages, and where the orchestration complexity exceeds the complexity of the underlying task.

Most production AI tasks are in the second category.

The teams that have figured this out have moved backward from multi-agent toward single-agent with better prompting, better context construction, and better error handling.

They are not going back because they gave up. They are going back because they measured the outcomes and the single-agent approach produced better results at lower cost.

The conference talk that created the expectation

The gap between the multi-agent demos at conferences and the reality of production multi-agent systems is not accidental.

Conference demos are constructed for the demo. The tasks are chosen because they showcase the architecture’s strengths. The error cases are not shown. The cost is not discussed. The debugging experience is not mentioned.

The audience leaves with an expectation that multi-agent systems are the obvious next step for any serious AI deployment.

The expectation drives investment. The investment drives engineering teams to build systems that match the expectation. The engineering teams discover that the expectation did not match the reality.

This cycle is running right now at dozens of companies simultaneously.

The teams in month one are building with excitement. The teams in month six are having hard conversations. The teams in month twelve are rewriting significant portions of what they built.

The conference talks will continue to show the month-one version.

The honest answer about when to use it

Multi-agent systems are not wrong. They are a powerful tool for a specific problem shape.

The honest answer about when to use them is simpler than the architecture diagrams suggest.

If the task can be broken into genuinely independent parts that can run in parallel and do not need to be reconciled, multi-agent is worth considering.

If the task is sequential, complex, and requires coherence across the entire output, a single well-designed agent with good prompting and good context will outperform a multi-agent system on most dimensions.

Cost. Reliability. Debuggability. Latency. Predictability of failure modes.

The teams shipping the best production AI systems right now are not the teams with the most impressive agent architectures.

They are the teams that asked the right question before designing the architecture.

What problem am I actually solving, and is this architecture the right one for that problem or the most impressive-sounding one?

The impressive-sounding architecture and the right architecture are the same thing less often than the conference schedule would suggest.

The production metrics are starting to prove it.