← All guides · Support agents in production

What to Do When an AI Support Agent Gives a Customer a Wrong Answer

Part 11 of Support agents in production · 1,614 words · ~7 min read · published 2026-10-25 · updated 2026-10-25 · Markdown variant

What to do when an AI support agent gives a customer a wrong answer: classify the error, contain one intent, find every affected conversation in traces, correct the customer, weigh honouring or reversing the commitment, and add a fixture.

Part of the AI Customer Support Agent in Production: Escalation, Policy, Tickets and Measurement guide.

When an AI support agent gives a customer a wrong answer, contain that one request type first, find every other conversation with the same fault, have a human correct each affected customer, and turn the case into a regression fixture. This is the own-mistake sub-article of the AI customer support agent in production cluster. The AI customer support agents reference (updated 2026-09-13) names the danger: a confident wrong answer, in the brand's voice, to a customer who must then be won back.

Reading key: a named reference is the source; anything else is the author's inference. The corpus holds no legal guidance on agent commitments, so each honour-or-reverse choice below is a decision aid to check with counsel, not legal advice. Triage, trace freezing and the post-mortem are in incident response runbooks for AI agents, and fixture mechanics are in turning an incident into an evaluation test case; this article covers what changes when a customer heard the wrong output.

Which wrong answers need an incident response?

Three kinds of wrong answer need an incident response: a wrong statement of policy, a commitment the agent had no authority to make, and a wrong action taken through a tool. The split is inference, because each kind leaves the customer holding something different. The support reference says the agent must never commit the company beyond documented policy, and the reliable tool calling reference (updated 2026-09-29) defines reliability as schema conformance, which as inference says nothing about permission.

Detection signals that should open an incident

Three signals the cluster already covers should open an incident: escalations, review-queue samples and customer complaints. Route them into an incident path instead of building new detectors.

• Escalations. A human has to undo what the agent said. The trigger log is in support agent escalation triggers; as inference, add an "agent was wrong" tag.
• Review-queue samples. A reject on a promise or an action is an incident candidate, not only a fixture candidate. See support agent human review queues.
• Complaints and repeat contact. A customer quoting the bot back, or the denied-confirmation and repeat-contact cells in support agent quality measurement.

A wrong answer with a one-off cause is a case; one that reproduces from the same inputs is an incident, so triage it with the runbooks article (inference).

How do you contain one request type without switching the agent off?

Contain a wrong-answer incident by routing the affected request type to humans through the policy-boundary escalation path while the rest of the agent keeps running. The support reference sends policy-boundary matters to a person and advises launching on a narrow set of request types, so narrowing back is the same lever in reverse. The ladder below, narrowest first, is inference.

Preserve the traces first, kept accessible independent of production, as the shipping agents to production checklist (updated 2026-08-13) says. If you do roll back, use the composite version tag from agent rollout and rollback.

A prompt line such as "never promise X" is an addition, not the containment, because it relies on the model's discipline while a routing rule or tool gate is structural, the distinction the support reference draws. Name the incident in the handoff reason so humans know why the type arrives. As inference, a wrong action caused by injected input may also call for the containment and evidence steps in how to respond when an AI agent takes a harmful action; that article does not cover injection.

How do you find every conversation with the same wrong answer?

Search the preserved traces for the fault's signature across the whole window since the cause went live, not only for the conversation that was reported. The shipping checklist's composite version tag (code, prompt, model pin, tool contracts) gives you a version field to filter on. The signature depends on the class (inference):

• Wrong action: the tool name plus an argument pattern, which is exact and cheap.
• Wrong statement: the retrieved document or version the agent quoted, since a phrase search misses paraphrases. Retrieval is a span, per the agent observability reference.
• Unauthorised promise: often no tool call exists, so combine a phrase search with a missing escalation for that request type, then read the hits.

A runnable sketch on a small export, with placeholder field names to adapt to your trace store:

# Sample export: one JSON conversation per line (placeholder layout)
cat > traces.jsonl <<'EOF'
{"conversation_id":"c_01","started_at":"2026-10-20T09:00:00Z","version":"v7","spans":[{"tool":"issue_refund","args":{"amount":40,"order_total":30}}]}
{"conversation_id":"c_03","started_at":"2026-10-17T10:00:00Z","version":"v6","spans":[{"tool":"issue_refund","args":{"amount":50,"order_total":30}}]}
EOF
# Signature: a refund above the order total, with no date filter on purpose
jq -c 'select(any(.spans[]; .tool == "issue_refund" and .args.amount > .args.order_total))
  | {conversation_id, started_at, version}' traces.jsonl

The v6 hit shows the fault predates the release you suspected, so the earliest match sets the window. Keep the matches as conversation IDs with what each customer was told or charged; that list is the next step's work queue. Trace content is customer data, so apply redacting sensitive data from agent traces before sharing the list.

Correcting the customer and deciding whether to honour or reverse

A human should correct each affected customer, and honouring or reversing what the agent committed to is a business and legal decision this site can frame but not settle. As inference, a person writes the correction, because the support reference routes commitments outside policy to a person instead of letting the model negotiate. State what was said, what is correct and what happens next; see support agent tone and brand voice for wording.

Whether a company is legally bound by its agent's statements is a question for counsel; the table is inference, not legal advice.

Four factors do the work (inference): reliance, reversibility, size against policy, and whether it is a pattern. For a pattern, set the rule once for the whole group, because case-by-case handling invites a second grievance. The shipping checklist puts irreversible actions behind a durable human approval gate logging approver identity and timestamp; a remediation is also a state change, so log the decision the same way.

Turning the case into a regression fixture

Turn the case into a fixture by asserting the structured fact that was wrong, adding paraphrased variants of the request, and running it several times. Freezing, redacting and red-then-green belong to the incident-to-eval-fixture loop; the support-specific part, both inference, is what to assert and which layer should have stopped the error.

The evaluating AI agents reference (updated 2026-09-27) says exact match against a reference is the most reliable check for tool calls and that LLM judges carry position, verbosity and self-preference biases, so prefer structure over judged prose. The guardrails reference lists groundedness as an output check and parameter ranges as an action check.

Three habits follow (inference):

1. Add variants. The customer's exact wording will not recur, so include paraphrases.
2. Run it repeatedly. The reference notes that one prompt can produce different tool sequences and defines pass^k as all k trials succeeding, so one pass does not prove the fix.
3. Tag the source as customer-reported, apart from review-queue fixtures.

Close the blameless post-mortem the shipping checklist calls for with one shipped artifact: a fixture, a check at that layer, or a corrected source document.

What ChangeGamer can verify first-hand

ChangeGamer runs no support agent, so as of 2026-10-25 it has no wrong-answer incident and none of the guidance above comes from operating one. One verifiable comparison comes from its build: changegamer/src/lib/articles.ts runs a validate() pass over every entry in ARTICLES on each npm run build, checking every in-body /resources/ and /articles/ link, not a sample. It throws on the first violation and names the offending slug. Reading that file confirms it. For incident searches, check the whole population and return every match in one pass.

#customer-support #incident-response #policy #traces #fixtures #agents #production