How to Reduce AI Hallucinations in Customer Service: A Practical Guide

How to Reduce AI Hallucinations in Customer Service: A Practical Guide

To reduce AI hallucinations in customer service, make the agent answer only from approved, current sources, limit what it can claim or do, and verify each answer before it reaches the customer. When the source does not cover the question, the correct behavior is to say so and hand the conversation to a person. No configuration brings errors to zero, so the realistic goal is to make them less frequent and to make every failure visible and fixable.

Key takeaways

• The agent makes fewer mistakes when it looks up approved documents and systems at the moment of the question, instead of relying on the model's memory.
• Bad sources produce bad answers: outdated, duplicated or contradictory documents need to be fixed before any prompt tuning.
• A written scope, permission to say "I don't know" and clear handoff rules are worth more than generic instructions such as "be accurate".
• Verification before sending (checking against the source and against the system) catches errors that a prompt alone does not prevent.
• Error reduction is proven with a set of test questions and a review of real conversations, not with the impression of the person who configured the agent.

Why does an AI agent make up answers in customer service?

A language model produces plausible text from learned patterns. By default, it does not consult your company's policy or the status of a customer's order. When information is missing, the text still sounds confident, and that is where invented answers come from.

In implementation work, the most common causes are predictable:

• The source does not exist: the question is legitimate, but nobody documented the answer.
• The source is old or contradictory: two documents say different things about the same deadline or rule.
• The instruction pushes the agent to help at any cost, without giving it an honest way out.
• The data is dynamic (order, calendar, stock) and was treated as fixed text.
• A tool returns an ambiguous or empty result and the agent fills the gap on its own.

Notice that almost all of these are process and data problems, not model problems. That is why the fix starts outside the prompt.

Which sources should the agent consult to answer?

The most common approach is retrieval-augmented generation, known as RAG: the system searches a trusted knowledge base for relevant passages and hands them to the model together with the question. AWS documentation and Google Cloud's reference architecture describe this pattern. That is official documentation. How each company organizes its knowledge base is implementation experience, and it works best with editorial discipline.

Before switching the agent on, prepare the knowledge base:

• Assign an owner to each document and show a visible review date.
• Keep a single version of each rule. If there are two, the agent will pick one without telling you.
• Separate policy (exchanges, cancellation, warranty) from sales conversation.
• Write exceptions next to the rule, not in a separate file that nobody retrieves.
• Remove everything the agent should not use: drafts, expired promotions, internal procedures.
• For data that changes, such as order progress or available time slots, query the system through a tool instead of copying the data into a document.

If the company does not yet know which questions come up most often, start from the support history. The article on AI customer support: what to automate and what to keep human helps separate what belongs to the agent from what should stay with people.

How do you limit what the agent can say and do?

Limiting the agent reduces the surface for error. An agent that can talk about anything will be wrong about topics nobody reviewed. An agent with a clear scope makes fewer mistakes and, when it does, the mistake is easier to find.

The scope should be written down and verifiable:

• Allowed topics: a short list tied to the approved sources.
• Forbidden topics: legal advice, refund exceptions, diagnoses, any promise not covered by policy.
• Refusal reply: a neutral text explaining that the matter will be passed to a person.
• An explicit rule that not knowing is an acceptable answer, and that handing off is better than filling the gap with a guess.
• Read-only tools at the start. Actions that change data (cancel, reschedule, refund) come later, with confirmation.

For the wording of the instructions, see how to write instructions for an AI support agent. One caution: a natural-language instruction guides the model but does not guarantee obedience. That is why it has to be paired with verification.

How do you verify an answer before it goes to the customer?

Verification is the layer that separates a demo agent from an agent in operation. It can be simple, and it should be proportional to the risk of the topic.

• Grounding check: a second pass confirms that every claim in the answer is supported by the retrieved passages. If it is not, the answer is blocked or rewritten.
• System check: order numbers, dates, product names and statuses are compared with what the tool returned, not with what the model wrote.
• Deterministic rules: a simple filter blocks promise language, such as guaranteed delivery times or outcomes, when no policy authorizes it.
• Safety threshold: if the search finds no relevant passage, the agent does not improvise; it hands off.
• Logging: each answer stores the question, the sources used and the decision taken, for later audit.

The article on guardrails for AI agents, with input, output and action controls details how to organize these layers. The OWASP list of risks for applications built on language models also treats incorrect answers and overreliance on the model as risks to manage, which reinforces the point that checking should not live only in the prompt.

Step-by-step plan to reduce wrong answers

This is a lean roadmap for a first flow, for example delivery time and exchange questions on WhatsApp.

• Step one: collect the most frequent real questions and note how the team answers them today. This is your baseline for comparison.
• Step two: for each question, find the official source. Where there is none, write one or take the question out of scope.
• Step three: resolve contradictions between documents and record an owner and a review date.
• Step four: define the scope, the forbidden topics and the refusal reply.
• Step five: connect the sources through retrieval and the dynamic data through read-only tools.
• Step six: add the checks (grounding, comparison with the system, blocking rules).
• Step seven: define when the agent hands off and what goes to the person: conversation summary, original question and sources consulted.
• Step eight: build a set of test questions, including trap questions outside the scope and questions with an ambiguous rule.
• Step nine: run a restricted pilot, with full logging and frequent review of the conversations.
• Step ten: based on the logs, decide whether to expand, adjust or stop.

Illustrative scenario: exchanging an opened product

Illustrative scenario: an online store receives a WhatsApp message from a customer who wants to exchange a product whose packaging has already been opened. The store's policy allows exchanges in general, but has an exception for a certain product category.

Without controls, the agent answers based on what seems reasonable and confirms the exchange, because the instruction asks for friendliness and nobody told it that it may refuse. The customer is promised something the store will not honor.

With the controls described above, the flow changes. The agent retrieves the policy passage and the exception passage. It looks up the order through a read-only tool and confirms the product category. The grounding check verifies that the answer cites the correct condition. If the product falls under the exception, the agent explains the rule and offers to pass the case to a person for review. If the search does not return the policy, it does not answer on its own and hands off with a summary of the conversation. The error has not disappeared as a possibility, but it has become unlikely and traceable.

How do you measure whether wrong answers actually went down?

Without measurement, any improvement is an impression. Three practices work together.

The first is the test set. It collects known questions, each with the expected answer or the expected behavior (answer, refuse or hand off). Every change to a source, prompt or model is tested against it before going live. Anthropic's guide to agent evaluations and OpenAI's evaluation guide describe this logic of repeatable tests.

The second is sampled review of real conversations. Someone from operations reads the conversations, marks what was wrong and identifies the cause: missing source, conflicting source, poorly defined scope or a verification failure. That classification directs the fix.

The third is evaluation assisted by another model, useful for widening coverage as long as it is calibrated against human review. The article on LLM as a judge for evaluating agent responses explains how to use that method without trusting it blindly.

Agree with the company on what counts as a wrong answer and what level is acceptable for each type of topic. A mistake about opening hours and a mistake about a contract condition do not weigh the same.

How the map, limit, pilot and hand off method applies

In Juan Carlo's work, reducing wrong answers follows the same sequence as any agent project. Map means understanding the current process, the real questions and the quality baseline before automating. Limit means restricting data, sources and actions, with read-only tools at the start. Pilot means running a real flow with logs and a success metric agreed in advance. Hand off means defining when the conversation passes to a person and delivering the documented operation, so the company can decide whether to expand, adjust or stop.

If the support flow involves personal data, treat the subject carefully from the design stage: Brazil's LGPD requires attention to purpose and data minimization, and the ANPD is the official reference for guidance. For a broader view, see LGPD and artificial intelligence for companies: what to do.

Frequently asked questions

Can an AI agent's hallucinations be eliminated completely?

There is no guarantee of elimination. What you can do is reduce the frequency with approved sources, a limited scope and verification, and handle the remaining errors with human handoff and continuous review. Anyone promising zero errors is promising more than the technology supports.

Is a good prompt enough to stop the agent from making things up?

It is not enough. The prompt guides behavior, but the model can ignore it in edge cases. The combination of a reliable source, tools for dynamic data, output verification and handoff rules is what makes the agent robust.

Does RAG solve the problem of wrong answers?

It helps a lot, because it gives the agent reliable material to consult, but it does not solve the problem on its own. If the knowledge base is outdated, contradictory or incomplete, the agent retrieves and repeats the error. The quality of the knowledge base and the check on the answer are still necessary.

Where should a company start if it does not have organized documentation yet?

Start with a few frequent, low-risk questions, write the official answers with an owner and a review date, and use that as the basis for the pilot. Leave out of scope whatever has no source yet and route those cases to the team. The knowledge base grows as the pilot shows which gaps appear most often.

Sources

• AWS: What is retrieval-augmented generation
• Google Cloud: retrieval-augmented generation architecture
• Anthropic: Demystifying evals for AI agents
• OWASP Top 10 for LLM Applications