Multi-agent LLM systems keep failing in production. A Berkeley taxonomy shows it is rarely the model.

The demo works. Production does not.

A three-agent pipeline that plans, executes, and reviews looks great in a fifteen-minute walkthrough. Wire the same architecture into a real workload, with retries, edge cases, and a full day of traffic, and it starts missing steps, looping, or quietly shipping wrong answers with total confidence. Anyone who has shipped multi-agent LLM systems in front of real users has watched this happen.

The size of the gap is hard to pin down precisely, because every vendor and every team defines "failure" differently. But the practitioner reports and production audits published through 2026 keep landing in a similar range: something like four in ten multi-agent runs fail by some meaningful measure, and in less forgiving task domains that figure climbs past eight in ten. The exact number moves depending on who is counting. The direction does not: multi-agent systems fail far more often once they leave the demo.

Most demos run two or three agents for a handful of minutes, on a task chosen because it shows the architecture off cleanly. Production adds agents as scope grows, runs sessions for hours instead of minutes, and throws inputs at the system that were never part of the demo script. Every one of those changes gives more surface area for something to go wrong.

What is more useful than the number is knowing why. In 2025, a team of researchers largely out of UC Berkeley set out to answer exactly that, and the paper they produced, "Why Do Multi-Agent LLM Systems Fail?", gives the first systematic answer instead of another list of anecdotes.

What the MAST taxonomy measured in multi-agent LLM systems

The researchers, led by Mert Cemri and co-authors, did not start from a hunch about what breaks. They collected execution traces from real multi-agent LLM systems running coding, maths, and general agent tasks, across seven popular open-source frameworks, using a mix of models including GPT-4, Claude 3, Qwen2.5, and CodeLlama. A hundred and fifty of those traces were annotated in depth by six trained reviewers, and the group reached an inter-annotator agreement (Cohen’s kappa) of 0.88. That is high enough to say the categories they built reflect something real, not one researcher’s opinion. The resulting taxonomy, MAST, was then checked against a much larger set: more than 1,600 annotated traces across the same seven frameworks.

The output is fourteen distinct failure modes. Grouped, they collapse into three categories: system design issues, inter-agent misalignment, and task verification failures. None of the three is "the model produced a wrong answer." That is the detail worth sitting with: the taxonomy that best explains why multi-agent LLM systems fail in production has almost nothing to do with how capable the underlying model is.

Category one: system design issues

The first bucket covers decisions made before a single agent runs a single step: how roles are scoped, how tools are assigned, how state gets handed between agents, and whether there is any limit on how long a chain can run before something forces a stop. A demo with three fixed roles and a five-step happy path never exercises these decisions hard enough to expose the gaps. Production does, because production sends a request that does not fit the roles you designed, or a tool call that returns something malformed, or a task that technically finishes after forty API calls instead of four.

The pattern shows up as agents doing the wrong kind of work: an agent scoped to search and summarise quietly starts making decisions it was never designed to make, because nobody drew a hard boundary, and the model, faced with ambiguity, fills the gap itself.

A concrete version: a research agent scoped to "search the web and produce a summary" gets a query that also implies a judgement call, such as which of two conflicting sources to trust. Nothing in its role definition says whose job that is. In a demo, the query is chosen so this never comes up. In production, it comes up on day one, and the agent either guesses silently or spins up a sub-task nobody asked it to create.

Category two: inter-agent misalignment and the infinite handoff loop

This is the category that shows up most often in practitioner write-ups of MAST-style failures, and it has a specific, almost comic shape. Agent A decides the task needs input from Agent B. Agent B decides it actually needs something from Agent C. Agent C, missing the context that made the request sensible in the first place, hands it back to Agent A. Nobody errors out. Nobody times out. The task just circulates.

It happens because cooperative agents, trained to be helpful and non-committal, default to deferring when they are uncertain rather than deciding and moving on. That is a reasonable individual behaviour and a disastrous group one: a system built from agents that each avoid owning a decision produces, collectively, a system where no decision gets made. Every handoff compounds a second problem too, because most frameworks summarise or truncate context between agents to manage token budgets. By the third or fourth hop, the receiving agent is often working from a thinner picture than the one that started the chain.

Category three: task verification failures

The third category is the quietest, and in a lot of production incidents the most expensive: the system decides it is done when it is not. Multi-agent pipelines routinely lack any check that is independent of the agent producing the answer. The reviewer agent, if there is one, was often given the same context and the same instructions as the agent it is reviewing, so it agrees for the same reasons the first agent was confident. That is not verification. That is the same opinion twice.

Compare it to code review. A pull request approved by its own author, using the author’s own test suite, is not reviewed, it is rubber-stamped. Most multi-agent architectures ship with exactly that structure and call it a review step.

This failure mode also costs more than the other two, because it is invisible by design. A handoff loop is visible: it burns tokens and time, and eventually someone notices the task never finished. A verification failure reports success. The log looks clean. The wrong output ships to whatever depends on it. Teams that instrument handoff counts but not verification agreement tend to catch category-two failures within days and category-three failures only after a customer or a downstream system flags the output, sometimes months later.

Why standard evals miss this

Most evaluation suites for agentic systems still score a single response against a reference answer, or check whether a short chain reaches the right final state within a handful of steps. That is exactly the range where the three MAST categories rarely fire: not enough steps for an infinite handoff to form, not enough ambiguity for a role boundary to get tested, not enough length for context to thin out between hops. A benchmark run daily on a fixed, five-step task will keep passing long after the same architecture has started looping in production on a slightly different, ten-step version of the same task.

The honest fix is not a better benchmark score. It is watching metrics that describe coordination itself: how many handoffs a task actually takes compared with how many it should take, how often a task returns to an agent that already touched it, and how often the system’s "done" signal disagrees with what a human reviewer would accept. None of those show up in an accuracy number, and all three showed up repeatedly in the traces MAST analysed.

The fix that is not a bigger model

The fixes that actually move the failure rate are structural, and none of them require a research budget.

Explicit ownership. Every handoff needs an agent, or a router, whose specific job is to decide whether the task is done, escalate, or move to the next step, rather than leaving that call to whichever agent happens to receive it next.

Handoff budgets. A hard cap on how many times a task can change hands before the system stops and asks for human input, the same way a circuit breaker stops a retry storm instead of letting it run forever.

Independent verification. A checking step that only sees the producing agent’s output and the original requirement, not its reasoning trace, so it cannot inherit the same blind spot.

Per-hop logging. Enough of a trace on every handoff that a failure can be diagnosed from the log, instead of re-running the whole pipeline and hoping it fails the same way twice.

class HandoffLimitExceeded(Exception):
    pass


class HandoffGuard:
    """Wraps agent-to-agent routing with an explicit owner and a hard cap."""

    def __init__(self, max_handoffs=6):
        self.max_handoffs = max_handoffs
        self.count = 0

    def route(self, task, next_owner):
        self.count += 1
        if self.count > self.max_handoffs:
            raise HandoffLimitExceeded(
                f"task {task.id} exceeded {self.max_handoffs} handoffs; "
                "escalating to human review instead of looping again"
            )
        task.owner = next_owner
        task.log_hop(owner=next_owner, hop=self.count)
        return task

What to check before calling it "working"

None of these four fixes need to land at once. Per-hop logging is the cheapest, and the one to add first, because it is the only way to find out which of the three categories is actually causing a given failure instead of guessing. Handoff budgets and explicit ownership come next, since they stop the most visible symptom: tasks that never finish. Independent verification is the most expensive to build properly, and the one worth adding last, once logging shows how often the system’s own "done" signal disagrees with a human check.

None of this is an argument against multi-agent architectures. It is an argument against treating a demo’s happy path as evidence that the coordination layer works. The gap between a working demo and a working production system was never really about the model. It is about who owns the decision to stop.