A single agent can already fail in difficult ways: a tool times out after applying a change, retrieved evidence is stale, or an answer invents a policy. With one decision loop, there are fewer handoffs to reconstruct. That does not make the system safe, but it gives an incident responder a smaller execution path to investigate.
Multi-agent systems add handoffs that can amplify these failures. The failure of one agent can cascade through the system in ways that are difficult to predict and harder to debug. When agent A calls agent B to complete a subtask, agent A’s correctness now depends on agent B’s correctness, which may depend on agent C’s correctness. A failure at any point in this chain propagates upward.
The failure may be obvious: agent B returns an error. Or it may be subtle: agent B returns a plausible but incorrect result that agent A incorporates into its reasoning without detecting the error. The subtle failures are the dangerous ones because they produce confident, wrong outputs that propagate through the system as verified facts.
Cascading Hallucination
The most dangerous multi-agent failure mode is cascading hallucination. Agent B hallucinates a fact. Agent A receives the hallucinated fact, treats it as ground truth because it came from another agent, and builds further reasoning on top of it. The hallucination is now embedded in agent A’s context and will be presented to the user with the confidence of a verified fact.
This is worse than single-agent hallucination for two reasons. First, the user may trust multi-agent output more than single-agent output. The assumption is that multiple agents checking each other’s work should reduce errors. In practice, without explicit verification mechanisms, multiple agents can amplify errors rather than catching them. Second, the hallucination is harder to trace. In a single-agent system, you can see the hallucination in the agent’s output. In a multi-agent system, the hallucination is buried in an intermediate agent’s response that was consumed by the calling agent and is not directly visible in the final output.
A Concrete Scenario
Consider a customer support system with three agents. Agent A is the orchestrator that receives the customer query. Agent B is a knowledge agent that searches documentation and returns facts. Agent C is a policy agent that checks company policies and returns guidance.
A customer asks about their refund eligibility. Agent A delegates to Agent B to find the refund policy. Agent B searches its knowledge base and hallucinates that the policy was updated last week to extend the refund window from 30 to 60 days. This is wrong. The policy has not changed. But Agent B presents it confidently with a plausible-sounding effective date.
Agent A receives this information and delegates to Agent C to check whether this customer qualifies under the 60-day window. Agent C confirms that the customer qualifies because they are within 45 days of purchase. Agent A tells the customer they are eligible for a refund under the extended 60-day policy.
The customer contacts the company expecting a refund under a policy that does not exist. The hallucination travelled through three agents, each of which trusted the previous agent’s output, and emerged as a confident, specific, wrong answer.
Mitigation: Inter-Agent Verification
The mitigation is risk-based source verification, not agreement between agents. When agent A receives a result from agent B, it should carry the source reference, the relevant passage or structured value, and the version or retrieval time needed to check it. Another agent can help inspect the evidence, but repeating the same unsupported claim is not independent confirmation.
Choose checks by the consequence of being wrong, the authority and freshness of the source, and whether the proposed action can be reversed. In the refund example, verify the eligibility rule against the authoritative policy and the purchase date against the account system before promising or issuing a refund. If either source is unavailable or conflicts with the claim, withhold the eligibility decision and route it for review. For a low-impact internal summary, sampling non-critical claims may be sufficient; requirements that affect permissions, money, or customer commitments need explicit checks.
An agent’s self-reported confidence is not permission to skip those checks. A confident answer can still be wrong, and several agents can share the same mistaken premise. Record unresolved claims and failed source checks in the handoff so the next agent cannot silently promote them to verified facts. Verification effort belongs in an explicit risk policy, not in a model’s assessment of its own certainty.
Context Window Exhaustion
Each agent in a multi-agent system has its own context window. When agent A calls agent B, agent A must pass enough context for agent B to do its work. If agent B then calls agent C, the context must be further compressed or truncated. By the time you reach three or four levels of delegation, the context available to the deepest agent may be insufficient for accurate work.
Consider a scenario where agent A is orchestrating a complex research task. It has accumulated 80,000 tokens of context from previous steps. It delegates to agent B to analyse a specific document. Agent B receives the document (20,000 tokens) plus a summary of agent A’s context (10,000 tokens). Agent B then delegates to agent C to extract key entities from a section of the document. Agent C receives a compressed version of the document section (5,000 tokens) plus a summary of agent B’s reasoning (3,000 tokens).
Agent C misses entities that were in the full document but not in the compressed version. Agent B’s analysis is incomplete because it was based on agent C’s incomplete extraction. Agent A’s final output is wrong, but the error originated three levels deep in the delegation chain, in a context compression step that is not visible in the final trace.
Mitigation: Context Management Discipline
Each agent should pass the minimum context needed for the sub-agent to do its work, not the entire conversation history. Critical context like specific constraints, quality requirements, and known facts should be explicitly included. Background context that is nice to have but not essential should be omitted to preserve context window space.
Hierarchical summarisation can help. Agent A provides agent B with a summary of the relevant context plus the specific task. Agent B provides agent C with an even more focused summary. Neither summarisation nor truncation guarantees that the task’s requirements survive. Keep authoritative evidence accessible by reference, and check each handoff against the requirements rather than assuming a fluent summary is complete.
Context pinning is another technique. Identify the most critical pieces of context (the user’s original request, key constraints, known facts) and pin them at every level of delegation. Pinned context is always included, even if it means reducing other context. This ensures that the most important information survives the delegation chain.
Monitoring Context Degradation
Check retained requirements and evidence at each delegation level. Before delegating, identify the constraints that determine whether the result is usable: tenant scope, policy version, relevant dates, allowed actions, and unresolved questions. After summarisation, verify that each required item is still present or retrievable and that the receiving agent’s result respects it. Keep the original evidence available for that comparison.
In the refund scenario, a summary that retains the customer’s purchase date but drops a policy exception is incomplete even if it retains nearly all the original tokens. A much shorter summary may be adequate if it preserves the applicable rule, exception, and source reference. Token counts measure context size and cost, not the proportion of meaning retained.
Use incident-derived evaluation cases that deliberately omit or contradict one required item. Check whether the receiving agent requests the missing evidence or stops the decision, rather than filling the gap with a guess. Track missing requirements, unsupported claims, and incorrect decisions separately from token savings. If a critical requirement disappears, repair the handoff or reduce delegation depth before continuing.
Dead Loops and Infinite Delegation
Multi-agent systems can enter loops where agent A calls agent B, agent B calls agent C, and agent C calls agent A. Without loop detection, the agents keep delegating to each other indefinitely, consuming tokens and adding latency without making progress.
A delegation stack can detect explicit cycles when the orchestrator tracks stable task identities. If a task is already active in the chain, reject the repeated delegation and return a structured stop reason. Do not force the calling agent to guess an answer. Changed wording can conceal the same task, so cycle detection needs independent execution limits as well.
The harder problem is implicit loops or infinite delegation behaviour. Agent A is unsure about a decision and delegates to agent B for a second opinion. Agent B is also unsure and delegates to agent C. Agent C is also unsure and delegates back to agent A, not because of a circular dependency but because all three agents have the same uncertainty threshold and none of them can resolve the uncertainty.
Mitigation: Delegation Depth Limits
Set a maximum depth for the delegation chain. At the limit, return control with verified partial results and a stop reason, or escalate for human review. Reaching the limit is not a reason to manufacture an answer or execute an unverified action.
Choose the depth limit from the task graph and test it against representative workloads. Depth alone does not bound cost: a shallow agent can repeatedly call siblings or retry tools. The orchestration layer also needs a shared per-task call budget and deadline, with bounded retries that consume the same budget. Reserve capacity before dispatch so parallel branches cannot each spend the remaining allowance.
Use missing evidence or a failed check to decide when to stop or request help. An agent’s confidence must not override the source-verification policy. Repeated delegation without new evidence should return an unresolved result, not another request for the same opinion.
Loop Detection at the Orchestration Layer
The orchestrator agent should track delegation patterns and detect loops before they consume significant resources. If the orchestrator sees that agent B has been called three times in the last ten seconds with similar tasks, it should stop delegating to agent B and handle the task differently. This is rate-limiting applied to delegation.
The orchestrator should also monitor token consumption per task. If a task has consumed more tokens than expected without producing a result, it should abort the delegation chain and return a partial result with an explanation. Token-based abort prevents runaway delegation from generating unexpected costs.
Inconsistent State
When multiple agents operate on shared state, they can create inconsistent state. Agent A reads a customer record, decides to update the address, and sends the update. Agent B reads the same customer record before agent A’s update is applied, decides to update the phone number, and sends its update. Depending on the update mechanism, one update may overwrite the other.
This is the classic concurrent modification problem from distributed systems. It applies to multi-agent systems whenever agents share state through external systems like databases or APIs. The problem is worse in multi-agent systems because agents may not be aware that other agents are operating on the same state.
Mitigation: Optimistic Concurrency Control
Each agent reads the state with a version identifier enforced by the storage or API layer. When updating, the agent includes that version as a precondition. The server must check the version and apply the write atomically; a separate read followed by an unconditional write still has a race. If the version has changed, reject the update so the caller can re-read and reconsider. For HTTP APIs, a strong ETag with If-Match is one way to express that precondition.
The retry logic adds complexity to the agent. The agent must detect the rejection, re-read the current state, re-evaluate its decision based on the updated state, and retry the update. If the state has changed significantly, the agent’s original decision may no longer be valid. The agent must handle this gracefully rather than blindly retrying.
Worked Example: Two Updates, One Stale Version
Consider a fictional support system where two agents read customer record version 17. The address agent proposes a new delivery address. The contact agent proposes a new phone number, but its write includes the whole record, including the old address. Without a precondition, the contact agent can silently restore the old address after the address agent has updated it.
Assume this API supplies strong ETags and requires If-Match for updates. Both agents initially receive ETag "17". The server accepts the address update with If-Match: "17" and advances the record to version 18. When the contact update arrives with the same precondition, the server returns 412 Precondition Failed without applying it. The address remains intact. This is the behaviour defined for a failed If-Match precondition in HTTP Semantics, RFC 9110.
The contact agent now reads version 18, verifies that the phone change is still authorised, and submits only the intended change against that version. If the server accepts it, version 19 contains both the new address and the new phone number. If the precondition fails again, the retry consumes the original task’s budget; exhausting that budget stops the write and returns a conflict for review. These version numbers illustrate the sequence, not a required ETag format.
A non-production test should force both agents to read version 17 before either writes. Assert that the stale write is rejected, that the rejection leaves the address unchanged, and that a bounded retry preserves both intended changes. Also force repeated conflicts and check that the stop path makes no further write. Save the precondition, server outcome, and resulting version in the trace without logging customer PII. A plausible final answer from the agents is not evidence that the record stayed consistent.
This example prevents a lost update to one record. It does not make a multi-record workflow transactional or solve a timeout after an external side effect. Those need their own transaction, reconciliation, and idempotency controls.
State Ownership
Another mitigation is to designate a single agent as the owner of each piece of state. If agent A owns customer records and agent B needs to update a customer, agent B delegates the update to agent A rather than performing it directly. This serialises access through the owning agent.
State ownership prevents concurrent modification only if the owner serialises writes and all writers use that path. A shared agent name alone provides no locking. Enforced ownership may create bottlenecks. If agent A is the sole owner of customer records and ten agents need to update customers simultaneously, agent A becomes a serialisation point. The throughput is limited by agent A’s processing speed.
The trade-off depends on your concurrency requirements. If concurrent modifications are rare, optimistic concurrency control is simpler and higher-throughput. If concurrent modifications are common, state ownership provides stronger consistency guarantees at the cost of throughput.
Idempotent Operations
Design tool operations to be idempotent. If agent A sends the same update twice (because it retried after a timeout), the second update should have no effect. Idempotency requires the tool to detect duplicate requests, usually through a request ID or idempotency key.
Idempotency is essential for reliable multi-agent systems because agents will retry failed operations. Without idempotency, a retry can create duplicate records, send duplicate emails, or apply duplicate charges. The tool layer must handle idempotency, not the agent layer, because the agent does not know whether the tool received the first request.
Cascading Latency
Each agent call adds latency. Agent A waits for agent B, which waits for agent C. The total latency is the sum of all agent call latencies plus network overhead. In a chain of four agents, each taking two seconds, the total latency is eight seconds before the user receives a response.
Latency compounds non-linearly in practice because each agent may make multiple tool calls, and the tool calls add their own latency. A multi-agent system where each agent makes two tool calls at 500ms each, in a chain of three agents, produces a total latency of at least three seconds from tool calls alone, plus model inference time at each level.
Parallel Execution
The primary mitigation is parallel execution of independent subtasks. If agent A needs results from both agent B and agent C, and B and C are independent, call them in parallel rather than sequentially. This reduces the total latency to the maximum of the individual latencies rather than their sum.
Parallel execution requires the orchestrator to identify independence. If agent B’s task depends on agent C’s output, they cannot be parallelised. If they are independent, parallelisation cuts latency roughly in half for two parallel calls, in thirds for three, and so on.
Timeout Enforcement
Each agent call should have a timeout. If the sub-agent does not respond within the timeout, the calling agent should handle the timeout gracefully. Three options exist. Retry the call (appropriate for transient failures). Use a degraded fallback like a cached result or a simplified heuristic (appropriate when some answer is better than no answer). Return an incomplete result with a clear explanation that some subtasks timed out.
The timeout should be set based on the expected latency of the sub-agent’s task plus a buffer for variance. A simple retrieval task might have a five-second timeout. A complex analysis task might have a thirty-second timeout. Do not set a single global timeout for all agent calls because different tasks have different latency profiles.
Circuit Breaking
If a sub-agent consistently fails or times out, stop calling it. The circuit-breaker pattern applies to multi-agent delegation: if agent B fails three times in a row, open the circuit and stop delegating to agent B. Route around the failure by using a fallback or reducing the scope of the task.
The circuit breaker should have a half-open state where it periodically retries the failed agent to see if it has recovered. If the retry succeeds, close the circuit and resume normal delegation. If it fails, keep the circuit open.
Failure Mode Summary
Cascading hallucination requires risk-based checks against authoritative sources. Context window exhaustion requires retained-requirement and evidence checks, supported by context pinning and careful summarisation. Dead loops require delegation depth limits, shared execution budgets, and loop detection. Inconsistent state requires optimistic concurrency control, state ownership, or idempotent operations. Cascading latency requires parallel execution, timeout enforcement, and circuit breaking.
The common thread is that multi-agent systems need the same distributed-systems patterns that microservices need: circuit breakers, timeouts, retries, idempotency, and eventual consistency. The models are non-deterministic, which adds a layer of complexity that deterministic microservices do not have. But the architectural patterns for handling failure, latency, and consistency are the same patterns that distributed systems engineers have been applying for decades.
Start with a single agent and add multi-agent delegation only when the task genuinely requires it. Every level of delegation adds failure modes, latency, and debugging complexity. The question is not whether multi-agent architectures are possible but whether the delegation justifies the operational overhead for your specific use case. Compare the simpler design against the delegated one on incident-derived cases, including failed source checks, missing requirements, budget exhaustion, and conflicting writes. Add delegation only when the measured benefit justifies those extra failure paths.
