Escalation Management With AI Agents: The Handoffs 3 Failures Missed

A Canadian tribunal ordered Air Canada to pay C$650.88 in damages because its chatbot described a refund rule the airline did not have. The money is trivial. The lesson is not: escalation management failed before any human knew a conversation had gone wrong. Read the public record on Air Canada, Cursor and Klarna side by side and one pattern repeats. The bot never lacked an escalation button. It lacked a reason to press it.

The short answer. Escalation management for AI agents is the set of rules that decides when a bot stops answering and a human takes ownership. The documented failures show the rules must fire on what the bot is about to say, such as a policy, a refund or a legal right, and not only on what the customer asks for.

What escalation management means once an AI agent answers first

In a traditional contact centre, escalation means moving a case from a frontline agent to a specialist or a supervisor. The frontline agent decides, using judgement, training and a written matrix. Everyone in that chain can recognise when they are out of their depth.

An AI agent changes the first link. It answers every contact, at any hour, in any volume, and it does not experience doubt. A language model produces a fluent answer whether or not a true answer exists. That is the property every case in this post turns on.

So the escalation question moves. The old question was who handles the hard cases. The new one is how the system knows a case is hard, when the thing handling it cannot feel difficulty. Your escalation design has to supply that missing sense from outside the model.

Most support teams inherited escalation rules written for humans. They key on customer signals: the customer asks for a manager, the customer is angry, the ticket is old. Those still matter. They miss the failure mode that produced every headline below, which is a calm customer receiving a confident, wrong answer.

The rest of this post reads three documented cases for the exact moment a handoff should have happened. Each case maps to a different trigger. Together they make a checklist you can test against your own deployment this month.

Air Canada: the chatbot stated a policy nobody had checked

In November 2022, Jake Moffatt asked Air Canada's website chatbot about bereavement fares after his grandmother died. According to the screenshots he supplied, the bot told him he could book now and "submit your ticket for a reduced bereavement rate" within 90 days of the ticket being issued. That account comes from Manatt's summary of the case.

The airline's actual policy did not allow that claim after travel. Moffatt flew, applied, and was refused. He took the case to the British Columbia Civil Resolution Tribunal and won on negligent misrepresentation.

Air Canada's defence is the part every support leader should read twice. The tribunal described the airline as suggesting "the chatbot is a separate legal entity that is responsible for its own actions", per McCarthy Tétrault's analysis of the decision. The tribunal called that "a remarkable submission".

Its reasoning was blunt. It found the airline did not explain "why customers should have to double-check information found in one part of its website on another part". It also said: "It should be obvious to Air Canada that it is responsible for all the information on its website. It makes no difference whether the information comes from a static page or a chatbot."

The trigger that should have fired

Two signals were present in that conversation. Either one should have routed it to a human or to a verbatim policy extract. The first was content: the bot was about to state an eligibility rule with money attached. The second was context: a bereaved customer asking about a compassionate fare is the definition of a high-stakes, low-volume conversation.

Neither signal depends on the customer asking for help. Moffatt did not complain. He believed the answer, which is exactly what a good answer is supposed to achieve. An escalation design that waits for the customer to be unhappy would have scored this conversation as a success.

My position is that any bot response which states a rule about money, eligibility or legal entitlement must either quote a retrievable policy document or hand off. Paraphrase is where the liability lives. The ruling did not create that principle, but it removed the comfortable fiction that a vendor's model is somehow a separate speaker. How liability is split between you and your AI vendor once that happens is covered in the breakdown of AI agent liability caps and remedies.

Cursor: an incident was handled as a support ticket

In April 2025, users of the coding tool Cursor started being logged out when they switched between machines. One user wrote to support and received an email from "Sam" saying the logouts were "expected behavior" under a new login policy, as reported by Fortune on 19 April 2025.

There was no new policy, and no human behind the email. Sam was an AI support bot. The explanation was invented. The user posted the exchange on Reddit and Hacker News, and Fortune reported that users began announcing cancellations.

Cofounder Michael Truell then posted on Reddit acknowledging an "incorrect response from a front-line AI support bot". He also wrote, "Apologies about the confusion here." Fortune reported the company was investigating a bug that logged users out. Cursor did not respond to Fortune's request for comment.

Three triggers, all silent

This case is richer than Air Canada because three separate escalation triggers should have fired, and none did.

The first is the policy trigger again. The bot asserted a rule that did not exist in any document. A grounding check against the published terms would have found nothing to support it.

The second is an account-state trigger. A customer saying "something changed in my account and I did not change it" is reporting a possible defect or security event. That belongs to engineering or an on-call owner, not to a FAQ answer. The bot treated a symptom as a question.

The third is a cluster trigger. Logouts were hitting multiple users. A system that counts near-identical complaints in a short window, and pages a human when the count spikes, turns a support thread into an incident before Reddit does. If you run agents in production, this is the same discipline as an on-call runbook for agent failures, pointed at your support queue.

The detail I find most damaging is the name. "Sam" reads as a person. A customer who believes a human checked the policy has no reason to ask for one. Disguising the bot did not just mislead the user. It disabled the customer's own escalation instinct.

Klarna: the escalation path was a cost line, not a promise

Klarna is the case people cite most and read least carefully. In February 2024 the company said its AI assistant had handled two-thirds of customer service chats in its first month. It said the assistant was doing the work of 700 full-time agents, according to CX Today's report of the announcement.

The same report gave the company's other claims. Resolution time had fallen from 11 minutes to 2 minutes, customer satisfaction had held steady, and Klarna estimated a $40 million profit improvement in 2024. The assistant ran in 23 markets.

Then in May 2025, Sebastian Siemiatkowski told Bloomberg that the AI was cheaper but delivered "lower quality" service, as reported by Entrepreneur on 9 May 2025. "Really, investing in the quality of human support is the way of the future for us," he said. Klarna began recruiting human agents again.

What Klarna actually changed

Read the quote that matters most. "I just think it's so critical that you are clear to your customer that there will always be a human if you want." That is not a staffing statement. It is an escalation policy, stated publicly by the chief executive.

The February 2024 launch already said customers could still choose live agents, per CX Today. So the human path existed on paper. What changed in 2025 was its standing. It moved from an option the cost model tolerated to a promise the brand made. Those two things produce very different queue behaviour, because a tolerated option gets quietly starved of capacity.

Klarna is not a story about AI failing. Its own numbers say the assistant resolved most chats faster. It is a story about what happens when the human path is sized as the residual of an automation target. The staffing consequences of that sizing are worked through in the analysis of what is left for humans after deflection.

Read the last column. In none of these cases did the deploying organisation's own escalation system catch the error first.

The common failure in AI customer service escalation

Put the cases together and the pattern is uncomfortable. In every one, the error was discovered outside the system. A tribunal, a Reddit thread, a reporter, a quality review months later. The escalation design never saw it.

The evidence from regulators points the same way. The US Consumer Financial Protection Bureau's 2023 report on bank chatbots is the clearest case, per the CFPB Issue Spotlight. It described customers stuck in "continuous loops of repetitive, unhelpful jargon or legalese without an offramp to a human customer service representative". It also warned that a bot "may fail to recognize that a consumer is invoking their federal rights".

That second warning is the Air Canada problem in a different industry. Recognising a dispute, a rights claim or an entitlement question is a classification task. If your bot cannot do it reliably, your escalation rules cannot depend on it doing it.

The Markup tested New York City's MyCity chatbot in March 2024, according to The Markup's investigation. It found the bot giving business owners answers that contradicted city law, including on whether landlords must accept housing vouchers. A legal-rights question is the clearest possible escalation trigger. The bot answered it anyway.

Most escalation logic in support software keys on the customer: sentiment, explicit requests, repeated contacts. Those signals fire when the customer already knows something is wrong. A confident wrong answer to a calm customer produces no such signal. The customer thanks the bot and leaves.

Customer anxiety about this is measurable. Gartner's survey of 5,728 customers found 64% would prefer companies did not use AI for customer service. Coverage of the release reported that the most common worry was that it would become harder to reach a person. That fear is the escalation path, described by the people who use it.

An escalation design checklist built from the failures

Each item below exists because a documented case shows what happens without it. None needs a new vendor. Most need a rule, an owner and a test.

Output-side triggers: watch what the bot is about to say

This is the layer the cases say is missing. Before a response is sent, classify it. Does it state a rule, a price, a refund, an eligibility condition, a deadline or a legal position? If yes, it must cite a retrieved source document, quoted rather than paraphrased. If no source is retrieved, the bot says it will connect a person and does so.

Treat the absence of a source as the trigger. That one rule would have caught Air Canada, Cursor and MyCity. It costs some deflection, and that is a price worth paying deliberately.

System-side triggers: watch the queue, not the conversation

Count near-identical complaints across conversations in a rolling window. When reports of the same symptom spike, page a named human owner and freeze the bot's explanatory answers on that topic. Route any "something changed in my account" report to a person or an incident channel by default.

The Cursor case is the argument for this layer. One conversation looked like a question. Many conversations were an outage.

Customer-side triggers: keep them, and make them a promise

Honour any request for a human on the first ask. Detect repeated unresolved turns and offer the exit before the customer has to find it, which is the CFPB's doom loop in reverse. Disclose that the agent is AI, and never give it a human name. The disclosure trade-offs are argued in full in the case for and against AI disclosure to customers.

The handoff itself: context travels, the clock starts

A trigger that fires into an empty queue is worse than no trigger, because it adds a broken promise to a wrong answer. Pass the full transcript and the bot's retrieved sources to the human, so the customer never repeats themselves. Set a response time target for escalated contacts and staff to it.

Then close the loop. Every escalation caused by an output-side trigger is a labelled example of something the bot could not ground. Review a sample weekly and fix the knowledge base, not just the ticket. The architecture choices behind this kind of review sit in the post on designing human in the loop as architecture.

Where this argument is weakest

Three objections deserve a straight answer, and one of them partly wins.

Four cases are not a dataset

Public failures are the ones that went viral or reached a tribunal. Millions of AI support conversations resolve correctly and leave no record. Building a checklist from headline failures risks designing against the memorable rather than the frequent. I cannot tell you how often the policy-assertion failure happens in your queue. Nobody has published that rate, and the vendors who could measure it have no incentive to. Treat this checklist as a set of hypotheses to test against your own transcripts, not as a measured ranking of risk.

Output-side triggers cost real deflection

This is the objection that partly wins. A strict "no source, no answer" rule will hand off conversations the bot would have answered correctly. For a high-volume, low-stakes product, that cost may outweigh the risk. Klarna's own reported numbers show an assistant resolving most chats faster than humans did. My view is that the rule should be strict for money, eligibility and rights, and relaxed elsewhere. Where exactly that line sits is a commercial judgement, and the handoff cost is modelled in the cost per ticket comparison of human and AI agents.

Some evidence in this post is also thinner than I would like. The Klarna figures are company claims reported by trade press, and the Air Canada quotations come from legal commentary rather than the decision text, which could not be opened during research.

Frequently asked questions

Where to start with your handoff rules

Pull 50 recent bot conversations in which the bot stated a rule, a price or a deadline. For each one, check whether the statement matches a document you could point to. The share that does not is your unsourced assertion rate, and it is the number this post could not give you.

Then run one fire drill. Ask your bot for a human, in the plainest words you can, and time how long a person takes to reply with your transcript in hand. If the answer is "never" or "after I repeated myself", fix that before you touch anything else.

Related reading