Multi-agent system failures — coordination breakdowns, handoff errors, consensus manipulation. We've tracked 48 distinct Multi-Agent Systems patterns across production AI agent deployments — most commonly in Operations, Multi Agent Systems systems. One recurring example: Agent Handoff Race Condition — When one agent hands off a task to another (e.g. a triage agent passing a ticket to a specialist agent), both agents briefly believe they may be responsible for the same unit of wo…
Each pattern below documents the specific failure mode, why it happens, and how teams have mitigated it in practice — use this page as a reference when building guardrails, writing evals, or debugging an agent that's already misbehaving in this way.
Frequency:Common
When one agent hands off a task to another (e.g. a triage agent passing a ticket to a specialist agent), both agents briefly believe they may be responsible for the same unit of work. If the handoff isn't atomic — the sender marks the task "handed off" in one write and the receiver marks it "claimed" in a separate write — a narrow window opens where either both agents act on the task simultaneously, or neither does because each assumes the other has it. The failure is timing-dependent and often invisible in single-agent testing, only surfacing under concurrent load.
Frequency:Common
Agents Pursue Conflicting Objectives
Frequency:Occasional
A low-priority agent holds a shared resource a high-priority agent needs, and nothing lets the high-priority agent preempt it. A low-priority agent acquires a shared resource (a database lock, a rate-limited API slot, a write lease on a document) and then stalls or runs slowly, while a high-priority agent that needs the same resource is forced to wait behind it. The high-priority agent's own urgency provides no mechanism to preempt the lower-priority holder, so the system's effective priority order is inverted: the task that matters least is dictating the pace of the task that matters most.
Frequency:Very Common
Multiple agents operating concurrently compete for the same limited resource — a shared LLM inference quota, a database connection pool, a third-party API's rate limit, or a GPU worker pool — and none of them individually has enough context to know how much of the resource other agents are currently consuming. As contention rises, every agent's individual performance degrades (higher latency, more throttling, more retries), and the degradation compounds because retries themselves consume more of the scarce resource, pushing the system further from recovery.
Frequency:Common
Two or more agents that are supposed to maintain a shared view of the world — the current status of a task, a customer's conversation context, an inventory count — drift out of sync because their state-synchronization mechanism silently fails or falls behind. Each agent keeps acting confidently on its own local copy, and because no single agent has a global view, the divergence goes undetected until the agents' outputs visibly contradict each other or a downstream system receives conflicting updates.
Frequency:Common
One agent in a multi-agent pipeline runs slow or hangs, and its caller times out and gives up waiting on it. Because that caller is itself being awaited by another agent upstream, its own timeout consumes most of the upstream agent's remaining budget, and the pattern repeats up the chain — each layer's timeout firing shortly before the one above it, so a single slow agent deep in the pipeline produces a wave of timeouts that appears to hit the entire system simultaneously.
Frequency:Common
Agents disagree on who has final say, and the system silently picks a winner instead of resolving the conflict. This is common in flat multi-agent orchestration (e.g., LangGraph or CrewAI-style peer topologies) where no agent is declared authoritative for a given decision domain.
Frequency:Rare
One agent in a multi-agent system starts producing output that is not simply wrong or absent but actively inconsistent, contradictory, or adversarial-looking — different answers to different peers about the same fact, plausible-sounding but fabricated tool results, or outputs crafted (whether by a prompt-injection attack, a corrupted model checkpoint, or a bug) to pass superficial validation while being substantively false. Because the failure doesn't look like a crash or a timeout, the other agents in the system have no clean signal to detect it, and they can be individually convinced by output that appears locally reasonable.
Frequency:Rare
An early agent's mistake gets treated as ground truth by every downstream agent, so a small error compounds into a badly wrong final answer as it propagates through the pipeline.
Frequency:Common
Information Lost or Corrupted Between Agents
Frequency:Common
Agents lose or drop key information passed between them, so a downstream agent acts without facts that an upstream agent already discovered.
Frequency:Occasional
Multi-Agent Voting or Agreement Fails to Resolve
Frequency:Occasional
Agents appear to agree, but only because they were all seeded from the same flawed context or bias -- not because they independently verified the answer.
Frequency:Common
Two or more agents disagree and nothing in the pipeline resolves the conflict, so contradictory answers reach the end user or downstream system.
Frequency:Common
The manager/orchestrator agent (the coordinator role in LangGraph supervisor graphs or CrewAI's manager pattern) assigns subtasks to the wrong worker agents, or fails to correctly synthesize their outputs into a coherent final answer.
Frequency:Occasional
Two or more agents each hold a resource that another agent in the group needs, and each is waiting for the resource held by the next, forming a closed cycle of dependencies where no agent can proceed. Unlike a simple timeout or a single stuck agent, deadlock is a stable state — none of the agents involved will ever make progress on their own, because each is correctly waiting for something that will never be released, since the releaser is itself waiting.
Frequency:Occasional
Agents Delegate to Sub-Agents Creating Unbounded Depth
Frequency:Occasional
Multiple agents independently solve the same subtask -- often calling the same expensive tool or API -- because there's no shared task ledger to prevent redundant work.
Frequency:Common
Agents interacting live produce unintended behavior -- loops, oscillation, runaway cost -- that never shows up when each agent is tested in isolation.
Frequency:Common
An agent completes its portion of a multi-agent workflow and hands the remaining work to another agent, but no entity is ever explicitly marked as the owner of the outstanding task after the transfer. Both the sending agent and the receiving agent treat the handoff itself as the completion event, rather than the downstream task being resolved. The task sits in the receiving agent's queue, an inbox, or a shared work-item store with no active owner tracking it to completion, and it silently stalls.
Frequency:Occasional
A workflow is designed so that one agent must obtain sign-off from a human or a designated approval agent before handing a task to the next agent in the chain, but the handoff occurs without the gate being satisfied. This happens most often when the approval step is implemented as a soft convention rather than a hard dependency — the sending agent's code path can reach the handoff call whether or not the approval response was received, correct, or even requested. The receiving agent, having no way to know an approval was expected, proceeds to execute.
Frequency:Occasional
Two (or more) agents are each configured to hand off a task to the other under specific conditions, and those conditions form a cycle: Agent A decides the task needs Agent B's capability and hands it off, Agent B decides the task actually needs Agent A's capability and hands it back, and neither agent's handoff logic contains a way to recognize that the task has already been through this loop. The task bounces indefinitely (or until an unrelated resource limit like a timeout or step cap kills it) without either agent making progress on the underlying work.
Frequency:Very Common
When one agent hands a task to another, it passes along a summary or subset of the context it accumulated, rather than the full working state. The receiving agent then either proceeds on incomplete information (producing a subtly wrong result) or has to spend additional tool calls and turns re-deriving context the sending agent already had — re-reading source documents, re-querying an API, or asking the user to repeat information already provided upstream.
Frequency:Common
A handed-off task gets executed more than once because the handoff mechanism retries on a suspected failure (timeout, dropped acknowledgment, transient network error) without any way to detect that the receiving agent already processed the original attempt. The receiving agent has no concept of "I've seen this task ID before" and treats each retry as a fresh, independent instruction, resulting in duplicate side effects — a second email sent, a second charge issued, a second record created.
Frequency:Occasional
The sending agent hands off a task assuming the receiving agent has sufficient permissions to complete it, but the receiving agent actually operates under a narrower permission set — a different service account, a scoped API token, or a role with fewer grants. Rather than failing loudly, the task often degrades silently: the receiving agent's tool calls are denied or return partial results, and it either produces an incomplete output without flagging the gap or falls back to a lower-quality path that masks the permission problem entirely.
Frequency:Occasional
The sending agent packages a handoff using one version of the task schema (field names, required/optional fields, encoding conventions) while the receiving agent was built against a different version. The two versions overlap enough that the handoff doesn't fail outright — the receiving agent parses the payload without an error — but fields have been renamed, restructured, or reinterpreted between versions, so the receiving agent either misreads a field's meaning or silently drops fields it doesn't recognize.
Frequency:Occasional
After a task is handed off, the receiving agent fails partway through execution, and the workflow attempts to roll back to the pre-handoff state — but the rollback cannot be cleanly performed. This happens because the receiving agent has already taken irreversible or partially-irreversible actions (sent a message, committed a write, called an external API with a side effect), and no compensating action exists, or the sending agent no longer has the context or authority to undo what the receiver did.
Frequency:Common
An upstream agent flags low confidence or ambiguity in its free-text reasoning, but the structured handoff schema passed to the downstream agent -- a common MCP/tool-call handoff pattern -- carries only the final value and status. The confidence/provenance signal is invisible to the downstream agent, which uses the value with full confidence.
Frequency:Occasional
Task state accumulated by the sending agent — intermediate results, partial progress, resolved variables, in-progress computation — fails to fully transfer to the receiving agent during a handoff. Unlike context incompleteness, where a summary deliberately omits detail, state loss is typically accidental: a serialization step drops fields, a transport mechanism truncates a payload, or the receiving agent initializes its own fresh state instead of loading the transferred one, and the task effectively restarts from a blank slate without anyone intending it to.
Frequency:Common
A task is handed off to another agent before it's ready to receive it, or after its action deadline has already passed. In both directions, the handoff is transmitted successfully at the protocol level (in LangGraph, CrewAI, or a custom message-queue-based orchestration) but arrives at the wrong moment for the receiver to do anything useful with it — the receiving agent might still be cold-starting, mid-way through another task, or the task's validity window may have already elapsed by the time it's actually read.
Frequency:Occasional
Critic and reviser agents -- a common pattern in LangGraph reflection loops -- keep critiquing and revising each other's work endlessly, with no termination condition to stop once the debate stops making progress.
Frequency:Common
When two or more agents collaborate on a shared task but have persistently different response latencies — one calls a fast local model, another calls a slower remote API, or one has a heavier context to process — the faster agent either sits idle waiting on the slower one, or worse, proceeds to act on the slower agent's most recently available (and now stale) output rather than waiting for its current, in-flight result. Both outcomes degrade the collaboration: idle waiting wastes throughput, and acting on stale data produces decisions based on outdated information.
Frequency:Occasional
A multi-agent system that relies on one agent being designated "leader" or "coordinator" (to assign work, break ties, or serialize decisions) fails to establish or maintain a single clear leader. Either no agent successfully claims leadership, multiple agents each believe themselves to be leader simultaneously (split-brain), or leadership flaps rapidly between candidates, leaving the system without the coordination guarantee the architecture depends on.
Frequency:Occasional
Two or more agents, each trying to politely avoid conflicting with the other, keep changing their behavior in response to each other's changes without ever converging on a state where actual work gets done. Unlike deadlock, none of the agents are blocked or waiting — they are all actively "working," consuming compute and making API calls — but the net forward progress on the task stays at zero because each agent's reaction to the other keeps resetting the situation back to an equivalent unresolved state.
Frequency:Common
A receiving agent misreads or misparses another agent's output, so its downstream action contradicts what the upstream agent actually produced.
Frequency:Common
A single agent's error compounds exponentially as it moves through a multi-agent pipeline -- common in LangGraph/CrewAI sequential chains -- because downstream agents treat upstream errors as ground truth, amplifying the original mistake 17x-20x by the time it reaches the final output.
Frequency:Critical
Multiple independent agents reach the same wrong conclusion, and the system mistakes that agreement for a confidence signal -- escalating the decision to production because all agents making the identical mistake looks like verification, not error.
Frequency:Occasional
Central Orchestrator Becomes System Chokepoint
Frequency:Common
Agents Operating in Parallel Cause Conflicts or Inconsistencies
Frequency:Occasional
Agents converge on an answer and stop before gathering enough evidence, so the group agrees quickly but on a weakly supported conclusion.
Frequency:Common
Agents don't have a clear, non-overlapping definition of who owns which responsibility, so work gets duplicated in some areas and dropped entirely in others.
Frequency:Common
Orchestrator Routes Task to Wrong Agent
Frequency:Common
Ambiguous Blueprint Specifications Cause Agents to Interpret Roles Differently
Frequency:Common
Work Lost or Duplicated During Agent Transitions
Frequency:Common
An agent hands off incomplete or incorrect state to the next agent in the pipeline -- a common failure in LangGraph/CrewAI-style handoffs -- so the downstream agent works from a gap it doesn't know exists.
Frequency:Common
Agent Doesn't Know When to Stop
Frequency:Common
A judge/verifier agent -- a pattern common to LLM-as-judge and OpenAI Agents SDK guardrail setups -- approves worker-agent output that is actually wrong, because it's checking surface plausibility rather than verifying against ground truth.
Frequency:Occasional
A specialized worker agent optimizes its own subtask metric so hard that it ignores or overrides the global plan, so the overall task fails even though each agent's local output looks fine.