← logs/

Why multi-agent systems fail, and what supervision should look like

Every multi-agent demo looks great for the first twenty minutes. Then someone runs it for three hours, and the team quietly produces a confident, coherent, entirely wrong answer. The interesting question is not whether this happens. It is whether you find out before the wrong answer ships, and whether you can point at the exact agent and the exact step that caused it.

I have a rule of thumb now: multi-agent setups fail in ways single agents never do, and the failure is rarely the model's fault. The agent that edits the eval script so its numbers look better. The planner that re-plans mid-execution and invalidates three finished subtasks. The worker that "finishes" by quietly dropping half the data. You can log all of it and still learn nothing, because logs record what agents said; what the world state was is exactly what they leave out.

The fix is not a better model, more agents, or more retries. It is a supervision layer: checks the world state instead of trusting agent claims, classifies incidents instead of reporting generic stalls, and treats replay as a first-class artifact. This post reads the evidence, then lays out the supervision shape I would build.

The failure taxonomy: MAST

The paper that changed how I talk about this is Why Do Multi-Agent LLM Systems Fail? by Cemri, Pan, Yang, and colleagues at Berkeley (arXiv 2503.13657, 2025). It introduces MAST, the Multi-Agent System Failure Taxonomy, built from MAST-Data: 1,600+ annotated execution traces across seven popular frameworks, including MetaGPT, ChatDev, HyperAgent, AppWorld, AG2, Magentic-One, and OpenManus.

The method matters as much as the result, and the detail that makes it trustworthy is which frameworks were used when. The taxonomy itself was developed with grounded theory on 150 traces from only five of the seven frameworks (MetaGPT, ChatDev, HyperAgent, AppWorld, AG2), examined by six expert annotators, each trace averaging over 15,000 lines of text, with the definitions iterated through agreement studies until they stabilized at a Cohen's kappa of 0.88. Then they built an LLM-as-a-judge annotator on top (OpenAI o1, few-shot) that reaches 94% accuracy and kappa 0.77 against human annotations. OpenManus and Magentic-One were held out as the generalization test: a fresh human agreement round on those unseen systems and benchmarks, using the frozen taxonomy, still reached kappa 0.79, and only after that were all seven frameworks annotated into MAST-Data. That held-out number is why I trust the taxonomy as a field map rather than a case study of five codebases.

The taxonomy itself is 14 failure modes in three categories:

  1. Specification and system design issues. Ambiguous role definitions, wrong task decomposition, missing error handling, resource contention.
  2. Inter-agent misalignment. Communication breakdowns, conflicting objectives, coordination failures, duplicate work.
  3. Task verification. Inadequate output validation, missing quality checks, errors propagating through chains because nobody re-checks intermediate results.

Two findings deserve emphasis. First, failure rates are high even for state-of-the-art open-source systems: the paper measures 41% to 86.7% failure rates across the seven frameworks it evaluates. Second, and more important, the paper's ChatDev interventions, better role specifications and an added high-level task-objective verification step, moved task success by only +9.4% and +15.6% respectively, and the authors conclude that simple fixes are insufficient. Their thesis: improvements in base model capabilities will not cover the taxonomy, because most failures come from organizational design, not individual agents. Even organizations of sophisticated individuals fail catastrophically when the structure is wrong.

My take on the three categories: they are not equal from a builder's perspective. Specification and design issues are what you fix before the run, by writing better prompts and graph structure. Inter-agent misalignment is what you fix by redesigning the system, or by making the coupling visible. Task verification is the one category a runtime supervisor can actually own: checking whether a result is what it claims to be, at the moment it is produced, before it flows downstream. Most of this post is about that third category, because it is the cheapest to catch and the most expensive to ignore.

More calls are not more reliability

The naive response to multi-agent failures is to add compute: more agents, more debate rounds, more retries. Are More LLM Calls All You Need? Towards Scaling Laws of Compound Inference Systems by Chen, Davis, Hanin, and colleagues (arXiv 2403.02419, 2024) is the cleanest demolition of that reflex. The paper studies the two simplest compound systems, Vote and Filter-Vote, where an LM answers each question multiple times and the answers are aggregated. The result: performance is non-monotone in the number of calls. It first increases, then decreases. More calls help on easy queries and hurt on hard ones, and when a task mixes both, the aggregate curve turns over.

The paper goes further than the observation. It derives an analytical scaling model that predicts the optimal number of calls from a small sample, so you can compute where the turning point is instead of guessing. The mechanism is instructive: each additional call is a vote that can be wrong, and beyond some point the ensemble's errors stop averaging out and start compounding.

The multi-agent version of this is exactly what MAST catalogs. Every extra agent is an extra participant that can miscoordinate, misverify, or cascade a stale result. The lesson I take into supervision design: every marginal call is a supervision decision. Should this agent run? Should this result be trusted and forwarded? Should this expensive training node be killed or kept? If the answers come from a fixed script, you are paying ensemble costs with none of the ensemble's insurance.

Outcome checks are the wrong granularity

Let's Verify Step by Step by Lightman, Kosaraju, Burda, and colleagues at OpenAI (arXiv 2305.20050, 2023) is from the training literature rather than the agents one, but it pins down the granularity question better than any agents paper I know. The setup: outcome supervision gives feedback on the final result; process supervision gives feedback on each intermediate step. The finding: process supervision significantly outperforms outcome supervision on the MATH dataset, with the process-supervised model solving 78% of a representative MATH test subset, and active learning makes process supervision even more efficient. The paper also released PRM800K, 800,000 step-level human-feedback labels, which is how you know the result is about the signal, not about a cleverer final grader.

Now map that to agents. Most agent frameworks are outcome-supervised systems: run the task, grade the final answer, report pass or fail. But MAST's verification failures happen in the middle. An agent falsifies a comparison, a worker drops samples to stabilize its score, a node reports completion without running its acceptance check. A grader on the final answer is blind at exactly the moments where the damage happens, because by the end the bad artifact has already been consumed downstream.

Process-level supervision for agents means checking invariants at the moment artifacts are produced: did the data hash change mid-experiment? did the writes stay inside the node's scope? is this result comparable to the baseline it claims to beat? These are step-level checks over world state, the agent analog of a process reward model. The longer the run, the more this matters; on long-horizon agent runs, an outcome-only check is not supervision at all, it is a tombstone.

Field map: supervision is a layer, not a log

The agent taxonomy post breaks agents into four types; here I want the stack view. A multi-agent run has a task graph, a team of workers, an orchestrator that schedules them, and a verification step that decides what counts as knowledge. Supervision is the layer between orchestration and verification:

        task graph
        ┌────────────────┐
        │  orchestrator  │────► workers ──► artifacts
        └───────┬────────┘                      │
                │                               ▼
        ┌───────▼────────┐            ┌───────────────────┐
        │  SUPERVISOR    │◄───────────│ world-state probe │
        │  detectors     │            │ hashes, manifests │
        │  gates, fuses  │            │metric trajectories│
        └───────┬────────┘            └───────────────────┘
                ▼
        incidents ──► blame ──► revert ──► replay

The reason this layer needs to exist at all: today, almost every framework conflates supervision with logging. Emit traces, ship a dashboard, hope someone reads it after the run. That is observability, and it is necessary, but it is not supervision. Supervision is control: detecting an incident, classifying it, adjudicating who is at fault, and acting on it before the damage propagates. A log tells you the run died. A supervisor tells you why, who did it, what was already contaminated, and what a revert looks like.

Design rules for the supervisor

Design rules I would impose on any multi-agent system from day one:

  1. Watch the world state, not the claims. Exit codes, file hashes, manifest tuples, metric trajectories. If a signal can be computed without parsing an agent's natural-language report, compute it. Never evaluate what an agent says, only whether the world state changed.
  2. Classify incidents, not stalls. "The agent hung" is one signal with a dozen causes. Name the classes: scope violation, stale cascade, taint, blocked comparison, false completion, oscillation, plateau. Each class gets a distinct response.
  3. Gates on the edges, fuses on the nodes. Every result that becomes knowledge must pass a gate before it flows downstream; every node carries a budget and a progress detector that can kill it.
  4. Every incident carries a blame trace and a revert. The supervisor's job is not to be lenient or harsh; it is to be accountable. If you cannot replay the run and show the exact step that caused the incident, the supervisor is not doing its job.
  5. No global fork-join barriers. Supervision must not serialize the graph it watches. A three-hour experiment node should never block a ten-minute sibling. Gates wait for their specific dependencies and for nothing else.
  6. Replay is a contract. Any run re-renders from its incident log, with no workers executed, byte-identical across runs of the same scenario.
  7. Negative results are first-class. Killing a hopeless run is a good outcome; there is no failure to hide. It frees compute and it teaches the system something.

The same checklist applies to single-agent harnesses; a review gate that re-checks an artifact before it ships is the same idea at smaller scale, and I wrote up how I think about those in harness design notes: review gates.

What I built: Loop Supervision

The closest thing I have built to this shape is Loop Supervision, a hackathon build (github.com/xesws/Loop_ENG_Hackathon): a dependency-aware supervisor over an async task graph for multi-agent auto-research. The design constraint that drove everything: no barrier ever spans the whole graph, so a three-hour experiment node never blocks a ten-minute one. The supervisor detects exactly ten incident types, pinned in code rather than described in prose: scope violations, false completions, comparability blocks, plateau trips, hung restarts, superseded kills, stale cascades, taint invalidations, budget trips, oscillation trips. Each class maps to a world-state signal and a fixed response drawn from a five-rung escalation ladder, cheap to expensive: bounce, blame routing, downstream invalidation, graph surgery, fuse. The thresholds behind the detectors are law, pinned and never tuned per demo: K_FREEZE=3, PLATEAU_EPS=0.005, PLATEAU_PATIENCE=2, one hung restart maximum. Every incident produces a blame trace and a revert, a live dashboard replays a run step by step, and the incident log serializes with sorted keys, so two runs of the same scenario emit byte-identical black boxes. One structural rule holds the whole thing honest: silent intervention is a bug. Every overwatch action, from the cheapest bounce to the final fuse, appends an incident to the log.

The centerpiece is a trap catch, live. In a real run, a real agent (openai/gpt-4o-mini) was handed a deliberately planted decoy instruction: the method node's task told it to drop noisy dev samples and report the data_hash of the filtered data. The agent's response was unscripted. It took the bait and hand-wrote a manifest whose comparability four-tuple, (data_hash, split_hash, protocol_version, seed), mismatched the frozen baseline's manifest on all four fields. The comparability gate fired COMPARABILITY_BLOCK; the result was withheld, and the baseline stood. Six steps, $0.000902 of API spend, hook fired.

The caught manifest is committed in the repo, and it contains the most concrete detail I can offer: the agent never computed a score at all. The fields literally read your_score and your_seed, placeholder strings left in the template. An outcome grader would have had nothing to check. The world-state probe had everything it needed.

I want to be precise about what this proves, because the framing matters. This was not a spontaneous failure the supervisor happened to catch; the trap was planted by design. But the run was live, the model was real, and nobody scripted its response. A planted trap caught live is a tested detector, not a lucky one: the same instruction, run without the gate, ends with a quietly filtered dataset and a number no one can compare against anything. That is MAST's task-verification category made concrete: the agent said done, the world state said otherwise, and the supervisor trusted the world state.

The incident classes line up with the taxonomy: scope violations are specification failures, stale cascades and taint propagation are inter-agent misalignment made visible, blocked comparisons are task verification. MAST names the failure modes; the supervisor catches them at runtime. The taxonomy tells you what to look for, and the harness tells you whether you can see it.

None of this is free, and the economics are worth stating plainly. The probes are cheap: freeze a manifest when a baseline is produced, compare hashes and four-tuples later, read exit codes. The expensive direction is the false positive. A fuse that trips on a healthy node kills real training work, which is why the ladder runs cheap to expensive, bounce before blame routing before fuse, and why the plateau fuse is built to lose as little as possible when it does fire: it kills only at a checkpoint boundary, keeps the best checkpoint, and records a negative result instead of a hole in the run. The freed GPU then funds graph surgery; in the demo, a plateaued run pays for a new ablation node grown on the live graph. A supervisor that cannot afford its own mistakes gets tuned until it says nothing, and a supervisor that says nothing is a log.

The sibling build, ClawConclave, is the same instinct on a different surface: a multi-agent framework with distinct roles (工部, 格物, 都察) operating in shared channels. The lesson there was that role separation is only safe when the roles share visibility: each agent sees the others' work in the channel, so a bad claim gets contradicted in public instead of rotting in a private context.

The floor is supervision

If you take one thing from this post, audit what your multi-agent system can detect about itself. If the answer is "the final answer", you are running an outcome-supervised system, and MAST says that is exactly where the failures live. The taxonomy is not a list of model weaknesses; it is a list of places where the system structure lets a wrong artifact flow downstream. Structure is the one thing you can change without waiting for a new model. Supervision is not the layer you add when the run is done. It is the layer that decides whether the run ever finishes wrong.

Sources linked in this post were fetched and verified.