Failure Modes and Cascading Errors in Multi-Agent Systems

Multi-agent systems fail differently than single models do, because a mistake in one agent doesn't show up as an error — it shows up as input. Agent B has no way of knowing that what Agent A handed it was wrong; it just looks like data, and Agent B builds on top of it. Nothing in the chain distinguishes correct output from output that looks correct but isn't. Once you get that, the rest of this piece is just working out where that gap opens up, and what actually closes it.

The three structural categories where multi-agent failures originate

A 2025 study called MAST, presented at NeurIPS, went looking for where these gaps actually live. Researchers pulled hundreds of execution traces from seven popular multi-agent frameworks, including AutoGen, ChatDev, and CrewAI, and sorted the failures into 14 distinct modes. Those 14 modes fall into three buckets, and the split between them tells you exactly where to spend your attention.

Specification problems come first, and they're the biggest bucket by far at 41.77% of failures: role confusion, task definitions that leave too much open, missing constraints nobody thought to write down. Coordination failures come next at 36.94%, agents talking past each other, state that doesn't sync, objectives that quietly conflict. Verification gaps round it out at 21.30%, where nobody checked the output, or the check that existed wasn't strong enough to catch anything.

A fourth category exists that MAST didn't formally track but that shows up constantly in production: infrastructure failures, rate limits, context windows overflowing, timeouts cascading from one service to the next. These tend to trigger the other three categories rather than sit apart from them.

Most teams build their review step at the end of the chain, after output is produced, because that's where a mistake is easiest to see. Specification and coordination problems together, though, make up a large majority of all failures, and both happen before an agent ever produces output. They're baked in at design time, which means a check placed only at the finish line will miss them entirely, no matter how good that check is.

How a local error becomes a system-wide corruption

Picture a procurement agent that misroutes a request. The scheduling agent downstream doesn't know the input was wrong, so it builds a production plan on bad data. Then the logistics agent books transport for goods that were never actually going to exist. Three agents produce three correct-looking steps that add up to one broken outcome.

That's cascading context drift in miniature: Agent A passes along degraded context with full confidence, Agent B has no signal telling it something's off, and it treats the input as ground truth. The corrupted payload doesn't shrink as it travels — it grows.

Memory poisoning works on a slower clock. One node hallucinates something, and that bad data spreads through message-passing to every agent holding a piece of shared memory. No single agent did anything wrong on its own; the corruption lives in the collective state, not in any one node, which is what makes it hard to trace back. Degradation here is gradual, so by the time someone notices, the origin point is buried under several layers of downstream activity.

Echo chambers might be the strangest failure on this list, and arguably the scariest. Agents validate each other's wrong conclusions, back and forth, until the wrong answer starts to look like consensus, and the system's confidence goes up exactly when its accuracy goes down. That inversion, high confidence paired with a wrong answer, is the most dangerous shape a failure can take, because nothing internal is flagging a problem.

Plan forking looks like a merge conflict. Different agents modify a shared plan based on small differences in reasoning, and the plan branches into versions that don't fit back together. Nothing is watching for this the way version control would, so the fork doesn't get caught — it gets executed.

Resource exhaustion loops round out the list: one agent decides more data will help, so it eats up a disproportionate share of tokens or API calls, starving everything else downstream. That starvation triggers timeouts, and those timeouts produce their own separate errors, turning one greedy agent into several broken ones.

What ties all five together: local confidence stays high while the global picture falls apart, and nothing in the system's own signals says stop, something's wrong, until the damage has already spread across multiple agents.

Tool calls as the most common proximate trigger

Across 2024 and 2025 production deployments, tool misuse and bad tool arguments account for roughly 31% of agent failures. That's the single biggest proximate cause, ahead of context drift and ahead of hallucination cascades.

Tool calls are dangerous for a specific reason: a bad tool call still returns something structured and well-formatted, so it looks like a normal response. The error travels wearing the shape of valid data, and no agent downstream has any reason to question it unless someone specifically built that check in.

The Supabase and Cursor incident from mid-2025 shows how bad this gets. A privileged, service-role agent was processing support tickets, and it treated user-submitted text inside those tickets as commands rather than as plain data. Attackers embedded SQL instructions in a ticket, and the agent ran them, exfiltrating integration tokens straight into a public support thread. Researchers who studied the incident called the combination a "lethal trifecta": privileged access, untrusted input, and an outbound communication channel, all sitting in the same agent at the same time.

The lesson generalizes past that one incident. Any agent that treats outside input, especially user-submitted input, as an instruction rather than as data has turned every untrusted message into a possible injection point. Most teams get the permission question wrong in the same predictable way, too: they grant the wider scope because it's easier to set up once and forget about it. "Read database" and "write database" are not cosmetically different permissions, and neither are "retrieve Slack messages" and "send Slack messages." That distinction decides how far a single compromised tool call can actually travel.

How permissions and context travel (or fail to) across agent chains

Most multi-agent systems get built out of parts that each handle identity differently. One piece checks access one way, another piece assumes it's already been checked, and a permission granted at the orchestrator level may never actually get enforced down at the tool level. That mismatch is authentication fragmentation, and it's common enough to be the default state rather than the exception.

Credential sprawl compounds it. Every agent-to-tool connection needs its own authentication, and without one central place managing that, API keys end up scattered across machines and config files. An agent can end up holding credentials nobody explicitly gave it, just because it inherited them from something upstream.

Stale permissions are a quieter version of the same problem. An agent grabs its access rights when it starts up, and if a user's permissions change partway through that session, the agent just keeps acting on the old rights, because nothing told it to check again. Downstream agents receiving that agent's output have no way to see the mismatch; as far as the chain is concerned, it looks like properly authorized context.

Shadow access is the related gap worth naming: tool usage that happens outside a governed gateway layer can easily go unreviewed and unattributed. An agent working outside a governed layer can pick up and pass along permissions nobody in the organization ever actually reviewed.

Many teams assume the safe move is re-checking permissions at every hop. That instinct runs backwards from how the risk actually behaves: re-checking at each boundary is where drift sneaks in, because every redefinition is a fresh chance to get it wrong. Permissions need to be inherited and kept in sync from the source system continuously, checked once at the source and then propagated outward. Teams keep skipping this simpler approach in favor of the version that feels more careful.

Security vulnerabilities that convert configuration into attack surface

Security assessments of MCP setups running through early 2026 keep finding the same pattern: vulnerabilities sitting right at the boundary between agent and tool.

Security assessments of MCP implementations have repeatedly surfaced command injection, path traversal, and server-side request forgery — SSRF — vulnerabilities across the servers examined.

Tool poisoning might be the cleanest example of a cascade built by design rather than by accident. A compromised MCP server embeds hidden instructions inside a tool's description field, the part an agent reads like help text, and the agent runs those hidden instructions without the user ever knowing they were there. That turns the tool registry itself, the list of available tools an agent can call, into an attack surface.

Documented cases show the pattern playing out: a poisoned tool description causes an agent to carry out attacker-directed actions while still completing the user's legitimate request, so the cascade stays invisible. A related class of attack exploits shared configuration trust — once a project's MCP setup is approved, later changes including swapped-in malicious servers can inherit that approval automatically, because the system's trust is bound to an identity label rather than to what the server actually contains.

Security assessments of MCP environments add one more layer: in an estate where multiple MCP servers connect to each other, compromising one server can cascade across the others. Single-server compromise is the wrong unit to measure risk by once servers start talking to each other.

Picking just one defense here is a mistake worth naming directly, because none of them work alone. Static metadata analysis, tracking the model's decision path, watching for behavioral anomalies, giving users visibility into what's happening: each one catches something the others miss. Stack them, and each layer left standing alone becomes a gap waiting to be found.

Why validation loops are the primary structural remedy

Two production results show what actual structured validation buys you. PwC added validation loops to a CrewAI multi-agent workflow and saw accuracy jump roughly sevenfold, from a low baseline up to a much higher level. Separately, a multi-agent SRE system called STRATUS, presented at NeurIPS 2025, improved failure-mitigation success rates by 1.5x across two industry benchmarks, AIOpsLab and ITBench, by running dedicated detection, diagnosis, and validation agents in sequence rather than folding all three jobs into one.

The lesson from both: validation works best treated as a role, a stage built into the chain whose entire job is to interrogate whatever the previous stage handed it, checked continuously rather than gated once at the end.

Self-checking is unreliable here, and it's worth being blunt about why: the same bias that produced a bad answer will usually blind that same agent to the fact that it's bad. Validation done by an independent agent beats validation an agent does on itself, full stop, and a team relying on self-checking is checking a box, not catching an error. Isolating failure boundaries between stages matters too; if a validation step fails, that failure shouldn't itself become a corrupted input feeding the next stage. Verification gaps, that 21.30% slice from MAST, are the easiest category to fix precisely because they sit downstream, and adding a validation stage doesn't require redesigning the agents that generate output — it changes the architecture that receives it.

Industry analysis suggesting a substantial share of agentic AI projects may be canceled before they reach maturity reads less like a technology forecast and more like a governance one. Organizations that skip designing for validation before they deploy will meet these failure modes for the first time in production, which is the most expensive place to meet them.

Governance infrastructure as the precondition for catching failures at scale

Per-agent validation works fine when there are a handful of agents. It stops being enough once an organization moves from a few pilots to hundreds or thousands of agents running at once, because every failure mode described above scales with the number of agents and the number of connections between them.

Three layers of infrastructure fix the specific problems raised earlier. An MCP Gateway gives you one audited, policy-enforced layer that all agent-to-tool connections have to pass through, enforcing the read-versus-write distinction and keeping credentials in one managed place instead of scattered across machines. An Agent Gateway builds on that by adding agent identities, permissions, memory, and behavior monitoring, so every action an agent takes is attributable to something and reviewable after the fact. A governed skill registry, meanwhile, versions what agents can do, tracks who owns each capability, and scopes access, so five different teams aren't quietly rebuilding the same prompt or workflow, each one inheriting the same unchecked assumptions the others already made.

Auditability is what actually contains a cascade once one starts. If a system can't show who approved a given agent action and when, there's no way to reconstruct where a failure began after the fact, and recovery turns into guesswork. Permissions that get inherited and synced automatically from the source system, rather than redefined every time they cross a tool boundary, are the direct structural fix for the stale-permission cascade described earlier.

Roughly 80% of Fortune 500 companies already have AI agents running in production workflows, but only about 28% of those have actually put MCP servers in place to govern the connections between them. That gap means most agent-to-tool connections across that whole estate still carry the same integration fragmentation MCP was built to remove. The governance problem isn't a future risk — it's already running in production, today, across most of the companies large enough to have deployed agents in the first place.

Domain experts owning and controlling the AI skills relevant to their own team, inside a governed registry rather than scattered across individual machines, is both a productivity story and a resilience one. A skill that lives outside a registry can't be audited when something goes wrong, can't be versioned when it needs fixing, and can't be contained when it fails — it can only be discovered, usually after the damage is already done.