多 Agent 系统失败根因：规范设计而非模型

Every team that gets burned by a multi-agent system tells the same story. The demo worked. Five agents, clean roles — researcher, planner, coder, reviewer, summarizer — and on the happy path it looked like the future. Then it hit real inputs and started producing confident nonsense, looping, or silently dropping half the task. The instinct is to blame the model and wait for the next checkpoint.

That instinct is wrong, and there's now enough evidence to say so precisely.

The failures are upstream of the model

The most useful thing published on this is the MAST work (Cemri et al.), which hand-annotated more than 1,600 execution traces across seven popular multi-agent frameworks and sorted what went wrong into 14 failure modes. Six annotators, Cohen's kappa of 0.88 — this is a real labeling study, not a vibes post.

The distribution is the interesting part:

• Specification and system design — ~41.8%. Task misinterpretation, ambiguous role definitions, bad decomposition, two agents with overlapping mandates, no termination condition.
• Inter-agent misalignment — ~36.9%. Context lost at handoff, format mismatches, agents contradicting each other, conversation that drifts off-task.
• Task verification and termination — ~21.3%. Ending early, verifying incompletely, or verifying incorrectly.

Read that again. Roughly four in five failures happen before and between model calls. The reasoning step — the part everyone benchmarks — is not where these systems break. They break in the seams: the spec that was never written down, the handoff that assumed context it didn't receive, the verification step that checked whether output existed rather than whether it was right.

This also explains the deployment numbers people keep quoting. A large majority of multi-agent pilots never reach stable production, and Gartner expects a big share of agentic projects to be cancelled by 2027. If the dominant failure mode were model capability, those projects would be getting rescued by every frontier release. They aren't. Four frontier models shipped in the first week of September alone; nobody's stuck pilot un-stuck itself.

Error amplification is the mechanism

Single-agent systems fail linearly. You get a bad output, you see it, you fix it.

Multi-agent systems fail multiplicatively. Agent B treats Agent A's output as ground truth. Agent C treats B's as ground truth. A 5% error at step one is not 5% at step five — it's compounded, and worse, it's laundered. By the time it reaches the final agent it arrives as clean, confident, well-formatted prose with no uncertainty markers attached, because each hop stripped the hedging and rewrote it as fact.

Reported amplification factors for uncoordinated topologies run as high as ~17× versus roughly 4.4× when there's a centralized validation bottleneck. Treat the exact multipliers as directional rather than gospel — they're topology- and task-dependent — but the direction is not in dispute and matches what anyone who has debugged one of these systems has felt.

The practical consequence: every handoff needs to carry confidence and provenance, or your architecture is a rumor mill. If Agent A can't say "I'm 60% sure, here's the source," Agent B has no way to be appropriately skeptical.

What actually fixes this

None of this is exotic. It's mostly discipline that the software industry already has and the AI industry skipped.

1. Write the process spec before the prompt

Most agent "role definitions" are a sentence in a system prompt. That is not a specification. A specification says: what triggers this agent, what it receives, what it must produce, what schema, what it is explicitly not responsible for, what it does when input is malformed, and what condition means it's done.

The best model for this isn't an AI paper — it's an SOP. Business process outsourcing has spent thirty years learning that when you hand work between teams, ambiguity in the handoff spec is where quality dies, and the fix is a written procedure with explicit exception handling. That knowledge transfers directly: agent orchestration is process design with a stochastic worker. This is the frame we use at SyncSoft.AI when clients bring us workflow automation and digital operations problems — map the process, name the exceptions, define the handoff contract, then decide which steps an agent should own.

2. Make handoffs typed and lossy-by-design

Free-text handoffs between agents are the single highest-yield thing to fix. Use structured payloads: the claim, the confidence, the source, the open questions. Force the sending agent to declare what it did not verify. A schema mismatch caught at the boundary is a caught bug; a schema mismatch smoothed over by an LLM's helpfulness is a silent one.

3. Verification needs a ground truth, not another agent

The 21.3% verification bucket is the one teams handle worst. The standard pattern is to add a "critic" agent — but a critic without a reference is just a second opinion from the same distribution, and it will happily approve confidently-wrong work. Real verification needs either a deterministic check (does the code compile, does the number reconcile, does the citation exist) or a human-labeled reference set for the cases where no deterministic check exists.

This is where model evaluation and QA work stops being optional overhead. You need a corpus of your workflow's traces, scored by someone who knows the domain, that tells you what a correct handoff looks like — otherwise you cannot distinguish "the system worked" from "the system produced output."

4. Start centralized. Decentralize only when you've measured a reason to

The mesh topology where every agent talks to every agent looks elegant in a diagram and is where amplification lives. A supervisor with a validation gate is boring, contains blast radius, and is far easier to debug. Earn the mesh.

5. Don't multi-agent things that aren't actually parallel

A large share of production multi-agent systems are a sequential pipeline wearing a costume. If the steps run in strict order and share all context, you have added handoff failure modes, latency, and token cost in exchange for an architecture diagram. One agent with good tools frequently beats five agents with good vibes.

The uncomfortable part: you need trace data

Here's what makes this genuinely hard rather than just neglected. To fix specification and coordination failures, you have to see them, and they're invisible in the places teams look.

Your observability stack shows you spans, latency, token counts, and errors. It does not show you that Agent B silently dropped the third constraint from Agent A's brief, because that isn't an error — every call returned 200. Every span is green. The system just quietly did the wrong thing.

The only way to find these is to read traces — actual end-to-end executions — and have someone competent annotate where the reasoning or the handoff went off the rails. That's exactly what the MAST authors did, and it's why their paper is more useful than a hundred framework benchmarks. The method is the contribution: label your failures before you theorize about them.

Most teams won't do this because it's slow and unglamorous. It's also the highest-ROI work available. A hundred carefully annotated failing traces from your own system will tell you more about what to fix than any leaderboard, and they double as the seed for trajectory correction and preference data if you later want to fine-tune the orchestration behavior rather than prompt around it.

Multi-agent systems are an organizational design problem that happens to be implemented in Python. The failure distribution says so: roughly 79% of what goes wrong is specification, decomposition, handoff, and verification — the same things that go wrong when you hand a project between two human teams without a written brief.

The good news is that this is fixable with tools you already have and skills your senior engineers already possess. The bad news is that it's process work, and process work doesn't demo well.

Before you upgrade the model again, go read ten of your own failing traces end to end. I'd bet money you find the bug in the brief, not the brain.

I work at SyncSoft.AI, where we help AI teams build the annotation, evaluation, and human-feedback datasets behind systems like these. If you're wrestling with agent trace evaluation or workflow decomposition, happy to compare notes — get in touch or just reply here.