Hallucination in a single LLM call is a known problem with known mitigations: retrieval augmentation, structured outputs, temperature control, post-hoc fact-checking. The model generates something incorrect, you catch it, you fix the prompt or the retrieval.
Hallucination in a multi-agent system is different. It is not just a model quality problem. It is an architectural problem — one where the structure of the system can amplify and propagate a single model error into a compounding chain of confident wrongness that is invisible until the final output arrives.
Why Multi-Agent Hallucination Is Worse
In a single-agent system, the hallucination is isolated. The model produced something wrong. You inspect the output, identify the error, trace it to a prompt or retrieval issue, and fix it.
In a multi-agent system, the hallucination propagates. Agent A produces a wrong output. Agent B receives that output as input, treats it as a verified fact, and builds on it. Agent C receives Agent B's output, which has now compounded the error. By the time the final output reaches a human, the original hallucination is buried under several layers of downstream reasoning that all look internally consistent.
This is the error amplification problem. It is not about any individual model's quality — it is about what happens when outputs from one model become the inputs for another without a verification step between them.
The Three Sources in Multi-Agent Systems
1. Context contamination
As an agent workflow progresses, the context window accumulates. Tool results, prior reasoning steps, sub-agent outputs — all of it builds up. In long workflows, earlier context can crowd out or contradict later context. The model is reasoning over a large, potentially inconsistent context window and making a coherence judgment across it.
Hallucinations often emerge at this boundary: the model synthesizes conflicting signals in the context window into a plausible-sounding but incorrect claim. The longer the context, the higher the chance of this synthesis failure.
2. Tool output misinterpretation
When an agent calls a tool, it receives a response in whatever format the tool produces. The model interprets that response and incorporates it into its reasoning. If the tool response is ambiguous, uses domain-specific formatting, or returns an unexpected schema, the model may misinterpret it — treating an error message as a valid result, misreading a numeric field, or conflating two similar-sounding fields.
The model does not have uncertainty about its interpretation of the tool response. It treats its interpretation as correct and proceeds. If the interpretation is wrong, every subsequent step built on it is wrong.
3. Instruction drift in long workflows
An agent starts with a clear goal. As the workflow progresses and the context window fills, the original instruction can become less salient relative to the accumulated context. The agent begins to optimize for the most recent context rather than the original goal — a form of hallucination where the agent's behavior drifts from its mandate without any single step being clearly wrong.
Architectural Mitigations
Centralized manager with validation gates
In a peer-to-peer multi-agent topology, agents pass outputs directly to each other. Each agent trusts the previous agent's output. Error amplification is unbounded.
A centralized manager pattern inserts a validation step between sub-agent outputs and downstream inputs. The manager receives an output, applies validation logic, and either passes it forward (if valid) or routes to a correction step (if not). The manager is the circuit breaker for hallucinated sub-agent outputs.
The cost is latency — every output goes through the manager before proceeding. The benefit is that errors are caught at the source rather than compounding through the pipeline.
Output schema enforcement
Model outputs that are free-form prose are harder to validate than outputs with enforced schemas. A sub-agent that is required to return a JSON object with specific fields is easier to validate: are the fields present? Do the values have the expected types? Are the claims within the expected range?
Structured outputs — using JSON mode, tool use, or output parsers — are one of the most effective architectural mitigations for hallucination in multi-agent systems. They convert free-form generation into testable structured data.
Source attribution requirements
Require sub-agents to attribute claims to sources. "The customer's last purchase was $340" is harder to validate than "The customer's last purchase was $340 (source: CRM query, customer ID 12345, retrieved 14:22 UTC)." Attribution forces the model to ground its output in a traceable source rather than synthesizing from training data or prior context.
Attribution also enables post-hoc validation: you can check whether the cited source actually supports the claim. In a customer-facing system where factual accuracy is critical, source attribution is not just a nice-to-have — it is the mechanism that makes hallucination detectable.
Context compression between steps
Instead of passing the full accumulated context from one step to the next, compress the context to the relevant summary before the handoff. The receiving agent gets a clean, compressed summary of what has been learned so far — not a raw concatenation of all prior tool outputs and reasoning steps.
Compression reduces context contamination risk. It also reduces token cost. The tradeoff is compression quality — a bad summarization step can lose information that turns out to be relevant. Test compression prompts carefully and retain the full context in storage for auditability even when compressing for active reasoning.
The Eval Implication
Evaluating hallucination in multi-agent systems requires more than checking the final output. You need to check intermediate outputs as well — specifically the outputs that will become inputs for downstream agents.
A hallucination at step three that produces a correct-looking final output (because downstream agents happened to compensate for the error) will not be caught by final-output evals. It will appear in production as an intermittent correctness problem that is difficult to reproduce because it depends on the specific path through the system.
Intermediate output validation is the eval counterpart to the manager validation pattern. Build it into your eval framework, not just your production monitoring.