You cannot make a model incapable of inventing things, but you can make invention useless to it. Ground every answer in approved sources, take numbers and dates only from live systems, require the agent to say it cannot confirm when nothing supports an answer, check replies before they send, and test for invented claims on your own cases.
Where do support agents invent things?
In predictable places. Knowing them tells you where to put controls.
- Gaps in the knowledge base. A customer asks something no article covers. The model fills the gap with what sounds plausible for a business like yours.
- Numbers. Fees, delivery times, interest, refund amounts. A model will produce a confident figure from context or from the general shape of the industry.
- Process steps. "Go to Settings, then Account, then Close." If the app's menus changed, the agent describes the old ones, or ones that never existed.
- Status. "Your refund has been processed" when the system shows it pending, because the conversation felt like it was heading that way.
- Pressure. A customer insists something is true and the model agrees, because agreeing is what it was trained to do.
What are the practical steps?
1. Answer only from retrieved sources. The agent's brief limits it to an approved knowledge base and policy library. It does not answer from general knowledge about how businesses usually work. If retrieval returns nothing relevant, that is a signal to stop, not to improvise.
2. Take figures from systems, not text. Balances, order statuses, delivery dates and fees come from live calls to the systems of record at the moment of answering. A help article saying "usually 3–5 working days" is guidance; the order system's dispatch date is the fact.
3. Make "I can't confirm that" a correct answer. The agent must be rewarded in testing for saying it cannot confirm and handing over, not penalised. An agent tested only on whether it answers will learn to answer.
4. Check replies before they send. An output check compares every number, date and commitment in a reply against what the agent retrieved in that conversation. Anything unsupported is removed or the reply is held. This catches the case where retrieval worked but the model added a detail.
5. Cite internally. Each answer is filed with the sources it drew on. Reviewers can see in seconds whether a claim had support.
6. Test for grounding specifically. Build test cases where the honest answer is "not covered" and check the agent says so. Include leading questions where the customer asserts something false. The broader resistance to manipulation is in how to stop customers from tricking a support agent.
7. Fix sources, not prompts. When review finds an invented answer, ask first whether the knowledge base had a gap. Usually it did. Fill it.
What does the agent do when it has no grounded answer?
| Situation | The agent | Stays with a person |
|---|---|---|
| No source covers the question | Says it cannot confirm; offers a handover or a follow-up | The answer, and adding it to the knowledge base |
| Sources conflict | Does not pick one; hands over | Resolving the conflict |
| System unavailable | Says it cannot check right now; offers a callback | Nothing, once the system is back |
| Customer asserts a fact the agent cannot verify | Neither agrees nor disputes; checks or hands over | Judgement where it matters |
An illustrative example
Take a mobile network's chat agent. A customer asks whether their contract allows them to use their allowance in a country they are visiting.
The knowledge base has an article listing included countries, but the customer's destination is not on it and not explicitly excluded either. An unguarded model might answer "yes, roaming is included in most destinations". The grounded agent says it cannot confirm that country is covered, gives the link to the published list, and offers to check with a colleague. The question goes on the knowledge base owner's gaps list. A day later the article is updated to name the country and its charges.
The customer did not get an instant answer. They got a correct one, and the next customer to ask gets it instantly.
Who answers when an invented answer gets through?
The business does, to the customer. Inside the business, the record should show whether the source was wrong or the agent strayed from it, because that decides who fixes what. The question is explored in who answers for an AI agent's mistake. Keeping answers aligned with a changing policy over time is a related discipline, covered in keeping an AI support agent's answers consistent with policy.
Where Pryme fits
In Pryme, every fact reaches the agent stamped with its source through the Pryme Context Protocol, so a claim can be traced to the record it came from or shown to have none. Attest's grounded gate replays your cases and fails any answer that is not supported. More is in the AI support agent that knows when to say no.
Questions people ask
Does a better model stop hallucination?
It may reduce it. It does not remove it, and the controls above are needed with any model.
Should the agent ever answer from general knowledge?
For harmless, general questions such as how to find a tracking number on a parcel label, perhaps. For anything about your products, prices or policies, no.
How do we find invented answers we missed?
Sample conversations, compare figures in replies against systems, and read recontacts where customers say "but the agent told me".