Multi-agent systems fail along their communication edges
When a multi-agent system fails, our instinct is to blame an agent — the researcher hallucinated, the coder botched the diff. The failure taxonomies keep saying otherwise. Individual agents mostly do their jobs; systems break at the edges between them: handoffs that under-inform, state that quietly diverges, context that never crosses the boundary. The graph fails before the nodes do.
The evidence base here is MAST (Cemri et al., 2025), the first grounded taxonomy of multi-agent failure — 1,642 traces across 7 systems, annotated at κ=0.88 agreement, yielding 14 failure modes in 3 categories. Inter-agent misalignment alone accounts for roughly 32% of failures: misunderstood handoffs, ignored input, derailment, withheld information, conversations resetting mid-task. Add task-verification failures (~24%), which cluster at the aggregation edge where composed work gets accepted or rejected, and the majority of observed failure lives in the connective tissue, not the specialists. The follow-up mechanistic work makes the edge framing literal: the "Spark to Fire" propagation studies model error spread along the communication graph and find that in 5 of 6 popular frameworks, a single injected falsehood can cascade to 100% of agents — with topology, not agent quality, determining the amplification. Lineage-aware governance along those edges prevents 89%+ of cascades.
Edges fail in predictable ways
Three edge pathologies recur. Misunderstood handoffs: a specialist receives the task but not the constraints — context starvation — because the handoff carried a free-form chat summary instead of a schema. Divergent state: two agents each hold a stale belief about the world and act on it — race conditions, state bleed, the blackboard updated by one writer while another reasons from the old value. Lost context between hops: frameworks that collapse cross-team communication to the last message only, producing the game-of-telephone effect where each hop compresses away what the next agent needed. Cognition's "Don't Build Multi-Agents" essay is really an argument about exactly this: actions carry implicit decisions, and edges that don't transmit those decisions produce agents that confidently contradict each other.
The engineering response follows directly: treat topology as a first-class design variable and edges as contracts. Topology first, because the shape sets the failure surface — a chain topology has maximum blast radius per error, a peer mesh pays quadratic context duplication, hub-and-spoke concentrates both bottleneck and audit trail in one node. The selection heuristics are workload-shaped: high decomposability maps to star or tree; write-heavy work wants linear flow with shared context; verification-dominated tasks need explicit critique edges. Then contract every edge that survives: structured handoff schemas instead of prose, input filters that trim and type what crosses, filesystem artifacts passed by reference so nothing gets summarized into oblivion, versioned writes on shared state, and verification gates placed spectrally — at the hub nodes where cascades concentrate — rather than uniformly. Notice that none of this is "make the agents smarter." It's protocol design, the same discipline distributed systems learned when they discovered the network was the failure domain — and it starts with designing the boundaries deliberately.
The honest caveat: edges aren't the whole ledger. MAST's single most prevalent failure mode — step repetition, at 15.7% — is intra-agent, and its system-design category (~44%) includes plain specification failures no handoff contract will fix. Some systems genuinely do fail because one agent was not up to its job. But the intra-agent modes are the ones model improvements steadily erode; the edge modes are structural, and they're yours. Adding a sixth agent is a topology decision wearing a hiring costume. Before you make it, ask what new edges it creates, what crosses them, and who verifies the crossing — because that, not the agent count, is what you'll be debugging.