Build a support agent that knows when to escalate

The failure mode that kills AI support agents isn't hallucination — it's false confidence. An agent that tries to handle everything burns trust with confident wrong answers. One that escalates everything burns your budget. The craft is knowing when to hand off, and designing the handoff so the human can pick it up without starting over.

Intercom's Fin — arguably the most mature AI support agent on the market — treats "escalation & handover quality" as one of its three primary metrics, alongside resolution rate and involvement rate. On its own pages, Fin's average resolution rate is reported to have grown from roughly 30% at launch to around 76%, with a 71% average across 7,000+ customers (both figures current as of August 2026). That still leaves a quarter or more of conversations needing humans. Escalation isn't an edge case. It's the product.

This tutorial walks through the three pillars of escalation design: confidence thresholds, handoff context, and human-in-the-loop patterns. It's aimed at teams building or configuring customer-facing agents, whether you're writing code or tuning a platform.

1. Stop asking "can it answer?" and start asking "how confident are we?"#

Most naive support agents route on intent alone: classify the message, look up an answer, reply. The problem is that intent confidence tells you nothing about whether the answer is right. A better approach is a composite confidence score built from several signals:

final_confidence =
    0.25 * intent_confidence       # do we know what they want?
  + 0.25 * retrieval_relevance     # did we find grounded sources?
  + 0.20 * answer_groundedness     # is the reply supported by sources?
  + 0.15 * tool_success_score      # did API lookups succeed?
  + 0.15 * policy_risk_score       # how dangerous is getting this wrong?

Weighting is yours to tune, but the principle holds: no single signal is trustworthy. An agent can be 99% sure of intent ("refund request") while retrieval returns nothing usable — that combination should never auto-resolve.

Beyond the composite score, there are low-cost tripwires worth building into the loop:

• Schema validation failures. If your agent emits structured output (intent, confidence, citations, next action) and it fails schema validation, that's a reliable "confused agent" signal — escalate rather than retry-looping into nonsense.
• Uncertainty markers in the reasoning trace. Phrases like "I'm not certain" or "I don't have enough information" in chain-of-thought can be caught with lightweight matching before the action executes.
• Missing required context. If a refund requires an order ID the agent cannot resolve, it should request human review rather than guess. Guessing is where trust goes to die.

2. Set three-tier thresholds — then calibrate them with data#

With a confidence score in hand, the standard routing pattern is a three-tier policy:

These numbers are starting points, not magic constants. Open-source support-agent implementations converge on roughly this shape, and platforms increasingly expose the threshold as a control: Intercom's Fin, for instance, gates auto-reply behind a configurable resolution-score threshold, with community documentation noting a default around 0.7.

Two design rules for the threshold system:

• Calibrate with an eval set, not vibes. Label a few hundred real conversations with "should the agent have handled this?" and check that your tiers match the labels. If high-confidence answers are still wrong 15% of the time, your threshold is miscalibrated or your confidence model is missing a signal.
• Hard escalation rules bypass confidence entirely. Some situations should route to a human regardless of score: legal threats, fraud or chargeback indicators, safety-critical topics, VIP accounts, and — always — the customer explicitly asking for a person. Bake these in as deterministic rules above the scoring layer.

3. Design the handoff, not just the handoff trigger#

The most common escalation bug is the cold handoff: the agent gives up, the customer gets "transferring you to an agent," and the human starts from zero, asking the customer to repeat everything. That's worse than no agent at all — the customer did the work twice.

Every escalation should ship a structured handoff payload. At minimum, the human receiving the case needs:

1. A one-paragraph summary — what the customer wants and where things stand.
2. The escalation reason — which threshold or hard rule fired, in plain language.
3. What the agent already tried — lookups, tool calls, answers given, and why each failed.
4. Retrieved evidence — the top sources or policy chunks consulted, with citations the human can verify.
5. Customer and account state — tier, recent tickets, sentiment trajectory, not just a name.
6. A suggested next action — the agent's best guess at resolution, clearly labeled as a suggestion.

In code terms, think of the handoff as an API contract between the agent and your helpdesk:

def escalate(conversation, reason, confidence):
    return {
        "summary": summarize(conversation),          # LLM-generated, human-readable
        "reason": reason,                            # e.g. "confidence 0.52 < 0.60"
        "attempts": conversation.tool_calls,         # what was tried
        "evidence": conversation.citations,          # sources consulted
        "customer_state": conversation.account,      # tier, history, sentiment
        "suggested_action": propose_next_step(...),  # labeled as suggestion
        "transcript": conversation.turns,            # full, for verification
    }

Tell the customer what's happening too — "I've brought in a specialist who has your full conversation history" beats a silent queue transfer every time.

4. Put humans in the loop, not on the sidelines#

Escalation isn't the only way humans stay in control. The best support-agent deployments blend several human-in-the-loop patterns, and Anthropic's own guidance on building human-agent teams is instructive here even though it was written about internal engineering agents:

• Start with maximum oversight, then relax. In the beginning, review everything the agent does, give feedback, and design verification checklists. Track which task types the agent has earned autonomy on, and expand scope per task type only after repeated successes. For support, that means launching with agent-assist (drafts reviewed by humans) before enabling auto-resolve.
• Build reflection into the cycle. Anthropic teams ask agents to compile "lessons & missteps" so mistakes aren't repeated. In support terms: every escalation is training data — route the human's resolution back into the loop so the knowledge base and thresholds improve.
• Treat human attention as scarce. When the agent does pull a human in, it should batch questions, repeat the key context needed to get the human up to speed quickly, and limit how much each human sees. Alert fatigue is real, and a review queue that floods humans with noise will be ignored exactly when it matters.

The through-line is the same: autonomy is granted per task type, gated by verification, and always revocable.

The practical middle tier is copilot mode — AI drafting replies inside the agent's inbox. Platforms including Intercom's Fin offer it as a first-class mode. It's the lowest-risk way to put an agent in front of real conversations, and human accept/edit/reject decisions give you labeled data to calibrate thresholds.

5. Measure escalation quality, not just resolution rate#

Teams often track resolution rate and stop there. That's a mistake — it incentivizes the agent to resolve things it shouldn't. A healthy measurement setup tracks the escalation system itself:

• Resolution rate — share of conversations completed without human intervention. Intercom distinguishes hard resolutions (customer confirms) from soft ones (customer exits satisfied), which is worth tracking separately.
• Escalation rate — share routed to humans. Watch the trend, not just the level: a sudden spike usually means a knowledge gap or a broken tool, not worse customers.
• Handover quality — the metric that matters most. Track reopen rates, time-to-resolution, and CSAT on escalated conversations specifically.
• Avoidable escalations — escalations caused by missing or stale knowledge-base content. This is your content backlog, handed to you for free.

Then close the loop: feed resolutions back into the knowledge base, retune thresholds monthly, and review a sample of escalations weekly. The goal is an escalation rate that declines over time while handover quality stays high.

Takeaway#

Building a support agent that knows when to escalate comes down to four commitments:

1. Score confidence from multiple signals — intent, retrieval, groundedness, tool success, and risk — not just classification confidence.
2. Route through calibrated tiers — auto-resolve, agent-assist, escalate — with hard escalation rules that bypass scoring for legal, safety, and fraud situations.
3. Ship structured handoff context — summary, reason, attempts, evidence, account state, and a suggested next action — so the human never starts from zero, and keep the customer informed during the transfer.
4. Keep humans in the loop by design — start with reviewed drafts, add approval gates for irreversible actions, and treat every escalation as training data.

The agents customers trust aren't the ones that never escalate. They're the ones that escalate at the right moment, with the right context, so the human who picks up the case already knows how to end it.