You've tested your agent dozens of times. It works in your dev environment. You ship it. Then your first real user triggers a confabulated answer, a wrong tool call, or an action the agent was never supposed to take.
The instinct is to blame the model. Swap GPT-4 for Claude, or try Gemini, or fine-tune something. But in most production failure post-mortems, the root cause isn't the model's weights — it's the information the model was given when it had to make a decision.
That's a context design problem. And it's solvable.
What "Hallucination" Actually Means in an Agent System
The word "hallucination" gets overloaded. It covers at least three distinct failure modes that require different fixes:
1. Factual fabrication — the model generates a statement that sounds plausible but has no grounding in the provided context. A customer-support agent invents a return policy. A research agent cites a paper that doesn't exist.
2. Tool misuse — the model calls a function with wrong parameters, calls the wrong function entirely, or invents a function call for a tool that doesn't exist. This is especially common when tool descriptions are vague or when multiple tools have overlapping purposes.
3. Instruction drift — the agent gradually drifts from its original task as the conversation grows, because the instructions in position 0 of the context window become diluted by the accumulated turns. By turn 20, the model is effectively a different agent than the one you configured.
All three happen because the model is filling gaps. When it doesn't have the right information at the right time, it generates the most statistically plausible completion — which is often wrong.
The Three Structural Causes
1. Context Rot
Context rot happens when the signal-to-noise ratio of the agent's context window degrades over time. You start with a tight system prompt and a clear task. Then tools return verbose JSON, the user adds side comments, intermediate reasoning accumulates, and by the time the agent needs to make a consequential decision, the relevant instructions are 8,000 tokens back in a 16,000-token context.
Models have recency bias. They attend more strongly to recent tokens. An instruction buried deep in a long context competes with everything that came after it. If you haven't re-anchored that instruction — or actively managed what stays in the context — it effectively weakens.
2. Tool Description Ambiguity
This is the most underestimated cause of agent failures in production. Tool descriptions are part of the context. The model reads your function name, description, and parameter schema and makes a probabilistic judgment about when and how to use the tool.
When descriptions are vague ("helper for data operations"), the model interpolates. When multiple tools have overlapping semantics, the model guesses. When parameter descriptions omit constraints ("pass the user's ID here" without specifying the format or source), the model fills in what seems reasonable.
A 40-word tool description written in five minutes at 11pm is doing significant cognitive work in your production system. It deserves more attention than it usually gets.
3. Memory Gap at Decision Points
Many agent failures happen at a specific moment: when the agent needs information that existed earlier in the conversation but is no longer retrievably present. The user mentioned their account type in message 3. The agent needs that in message 15 to decide which tool to call. If your architecture doesn't have explicit memory — a structured state object, a retrieval step, or a re-injection mechanism — the agent either asks again (bad UX) or guesses (hallucination risk).
This is distinct from retrieval-augmented generation (RAG), which is about fetching external knowledge. Memory gap is about the agent's own working state — the structured facts it needs to carry forward across turns.
Five Grounding Techniques That Work in Production
Technique 1: Explicit Negative Space in System Prompts
Most system prompts describe what the agent should do. High-reliability agents also explicitly describe what the agent should not do, what it doesn't know, and what to say when it hits an uncertainty boundary.
Instead of relying on the model to infer that it shouldn't make up a policy, you state it directly: "If you do not have explicit information about X in the provided context, respond with [specific fallback phrase]." Negative space definitions dramatically reduce fabrication because you're replacing probabilistic gap-filling with a deterministic instruction.
Technique 2: Priority-Weighted Context Injection
Not all context is equally important. Define an explicit hierarchy: core task instructions (highest priority) > current-turn user input > tool results > conversation history > background knowledge (lowest priority).
When context pressure builds, prune from the bottom of that hierarchy, not uniformly. A compaction strategy that preserves your system prompt and recent tool results while summarizing older conversation turns will perform better than a naive truncation at the context limit.
Technique 3: Anchoring Instructions at Injection Points
Before each tool call, re-inject the relevant constraint. Before each generation step, include a brief instruction re-statement. This isn't repetition for the user — it's a technical mechanism to counteract recency bias and context rot.
The pattern looks like this: [core task reminder] + [current state] + [specific decision or generation request]. The reminder should be short — two to three sentences — but its presence at the point of decision meaningfully reduces drift.
Technique 4: Structured State Objects Over Conversation History
Instead of relying on the model to extract relevant facts from prior turns, maintain an explicit state object and inject it as structured context. Something like:
CURRENT STATE:
- User: {{name}}, plan: {{plan_type}}
- Task: {{active_task}}
- Constraints: {{active_constraints}}
- Last confirmed: {{last_confirmed_fact}}
This object is compact, survives context window pressure, and is unambiguous. The model doesn't need to remember that the user mentioned their plan type three turns ago — it's right there.
Technique 5: Confidence-Gated Tool Calls
For high-stakes tool calls (writes, deletions, external API calls), add a confidence gate: before executing, the agent must produce a brief rationale and a confidence signal. A simple yes/no — "Do I have sufficient information to execute this reliably?" — inserted before the tool call catches a significant fraction of wrong calls. The model that would have fabricated a parameter often surfaces its own uncertainty when asked directly.
Why These Failures Compound in Multi-Agent Systems
Single-agent hallucinations are bad. Multi-agent hallucinations are worse because they propagate.
In a typical orchestrator-subagent pattern, the orchestrator passes context summaries to subagents. If those summaries contain a fabricated fact — a number, a user attribute, a constraint — the subagent treats it as ground truth. It has no access to the original conversation. By the time the final output reaches the user, the original error has been compressed, processed, and amplified through several layers of reasoning.
This is why multi-agent architectures require stricter context discipline at handoff points. Every context summary passed between agents should be treated like a schema: explicit fields, explicit null values (rather than omitting absent information), explicit confidence signals on uncertain facts.
The Underlying Principle
The model is a general-purpose reasoning engine. The quality of its outputs is bounded by the quality of the inputs it receives at decision time. A hallucination that looks like a capability failure is almost always an information failure — the model was asked to decide in an information environment that didn't support a reliable decision.
Context engineering is the practice of deliberately designing that information environment. It's the system prompt, yes, but also the tool descriptions, the state management, the compaction strategy, the memory architecture, the injection timing, and the confidence gates. Together, these determine whether your agent makes reliable decisions or plausible-sounding guesses.
Most of this is invisible until something goes wrong. Then it's the only thing that matters.
If you want the full framework — 35 pages covering token budget management, RAG vs. long-context decision patterns, system prompt design templates, anti-hallucination architecture, and multi-agent coordination scaffolds — the Context Engineering for AI Agents guide has 13 copy-paste templates you can adapt directly to your stack.
Context Engineering for AI Agents — Practitioner's Guide ($39)
