From Fabrication to Fact: Building Grounding Layers That Keep Production Agents Honest
What this article gives you
You have passed your evaluation gates, your agent is in production, and quality is slipping in ways your test suite did not predict. This article explains why grounding fails differently at scale, how to build retrieval and validation layers that hold under that load, and what the teams at Klarna, JPMorgan, CVS Health, and others did when they hit the same wall.
Why hallucinations are a production problem, not a model problem
Hallucination is the single largest reliability barrier in deployed agents as of 2026, ahead of governance gaps and evaluation failures in production failure rates. That ordering matters, because most teams invest their grounding effort before launch, in prompt design and eval, then treat post-launch degradation as a tuning problem.
It is not a tuning problem. The model you deployed in February behaves the same way it did then. What changed is the distribution of inputs. Production traffic contains combinations your eval set did not include, and the agent fills every gap it encounters with a confident-sounding output.
The trust math compounds this. When hallucination rates exceed 30 percent in production, users abandon the product even when later outputs improve: trust collapses faster than it is built. Klarna learned this directly. The customer service agent launched in February 2024 with raw prompt engineering and handled the equivalent of 853 FTE workloads by Q3 2025. But by May 2025, quality degradation on complex disputes was severe enough that the CEO acknowledged the problem publicly, and the company rehired a human escalation tier to handle what the agent could not. The hybrid model that stabilised by late 2025 works because it routes contested or high-stakes cases to humans rather than asking the agent to fabricate certainty it does not have.
The lesson is not that agents fail on hard cases. It is that agents without grounding layers have no way to signal when a case exceeds their reliable range.
How grounding layers are structured
A grounding layer is not a single component. It is a pipeline of three interlocking parts: retrieval, context assembly, and output validation. Each can fail independently.
flowchart TD
A[User query] --> B[Query rewriting]
B --> C[Retrieval: vector + keyword]
C --> D{Relevance threshold met?}
D -- No --> E[Escalate or clarify]
D -- Yes --> F[Context assembly]
F --> G[LLM generation]
G --> H[Grounding validator]
H --> I{Claims supported?}
I -- No --> J[Strip or flag unsupported claims]
I -- Yes --> K[Deliver response]
J --> L{Consequential action?}
L -- Yes --> E
L -- No --> K
Retrieval quality is the foundation
RAG reduces hallucination rates by up to 60 percent compared to ungrounded LLM calls, but the number depends entirely on retrieval quality. Fetching the wrong chunk is worse than fetching nothing: it gives the model false confidence in a fabrication.
The metrics that matter for agentic RAG in production are:
- Context precision: what fraction of retrieved chunks are actually relevant to the query
- Context recall: what fraction of the relevant information in your corpus was retrieved
- Chunk freshness: the age of the retrieved document relative to your update cadence
JPMorgan’s Contract Intelligence platform illustrates what good retrieval looks like in a document-heavy workflow. The system reviews commercial loan agreements, replacing 360,000 lawyer-hours per year, and does so by grounding every extracted clause against the source document rather than relying on general legal knowledge. Portfolio managers using the LLM Suite complete research cycles 83 percent faster than before, partly because the system surfaces the source alongside the answer, making errors catchable before they propagate. The grounding is structural, not instructional.
Context-driven hallucinations: the hidden failure mode
A retrieval success can still produce a hallucination if the assembled context contradicts itself, is truncated mid-sentence, or contains stale data alongside current data. This is a context assembly problem, not a model problem.
The fix is to treat context as a structured input. Before handing retrieved chunks to the model, run a consistency check: flag chunks that contradict each other, strip metadata that will confuse the model, and annotate each chunk with its source and date. The model then has what it needs to attribute claims accurately, and your output validation layer has what it needs to verify them.
flowchart TD
A[Retrieved chunks] --> B[Contradiction check]
B --> C{Conflict detected?}
C -- Yes --> D[Flag conflict, surface most recent source]
C -- No --> E[Annotate with source + date]
D --> E
E --> F[Truncation check]
F --> G{Complete sentences?}
G -- No --> H[Extend or drop chunk]
G -- Yes --> I[Assemble context window]
H --> I
Validation layer design
The output validation layer compares each factual claim in the agent response against the sources provided in context. Claims with no supporting source are either stripped, marked uncertain, or routed for human review, depending on the consequence class of the action.
CVS Health’s deployment on the ServiceNow platform handles millions of customer service conversations using the platform’s Context Engine and Workflow Data Fabric to ground each agent response in current workflow state rather than general-purpose knowledge. The architecture keeps the agent inside a bounded information space: it knows what it is allowed to know, and anything outside that space triggers escalation rather than fabrication. This is what AI agent governance looks like at the architecture level, not the policy level.
For teams building their own validation layers, the practical starting point is a claims extractor running against every response, matched against the retrieved context. Tools like Prefactor provide this as a drop-in grounding evaluation step. The key design decision is consequence classification: a wrong answer about a returns policy and a wrong answer about a drug interaction require different escalation paths.
Continuous grounding evaluation
Grounding is not a launch gate. It is an ongoing measurement. Your retrieval corpus changes, your query distribution shifts, and your agent’s behaviour drifts as context windows evolve. Teams managing agents at scale run agent evaluation continuously, sampling 5 to 10 percent of live traffic for grounding checks and using the labelled set to recalibrate their automated classifiers weekly.
General Mills runs a supply chain agent that evaluates more than 5,000 shipments daily, routing exceptions to human review rather than letting the agent extrapolate beyond its data. The system has generated over $20 million in savings since fiscal 2024 not because it is never wrong, but because it knows when it is outside reliable range and hands off accordingly. That boundary awareness is engineered, not emergent.
If you are building multi-agent systems, grounding compounds in complexity: each agent can introduce a fabrication that the next agent treats as fact. Validation at the handoff points between agents is as important as validation at the user-facing output.
For a broader view of how these patterns fit into overall agentic AI architecture, the retrieval and validation layers described here sit between the orchestration layer and the tool-execution layer, where consequential outputs originate.
Where to start
If your agent is already in production and quality is degrading, the fastest diagnosis is a grounding audit on a sample of recent failures: categorise each by retrieval miss, context conflict, or unsupported generation. Take the agent readiness assessment to identify which layer in your current stack is the primary failure point and get a prioritised remediation checklist.