Grounding: how to stop an AI agent inventing answers for your customers
Hallucination isn't a mysterious model flaw — it's a system design failure with known causes and known fixes. Retrieval grounding, decision boundaries, confidence thresholds and citation validation.
The question every operator asks in the first meeting: what stops it from making something up to a customer?
It's the right question, and the honest answer is not "the model is very good now." Language models produce fluent text that is consistent with their training distribution. When the correct answer isn't available to them, the fluent output keeps coming — it just stops being true, and it arrives in exactly the same confident register as everything else.
You don't fix this with a better model or a sterner prompt. You fix it with system design. Four layers, in order of how much they matter.
Layer 1: Ground the answer in live data
Most hallucinations in a business context aren't creative fiction — they're the model answering from general knowledge when it should have been reading your database.
"Your order shipped on Tuesday" is a hallucination if the model inferred it from typical patterns rather than from your fulfilment record. It's a fact if it read the record.
So: the model should never be the source of truth for anything a system knows. Order status comes from the order system. Policy comes from the policy document. Stock comes from inventory. Pricing comes from the catalogue. The model's job is to find, combine and express — not to remember.
In practice that means retrieval over your live systems, and it means being ruthless about what's in the context window. The most common grounding failure we see isn't missing retrieval — it's stale retrieval. Three versions of the returns policy in the index and no notion of which is current, so the agent quotes the 2023 one to a customer in 2026. Version and date your documents, filter to current, and treat "which document is authoritative" as a data problem you own rather than something the model should figure out.
Layer 2: Constrain what the agent can do
Grounding controls what the agent says. Decision boundaries control what it does, and this is the layer that lets you sleep.
Allow-list actions, don't block-list them. The agent can issue a refund up to €X on an order under Y days old with a delivery-confirmed status. It cannot issue a refund outside those conditions — not because we told it not to, but because the tool rejects the call. The boundary lives in code, where it can be tested, not in a prompt, where it can be argued with.
Encode the policy where it's enforceable. If your returns window is 30 days, the check_return_eligibility tool computes eligibility from the order date and returns a decision. It does not hand the model a policy document and hope. Anything that can be computed should be computed.
Make irreversible actions require confirmation. Reversibility is a good sorting criterion. Reading data, drafting a reply, looking up tracking — let it run. Sending an email, issuing money, deleting a record, publishing something — those get a gate, either a human or a hard rule.
Use structured output where the shape matters. When you need a classification, constrain the response to an enum. When you need extracted fields, constrain to a schema. A model that can only emit one of six values cannot invent a seventh.
Layer 3: Let it not know
The single most valuable behaviour you can build into an agent is a functioning escalation path.
Models are trained to be helpful, and helpfulness pulls hard toward producing an answer. Left alone, that's exactly the pressure that produces confident fiction. You have to give the agent somewhere else to go.
Set a relevance floor on retrieval. If nothing scored above the threshold, the correct behaviour is not to answer from whatever came back. It's to escalate.
Instruct positively, not just negatively. "Don't make things up" is weak. "If the retrieved context does not contain the answer, say that you don't have it and hand off to a human with a summary of what the customer asked" is a specific, checkable instruction with an action attached.
Escalate on sentiment, not just on uncertainty. Some conversations should leave automation regardless of whether the agent knows the answer — legal threats, bereavement, safety issues, anyone who's asked for a human twice. Detect these on a separate path with its own rules and its own eval set.
Make handoff cheap and good. An escalation that dumps a raw transcript on an agent is a tax. One that arrives with a written summary, the retrieved context, the actions already taken and the specific blocker is a gift. If handoff is genuinely good, you can set the threshold conservatively without anyone resenting it — and a conservative threshold is what keeps you out of trouble.
Layer 4: Verify before it ships
The final layer catches what the first three missed.
Enforce citations, then validate them. Require the model to cite the source for each factual claim. Then check, in code, that the cited source exists in what you actually sent it and that the claim appears there. Uncited or unverifiable claims get stripped or flagged. This converts hallucination from an invisible failure into a detected one — which is the entire game.
Cross-check computed values. Refund amounts, delivery dates, discount calculations — recompute them deterministically and compare. If the model's number and yours disagree, yours wins and the discrepancy gets logged. Models are not calculators and should not be trusted as ones.
Run a cheap verification pass on high-stakes output. A second, smaller model checking "is every claim here supported by this context?" catches a meaningful share of errors for a fraction of the primary call's cost. Use it where the cost of being wrong justifies it.
What doesn't work
Some things that get proposed constantly and don't survive contact with production:
Prompting harder. "You MUST NOT hallucinate. This is CRITICAL." Modern models follow instructions closely, which means aggressive language mostly produces over-cautious behaviour on cases that were fine — more unnecessary escalations, more hedging, more refusals to answer questions it could have answered. It doesn't create knowledge the model doesn't have.
Asking the model if it's sure. Self-reported confidence correlates weakly with correctness. A model that hallucinated an order date will confidently confirm the order date. Confidence has to come from the system — retrieval scores, validation results, boundary checks — not from introspection.
Temperature zero. It makes output more deterministic, not more true. You'll get the same wrong answer reliably.
Waiting for a better model. Model quality has improved enormously and the failure mode persists, because it's structural: a system that isn't given the fact cannot produce the fact. Better models hallucinate less often and just as convincingly.
The honest version
No system reaches zero. What a well-built one achieves is: hallucinations become rare, and when they happen they are detected rather than shipped, because a citation didn't validate or a computed value didn't match or a retrieval score fell below the floor.
That's the actual bar. Not "it never gets anything wrong" but "when it gets something wrong, we know, and a human sees it before the customer does."
Every operator we've worked with accepts that bar immediately — because it's the same bar their human team operates at, and the human team doesn't come with an audit log.
Every AIMAGENTIC agent ships with grounded retrieval, coded decision boundaries and a written escalation path. Book an audit call and we'll map yours.