Single-agent systems fail in predictable ways. Multi-agent systems fail in ways that are harder to see coming — and almost always in the handoffs. Here's the failure map and the cheapest fixes for each mode.
There's a pattern in how teams approach multi-agent systems. They start with a single agent that does everything — one prompt, one context window, one set of tools. It works until the task gets complex enough that the agent starts losing the thread or hallucinating in the middle of long chains. So they split it up: one agent plans, another executes, a third checks the output. The system feels cleaner on paper. Then it goes to production and fails in ways the single-agent version never did.
This isn't a reason to avoid multi-agent systems — they're genuinely more capable for the right tasks. But the failure modes are different, and they're mostly invisible until real load hits. Understanding them before you build is cheaper than debugging them after.
In a single agent, failure happens inside one context: the model gets confused, loses track of the goal, or calls the wrong tool. You can see it in one trace. In a multi-agent system, the failures overwhelmingly happen at the boundaries — in what one agent passes to the next, and in what gets lost or corrupted in transit.
Handoff drift is the most common. Agent A completes its task and passes a result to Agent B. The result is technically correct but underspecified — Agent B makes reasonable assumptions to fill the gaps, and those assumptions compound across three more handoffs until the final output is confidently wrong in a way that's hard to trace back to any single step. Each agent did its job; the system failed.
The fix is treating handoffs like typed function calls, not like conversation. Every inter-agent message should have an explicit schema: what fields are required, what their types are, what "done" means. A structured output format enforced at each handoff eliminates most drift before it starts.
Conflicting world models is the second failure mode, and it's the one that produces the strangest bugs. Two agents operating on shared state can develop inconsistent beliefs about it — one agent's read happened before another's write, or two agents wrote to the same field at roughly the same time and one overwrote the other. The result is that the system proceeds on contradictory assumptions, neither agent aware of the conflict.
This is the distributed systems problem, applied to AI. The solution is also borrowed from distributed systems: define a single source of truth for shared state, build explicit locking or versioning for writes, and make agents read from that source rather than caching their own copy. It's more infrastructure than most teams want to build, which is why the memory layer from Issue 007 matters: a proper agent memory system handles state consistency as part of its job.
Cascading overconfidence is the subtlest failure mode and the one that's hardest to catch in testing. Agent A produces an output with a confidence score of 0.9. Agent B treats that as ground truth and builds on it. Agent C does the same. By the time an error in A's output surfaces, it's been load-bearing for three steps and fixing it requires unwinding the whole chain. Contrast this with a single agent, where a mistake in step 3 of 10 only affects steps 4–10 — recoverable. In a multi-agent system with tight coupling, an early mistake can invalidate the entire run.
The mitigation: build skepticism in at each layer. Agents downstream of another agent should treat their inputs as claims to verify, not facts to accept. This is particularly important for any agent handling final output — it should run a sanity check against the original task specification, not just the immediately prior agent's output.
Every functioning multi-agent system eventually grows an orchestration layer — something that decides which agent runs when, monitors progress, and handles failures. Most teams build this layer reactively, after something goes wrong. The teams that ship faster build it first, even in minimal form.
At minimum, an orchestrator should: log every inter-agent message with a timestamp and agent ID, detect when a sub-agent has stalled or failed and decide whether to retry or surface the failure, and maintain the canonical version of shared state. That's not a lot of code, but it's the difference between a multi-agent system that's debuggable and one that requires archaeology every time something goes wrong.
The good news: the failure modes above all produce observable signals. Handoff drift shows up as downstream agents working with incomplete schemas. World model conflicts produce write collisions in your state store. Cascading overconfidence shows up in traces as high-confidence outputs that contradict the original task. If you're logging the right things, you'll see these failures coming before they reach users.
What it is: LangSmith is LangChain's observability and evaluation platform. It traces every step of an LLM call or agent run — inputs, outputs, tool calls, latency, token counts — and presents them in a timeline view that makes multi-agent flows actually inspectable. You can tag runs, compare them side-by-side, annotate failures, and build eval datasets from real production traces.
Why it matters for multi-agent systems: The failure modes in today's issue are almost impossible to debug without cross-agent tracing. LangSmith gives you exactly that — a single trace view that shows what each agent sent, what it received, and how long each handoff took. When cascading overconfidence or handoff drift surfaces in production, you'll find the root cause in minutes instead of hours.
Best for: Any team that has moved past a single-agent prototype and into a pipeline with two or more agents. The free tier covers most early-stage usage; it's LangChain-native but also works with other frameworks via the SDK.
Liu et al., Tsinghua University, 2023
Most LLM benchmarks test knowledge. AgentBench tests something different: can the model actually complete multi-step tasks in environments that push back? The benchmark covers eight real-world task types — OS interaction, database queries, knowledge graph navigation, web browsing, card games, lateral thinking, house-holding tasks, and digital card games — and scores models on task completion rather than answer correctness.
The findings are sobering: performance drops dramatically on tasks requiring long chains of reasoning and tool use, and the gap between the best and worst models is far larger on agent tasks than on standard QA benchmarks. Models that look similar on MMLU look very different when they have to plan across ten steps and recover from errors mid-run.
Why it matters practically: Before committing to a specific model for your multi-agent system, check how it performs on AgentBench's task types that most resemble your use case. A model that's 5% better on a knowledge benchmark but 20% worse on sequential tool-use tasks is the wrong model for an agent pipeline, regardless of where it ranks on the leaderboard.
Give this your multi-agent setup and get back a typed handoff schema for each inter-agent boundary — the single highest-ROI fix for handoff drift.
You are a multi-agent systems architect. I will describe my agent pipeline and you will design a typed handoff schema for each inter-agent boundary. For each handoff, output: - A JSON schema with required fields, types, and a one-line description of each field - A "done" condition: the exact criteria Agent A must meet before handing off to Agent B - A "reject" condition: what Agent B should do if the handoff payload is missing required fields or fails a sanity check - One example of a valid payload and one example of a payload that should be rejected Keep schemas narrow — only include fields the receiving agent actually needs to do its job. Bloated schemas create their own coordination problems. My agent pipeline: [DESCRIBE YOUR AGENTS AND WHAT EACH ONE DOES] Primary task the pipeline handles: [DESCRIBE THE END-TO-END TASK] Current handoff format (if any): [PASTE OR DESCRIBE, OR WRITE "NONE"]
The output gives you a contract between every pair of agents in the system. Enforce it with structured outputs or a validation step at the top of each agent's run — an agent that rejects a bad handoff early is far cheaper than one that propagates a bad payload through three more steps.
New issue every weekday at 7am. Free forever.
No spam. Unsubscribe in one click.