When your agent is wrong for the first time in front of users: what to say, what to fix

Picture this: three days after go-live, the support agent you deployed for a consumer electronics retail chain tells a user they can return an item within 60 days. The real policy is 30 days. The user takes a screenshot, and that screenshot is now sitting in the customer’s leadership chat channel.

Every FDE who deploys agents should prepare for this moment in advance. That the model will sometimes be wrong is close to certain. The real question is what you say and what you fix in the first few hours, and how you keep the customer wanting to expand the deployment rather than pull it back.

That makes this a skill worth practising before go-live, not one to learn once the incident has happened. If you are preparing for FDE interviews, an incident you handled well is also a story worth having ready.

The agent’s mistake is the customer’s own word

Before you draft any message, you need to understand who is responsible. In Moffatt v. Air Canada, the Civil Resolution Tribunal, British Columbia’s civil tribunal, rejected the argument that the chatbot was separate from the airline. The decision states that the chatbot, although interactive, was still just a part of Air Canada’s website.

The tribunal went further: the airline is responsible for all the information on its website, and Air Canada had not taken reasonable care to ensure its chatbot answered accurately.

The consequence for FDEs is clear. “AI sometimes hallucinates” excuses nothing. To end users, the agent speaks for your customer. To the customer, the agent speaks for you.

The case of Anysphere, the company behind Cursor, shows that an agent can invent an entire policy. Its support bot, named Sam, asserted that each subscription could only be used on one device, calling this a core security policy.

No such rule existed, but users had heard it from the product’s own support channel.

The first hour: contain, measure, then speak

The first job is to contain, not to explain. In the retail example, you switch off the returns topic alone: every question containing “exchange”, “return” or “refund” is routed to a human. The agent keeps running for every other topic, so the customer does not have to choose between “turn it all off” and “leave it as is”.

The second job is to measure the scope. Search the logs for every returns conversation since go-live and filter for answers that mention a number of days. The result is the list of people to contact, and it is also the first number the customer’s owner of the deployment will ask you for.

Only now do you speak. One customer-service AI vendor’s guidance is marketing material and should be read with caution, but the three-part formula it suggests for a message after a wrong answer is sound: acknowledge what happened, correct the information, and offer redress tailored to each person.

Drop any part and that part of the message fails.

Anysphere’s correction is a model worth studying because it is short. It said plainly that what the bot said was wrong: users are free to use Cursor on multiple machines. It also said the company was looking into the real cause, possibly a login session bug arising from security updates. No hedging, no blaming “artificial intelligence”.

For the retail example, the first-hour message to the customer’s owner might look like this:

Subject: Agent gave the wrong return window, contained at [time]

What happened: from [date] to [time], the agent said the return window was 60 days.
The correct policy is 30 days.
Scope: [N] conversations, list attached.
Done: the returns topic has been routed to staff; all other topics are running normally.
Proposal for affected users: [redress], needs your approval.
Next: root cause and fix sent by [time]; monitoring figures sent after 72 hours.

Note the line “needs your approval”. How to compensate users is the customer’s business decision. You propose; the customer decides.

Fix the system, don’t look for someone to blame

Once the heat dies down, the pressure to find out “who broke it” will arrive. Google’s SRE book defines a truly blameless postmortem as one that focuses on contributing causes without blaming an individual or team. It says you cannot “fix” people, but you can fix systems and processes to help people make the right choices.

The reason is not just about being decent. The SRE Workbook warns that a culture of blame makes teams risk-averse for fear of being publicly named, and they may hide the very details needed to stop the error recurring. If the customer’s engineers fear blame, you will never learn who uploaded which document to the index.

Applied to the retail example, suppose that tracing back you find three contributing causes. An old policy document stating 60 days was still in the RAG index. The eval suite had no case on the return window. There was no alert when the agent stated a policy figure.

Each cause needs its own fix: remove the old document and tag policy documents with an effective date, add an eval case for each figure, and build a check that compares every figure the agent states against the source of truth.

The mistakes that make the first error the last

The most common mistake is blaming the model. The Air Canada case shows the argument does not stand up before a tribunal, and in a meeting room with the customer it is weaker still. The second mistake is the opposite: blaming one person. You get a name, but lose the facts you need to fix things.

The third mistake is fixing it quietly and pretending nothing happened. Users who received the wrong information are still acting on it. The fourth is declaring “done” before you have the figures, and then the error comes back the following week.

The fifth is offering everyone the same blanket compensation, when someone who lost money and someone who merely misread need two different responses.

Trust returns with measurements

An apology opens the door, but trust only returns when the customer sees the figures. Anthropic’s September 2025 postmortem on three quality incidents is an example of owning a mistake directly. It restated the company’s commitment to quality, then wrote that in the recent incidents it had fallen short of that standard.

The more instructive part is the concrete fix to detection. Anthropic committed to running quality evaluations continuously on its real production systems to catch errors, not only before release. For FDEs, that is the difference between “the evals passed on go-live day” and “the evals still pass this morning”.

The vendor guidance mentioned above recommends monitoring the faithfulness score of the affected topic cluster for 48 to 72 hours after the fix to make sure it holds. In the retail example, you reopen the returns topic only once the new eval cases pass. Then you send the customer the 72-hour chart along with a one-page postmortem.

Don’t keep the postmortem within your team. The SRE Workbook recommends proactively sharing postmortems as widely as possible, including with customers. A document that sets out the cause, the fix and the figures usually reassures the customer’s owner more than any reassuring phone call.

The figures in that runbook are also how to describe the incident on a CV or in an interview: how quickly you contained it, how many conversations were affected, what the new eval cases caught afterwards. A generic “handled an incident” is something nobody remembers.

An agent’s first mistake is the first time the customer sees you work when things are not going smoothly. If you contain it fast, tell the truth and bring the figures, many customers will trust you more than they did before the incident.