Agent Escalation: When to Hand Off to a Human vs. Keep Handling

June 23, 2026 · updated June 25, 2026 · How Claude Actually Works (part 25)

▶ Watch on YouTube & subscribe to The Stack Underflow

Most agent escalation logic in the wild falls into one of two opposite failure modes. The agent escalates the moment a customer types “I’m so frustrated” — routing a fully solvable problem to the human queue and training customers that performing frustration earns faster service. Or the agent calmly processes “please close my account” as a routine task and executes an irreversible action with no human gate at all. Both failures come from treating escalation as a vibe check rather than a deterministic signal. The fix is the same for both: replace “does this feel escalation-worthy?” with an explicit, auditable checklist.

This matters structurally, not just operationally. Anthropic’s 2025 research on long-running agents found that experienced users interrupt Claude in roughly 9% of turns — more than new users, not less — because they understand where the agent’s judgment genuinely falls short and where it does not (Anthropic, 2025). Escalation is a skill, and it can be designed. Here is how.

The one-sentence version: Escalate on policy, complexity, risk, or explicit request — never on sentiment — and hand off a structured summary card, not the raw transcript.

The two opposite failure modes

Before defining the triggers, name the poles you are trying to stay between. They are mirror images of the same root error: routing on the wrong signal.

Both are routing errors. The calibration problem is identical in each case: something other than the correct four signals is driving the decision. Fix the signal, not the threshold.

The four escalation triggers

Escalate on exactly four signals. Anything outside this list stays with the agent.

ESCALATION DECISION TREE
─────────────────────────────────────────────────────
Incoming turn
      │
      ▼
  Explicit request for human?
      │ YES ──────────────────► human queue + summary card
      │ NO
      ▼
  Policy gate tripped?
      │ YES ──────────────────► human queue + summary card
      │ NO
      ▼
  Resolution path exhausted / multi-system failure?
      │ YES ──────────────────► human queue + summary card
      │ NO
      ▼
  Security, compliance, or fraud signal?
      │ YES ──────────────────► human queue + summary card
      │ NO
      ▼
  Agent keeps handling
─────────────────────────────────────────────────────

Trigger 1 — Explicit request

The customer says “I want a human.” Route immediately. No clarifying question, no one-more-tool-call attempt to resolve first. This is the clearest signal in the system and the one you should never second-guess. Asking “are you sure?” or “can I try one more thing?” adds friction to the only unambiguous instruction the customer can give you. Honor it.

Trigger 2 — Policy

Certain actions trip a hard gate by rule, not by agent discretion. Refunds over a dollar threshold, account closures, plan downgrades — these are defined in policy and the agent does not adjudicate them. The rule fires, the route happens.

# Pseudo-code — the policy gate
if action in POLICY_GATES:
    escalate(reason="policy", action=action)

The agent does not evaluate whether this particular account closure seems risky. Policy is mechanical on purpose. Consistent enforcement requires extracting the judgment call entirely — if the agent is deciding case by case, you no longer have a policy, you have an opinion.

Trigger 3 — Complexity

A multi-system failure the agent cannot resolve. Not “this is taking several tool calls” — that is just a long conversation. Complexity means the resolution path is genuinely exhausted: the agent has used the tools available to it and cannot reconcile the state of the systems involved. That distinction matters. Long does not equal complex, and routing on conversation length floods the queue with solvable problems.

Trigger 4 — Risk

Security events, compliance scenarios, suspected fraud, and PII exposure go to a human. These are not judgment calls the agent should make autonomously. When the agent detects something that touches regulatory scope or security posture, it escalates with context — it does not decide whether the signal is serious enough.

The non-trigger: sentiment

This section deserves its own heading because sentiment routing is the most common and most expensive mistake in production escalation systems.

Sentiment is not a routing signal. A frustrated customer with a solvable problem should still get the agent. Routing on tone — anger, impatience, repeated messages — produces a broken system in three specific ways:

The right read on frustration is different: it is a quality signal you should instrument and learn from, not a handoff trigger. A frustrated customer whose problem gets solved by the agent is a better outcome than a frustrated customer who waits 20 minutes for a human to solve the same problem. The sentiment matters for your quality review pipeline. It does not belong in the routing decision.

Note: even if your sentiment classifier is highly accurate, that does not fix the problem. The issue is not classification accuracy — it is that frustration does not imply an unsolvable problem. You would be routing accurately on the wrong variable.

What the handoff actually passes

The trigger fired. Now what does the agent hand to the human?

Not the raw 40-message transcript. A structured summary card the human can act on in ten seconds:

ESCALATION SUMMARY CARD
────────────────────────────────────────
Customer:    [name / account ID]
Requested:   [what they want]
Attempted:   [what the agent tried]
Blocked by:  [what prevented resolution]
Trigger:     policy | complexity | risk | explicit
────────────────────────────────────────

That is the handoff. The human reads it, has context, and acts. Handing over a raw transcript forces the human to do the synthesis work the agent should have already done — reconstructing the thread into an actionable state. The summary card is the agent finishing its job, not dumping state and exiting.

The format has a secondary benefit: because the trigger field is typed (policy / complexity / risk / explicit), your escalation logs become auditable. You can query “how many policy escalations in the last 30 days, broken by action type” and get a real answer. Raw transcript handoffs give you no such signal.

How this connects to the Messages API

If you are building the escalation layer on Claude directly, the Messages API stop_reason field gives you structured signal you can route on. As of the current API specification (platform.claude.com, 2026), the relevant values are:

A pause_turn stop reason is worth treating as a complexity signal in your escalation router — it means the agent’s execution was interrupted before it could close the task. Combine it with your resolution-path tracking to decide whether to continue or escalate.

For pre-tool-use hooks in Claude Code (the mechanism for gating irreversible actions before they fire), see Claude Code Hooks Explained. The hook fires before the tool executes, which is exactly the right place to apply your policy gate check.

How to apply this in production

Concrete steps to move from sentiment-based (or no) escalation to the four-trigger model:

1. Write the policy gate list explicitly. Every action that should be a hard hand-off by rule — not by agent discretion — goes in this list. “Refunds over $500” is a valid entry. “Situations that feel sensitive” is not.

2. Define resolution-path exhaustion for your domain. What does “I have used all available tools and cannot reconcile the state” actually look like in your system? Define it precisely enough to code it. If it requires the word “complex,” keep refining until it does not.

3. Instrument the trigger field on every escalation. Log which of the four triggers fired. This is your primary signal for tuning the system — both the policy gate list and the complexity definition will need adjustment based on real escalation patterns.

4. Build the summary card as a prompt template, not an afterthought. Give the agent explicit instructions to produce the WHO / WHAT / TRIED / BLOCKED structure when escalating. Test that a human who knows nothing about the prior conversation can read it and act in under 30 seconds.

5. Never put sentiment in the router. Route it to your quality review pipeline instead. Monitor it. Use it to find patterns in what kinds of problems produce frustration. Fix those problems. Do not use it to trigger handoffs.

Common misconceptions

“A long conversation means the agent is struggling and should escalate.” Length is not a proxy for complexity. A long conversation that is progressing toward resolution should stay with the agent. Complexity means the resolution path is exhausted, not merely extended. Routing on length fills the human queue with solvable problems that simply needed more turns.

“Escalating on frustration is safer — better to err on the side of human attention.” It feels safer but produces a broken system. The human queue is a finite resource. Flooding it with resolvable issues does not make the system more careful — it delays the cases that genuinely need human judgment and degrades the service level for everyone.

“The agent should hand over the full conversation so the human has complete context.” Full context is not the same as raw transcript. A 40-message thread is noise until synthesized. The summary card is complete context, compressed to what the human needs to act. Handing the raw transcript is the agent offloading its job to the human.

“Sentiment analysis being wrong is why we should not use it for routing.” The problem is not classifier accuracy — it is that frustration does not imply an unsolvable problem. Even a perfect sentiment detector would be the wrong input to the routing decision. The routing decision should be grounded in task state, not emotional state.

Frequently asked questions

What if a customer is both frustrated AND has a policy-gate issue?

Route on the policy trigger. The sentiment is irrelevant to the routing decision — you would have escalated anyway. The trigger field in your summary card and your escalation logs should read “policy,” not “frustration.” This keeps your metrics clean and your escalation data meaningful for future tuning.

How granular should the policy gate list be?

Specific enough to be unambiguous, no more granular than that. “Refunds over $500” is a good gate. “Situations where a refund might feel unfair” is not — that requires judgment, which defeats the point. If writing a policy rule requires adjectives like “sensitive,” “complex,” or “unusual,” it is not a policy rule yet. Keep refining until it is a condition the agent can evaluate without any discretion.

Can the agent ask a clarifying question before escalating on an explicit request?

No. “I want a human” is a terminal signal. Asking “are you sure?” or “can I try one more thing first?” puts friction on the clearest signal in the system. The customer has told you what they want. Route immediately.

What happens if none of the four triggers fire but the agent still cannot resolve the issue?

This is the edge case worth instrumenting carefully. An agent that exhausts its resolution path without hitting any of the four triggers is either a complexity case you have not yet defined precisely enough, or a signal that the agent’s tool set or scope needs adjustment. Log it as a distinct category — “unresolved without trigger” — review it regularly, and use it to refine either the trigger definition or the agent’s capability set. Do not silently route these to the human queue; doing so would pollute your escalation metrics.

Does the pause_turn stop reason mean I should always escalate?

Not automatically — but you should treat it as a complexity signal. A pause_turn response means the server interrupted the agent before it could finish the task. Combine it with your resolution-path tracking: if the agent hit pause_turn and has already exhausted its tool calls without making progress, that is a complexity escalation. If it hit pause_turn mid-way through a path that is still progressing, continue the turn.

How does this escalation model relate to confidence-based routing?

They are complementary, not competing. Confidence routing (covered in Confidence Fields and Human-in-the-Loop Routing) flags uncertainty — the agent is not sure what the right answer is. Escalation triage handles structural conditions — policy gates, complexity, risk, or an explicit customer request. You can and should have both. A low-confidence score might influence how carefully you monitor the resolution path, but it does not by itself trigger escalation under this model.

Where this fits in the series

This tutorial is part of How Claude Actually Works — a course that builds a mechanistic understanding of how Claude reasons, acts, and integrates with production systems. It sits in the reliability plane of the Claude Stack mental model, alongside the episode on confidence fields and human-in-the-loop routing (which handles uncertainty, the bookend to this episode’s structural triggers). The next step is the capstone: Production Claude Agent Architecture, where every piece — tools, context management, evals, escalation — assembles into a real system. Browse all tutorials to follow the full series or jump to any topic.