Our piece on the phased trust model answered the question operations leaders ask first: can you trust an AI agent with real work? The answer was structural — authority grows in phases, from Observe to Shadow to human approval to limited autopilot, and no phase is skipped. But that piece left one thread unresolved. Trust phases describe how an agent earns responsibility. They say less about what happens at the boundary — the moment the agent reaches the edge of what it is allowed or able to do, and a person has to take over.
That moment is where deployments actually succeed or fail. Not in the demo, not in the accuracy benchmark. In the 11th hour of a Tuesday, when the agent hits a case it cannot close and something has to happen next.
The two ways escalation fails
Most escalation designs fail in one of two directions, and both are quiet.
The first failure is the dead end. The agent detects an exception, flags it, and the flag goes… somewhere. A dashboard nobody watches. An email inbox checked twice a day. A Slack channel that already has 40 unread alerts. The customer waits. The parcel’s re-attempt window closes. The agent “did its job” — it escalated — and the operation still failed, because escalation was treated as an output instead of a handoff. An alert is not an escalation. An alert is a hope.
The second failure is the flood. The agent escalates so often that the approval queue becomes the bottleneck it was supposed to remove. We described this pattern in why AI projects stall: an agent escalating 60% of cases has not automated the workflow, it has added a review step to it. The team is now doing its old job plus a new one. Within weeks, reviewers start rubber-stamping to clear the queue, and the approval gate exists on paper only.
Dead ends come from designing escalation as an afterthought. Floods come from never defining what shouldn’t escalate. Both are design failures, not model failures — and both are visible in Shadow mode, weeks before they hurt anyone in production, if you know to look for them.
The four parts of a handoff that works
A working escalation has four components. If any one is missing, you have an alert, not a handoff.
1. A trigger that means something. “Low confidence” is not a trigger; it is a feeling the model has. Operational triggers are concrete and agreed in advance: the order value exceeds the agent’s limit. The customer has used words that signal a complaint, not a query. This is the third delivery attempt. The scan data and the customer’s story contradict each other. The refund amount crosses a rupee threshold. Each trigger is a rule your operations lead could read and nod at — because they helped write it.
2. A package, not a pointer. The worst escalations say “please look at ticket #48211.” The human then has to reconstruct what the agent already knew: the order history, the scan trail, the previous contacts and what has been tried. A working handoff carries the case file with it — the evidence the agent gathered, the options it considered, and the specific decision it needs. A useful design target is for the receiving human to decide without reopening every source system. If they cannot, the package needs work.
3. A named owner and a clock. Every escalation class routes to a specific queue with a specific owner and a response-time commitment that matches the operational deadline. An NDR escalation has to land with someone who will act before the courier’s re-attempt window closes — a 24-hour response SLA on a 6-hour window is a dead end with better formatting. If the primary owner doesn’t pick up within the window, the escalation escalates: to a backup, then to a supervisor. Escalations need their own escalation paths.
4. A return path. This is the part almost nobody designs. After the human decides, the case has to flow back: the decision is recorded, the customer hears the outcome, and — critically — the decision becomes training evidence for the agent. A handoff that doesn’t capture the human’s reasoning is a recurring cost. A handoff that does is how yesterday’s escalation becomes next quarter’s automated category. The return path is where escalation pays for itself.
What should never come back to the agent
Designing escalation well also means drawing the line in the other direction. Some categories should route to people permanently, not until the agent improves.
Anything involving anger or distress. A customer who is furious is no longer asking about a parcel, and an agent that cannot feel the difference will optimize for closing the ticket when the job is keeping the customer. High-value exceptions: the bulk B2B order, the VIP account, the refund that exceeds a threshold your finance team set. Novel patterns — the case that matches nothing in the training distribution, which is precisely where an agent’s confidence is least trustworthy. And every case where the data and the customer’s account disagree, because that disagreement is usually a real operational fault wearing a support costume, and someone needs to go look at the actual process.
The honest test is reversibility and blast radius. If a wrong action is cheap to reverse, the agent can earn its way into it through Shadow and approval. If a wrong action is expensive, public, or irreversible, the default is human — and the burden of proof sits on the automation, forever.
Escalation rate is a vital sign, not an embarrassment
Teams often treat a high escalation rate as a deployment failure and try to tune it down. That is backwards. The escalation rate is the single most informative number an operations agent produces.
For example, a category that escalates at 35% in week one and 12% in week eight is telling you the agent is learning the boundary — or that your team is refining it. A category stuck at 40% for two months is telling you the category is wrong: it bundles two different case types, one automatable and one not, and it should be split. A sudden spike in escalations on a process that was stable is often the first signal that something upstream changed — a courier swapped a status code, a sale doubled volume, a policy edit broke a template. In a well-run deployment, the ops lead reads the escalation dashboard the way a plant manager reads gauges. The number is not the agent confessing weakness. It is the operation describing itself.
This is also why escalation design belongs in the earliest project conversations, not the later ones. Draft the escalation map — triggers, owners, clocks and return paths — during Observe and test it in Shadow against what the team actually did with the same cases. Before approval-gated action begins, review whether each handoff reached an owner and produced a recorded decision.
What this does not fix
Good escalation design does not rescue an agent that shouldn’t be deployed. If Shadow mode shows the agent can’t reliably identify the boundary — escalating the routine cases and confidently closing the weird ones — no handoff design will save the deployment. That is a stop decision, and the phased model exists to make it cheap.
It also does not fix understaffing. An escalation path that routes to a supervisor who is already carrying sixty cases a day will become a dead end no matter how elegant the trigger logic. Escalation concentrates human attention on the hardest cases; that attention has to exist. If it doesn’t, the first project is not automation — it is the staffing and queue design around the exceptions.
Finally, it does not make the handoff feel good to the customer by itself. “Let me connect you to a specialist” is still a wait. The design goal is narrower and more honest: when the wait ends, the person on the other end knows everything, decides fast, and the customer never has to repeat themselves. That is what a handoff that isn’t a dead end feels like from the outside.