Customer Support Automation Handoffs: Calibrated Confidence, Escalation Queues, and Human Continuity

A support model saying "I am 92% confident" does not prove that its answer is correct: the number may merely be a probability associated with token generation and have no calibratable relationship to whether the knowledge is outdated, the order tool found the current customer's record, or the refund policy applies. Conversely, raising a single global threshold does not necessarily make the system safe; small Chinese-language samples, angry complaints, and account-security issues can still be masked by aggregate metrics. The real control point is which verifiable evidence allows the system to hold authority to send a customer-facing reply.

The End-to-End AI Customer Support Agent introduces RAG, tool queries, and a basic human-escalation architecture. This article does not rebuild the support product; it defines the runtime decision policy and ownership handoff. Human Review Queues for Agents provides general risk routing, while Human Overrides for High-Risk AI records how humans change the result after the machine has formed a recommendation. Here, the handoff occurs before an unreviewed reply gains send authority and further constrains the conversation SLA, explicit requests for human assistance, and support queue capacity.

Confidence Is a Calibrated Decision Input, Not a Model's Claim

Publish an immutable supportDecisionPolicy.v1 that fixes the intents eligible for automatic handling, languages and channels, risk tiers, model/RAG/tool bundle digest, calibration-set snapshot, thresholds, maximum turns, queue routing, and effective window. Its output is limited to AUTO_REPLY, DRAFT_FOR_REVIEW, ESCALATE_NOW, and ABSTAIN, each with a stable reason code. The generative model cannot decide on its own to bypass the policy.

schema: supportDecisionPolicy.v1
revision: 12
bundle: support-cn@sha256:81f...
autoReplyIntents: [shipping_status, password_reset_help]
forbiddenAutoReply: [refund_commitment, account_lock, legal_threat]
thresholds:
  lowRiskSupportedAnswer: 0.93
  toolIdentityBinding: 1.00
maxUnresolvedTurns: 2
handoffSla: {urgent: 5m, normal: 4h}

The decision engine reads an evidence vector: whether retrieved passages cover the answer's claims, source version and validity window, whether a tool returned a receipt bound to the current account, identity-verification level, rule matches, whether the user explicitly said "human agent," the number of repeated unresolved turns, language slice, and potential harm. Any missing critical evidence yields INSUFFICIENT_EVIDENCE; the engine does not treat a missing field as zero and continue averaging. Requests involving refund commitments, account suspension, security, or legal matters are escalated directly. A high model score cannot override these hard boundaries.

A probabilistic model must be calibrated on an independent labeled set and report reliability curves, Brier scores, or ECE by intent, language, customer tier, and risk slice. High confidence from modern neural networks can be miscalibrated; temperature scaling and similar methods can correct only the statistical relationship and cannot restore missing evidence. AI Safety Classifier Threshold Release Gates governs the versioned mapping from scores to actions for an individual safety classifier. The support policy consumes its receipt but must still combine retrieval, identity, tool, and queue evidence. The NIST AI RMF and Generative AI Profile emphasize risk-based governance, measurement, and human oversight. Thresholds must therefore be tied to the cost of an incorrect automated reply rather than the pursuit of a more attractive auto-resolution rate.

A Handoff Is a Fenced State Machine

Conversation state is restricted to BOT_ACTIVE -> HANDOFF_REQUESTED -> QUEUED -> HUMAN_CLAIMED -> HUMAN_ACTIVE -> RESOLVED. The same canonical transaction that enters HANDOFF_REQUESTED creates a stable case, changes the owner to HUMAN_PENDING, increments the sender generation, and writes the handoff packet and queue outbox; QUEUED becomes valid only after a durable queue acknowledgment. The packet contains the original request, reference summary, steps already attempted, tool receipts, the unresolved reason, identity/risk details, and proof of redaction. The summary is for navigation only and must not turn model inferences into customer facts.

Claiming the case increments ownerGeneration again. Every message-sending entry point must validate the case, owner, policy, and sender generation together: once a handoff is requested, the old bot may only save a draft even if its response arrives late. Returning control to automation requires a human to explicitly select a new policy revision and an allowed intent, then increment the generation again. A queue timeout does not automatically give control back to the model. Agent Failure Recovery Order can determine whether to retry or escalate, but send authority for the support channel remains governed by the ownership record.

Queue overload must not cause the confidence threshold to be lowered merely to reduce the human-escalation rate. If the queue fails, the case remains HUMAN_PENDING and the bot stays fenced. Only the control plane holding the current sender generation may send a queue acknowledgment that contains no conclusion. The system may collect required fields and prioritize security, payment interruptions, service unavailability, and routine inquiries. Users who explicitly request a human should not first have to talk to the bot for three more turns; the handoff SLA begins when the request is made.

Evaluate Missed Escalations, Not Just Escalation Counts

The offline set contains cases that should receive a correct automated reply, be drafted, be escalated immediately, or be refused, and retains independent adjudication. The primary gates are the harmful auto-reply rate, missed-escalation rate, evidence support rate, and identity-binding errors; the auto-resolution rate is only a capacity benefit. Agent Online Evaluation Metrics connects offline evaluation with real user outcomes. This policy must also track handoff wait p50/p95, human rewrite rate, repeat-contact rate, the number of bot races blocked after handoff, and calibration drift for every slice.

The fault suite makes retrieval return an outdated policy, lets a tool time out while an optimistic answer is generated, has a user request a human in another language, repeats the same problem three times, injects attack text claiming "the system has approved the refund," makes a human and bot send simultaneously, has two agents claim the case concurrently, takes the queue service down, loses the owner generation, and raises confidence across an entire language. Assertions require 0 automated replies for hard-risk cases, 0 missed escalations for explicit human requests, 0 write-operation commitments when identity is incomplete, and 0 successful sends by stale owners.

Launch gates require an evidence support rate of at least 99% for low-risk slices. For each mandatory risk slice, preregister a one-sided 95% Clopper-Pearson upper bound and alpha allocation across slices, and require at least 3000 independent automated-reply samples with mature outcomes; otherwise the result is INSUFFICIENT_DATA and blocks launch. Zero events cannot be used to pretend the system is safe. The harmful auto-reply upper bound must be below 0.1%, ECE must be no greater than 0.03, at least 99.9% of explicit human requests must enter the queue within 30 seconds, and required-field coverage for handoff packets must be 100%. Start in shadow mode, then enable drafting, and finally enable 5% only for two low-risk intents.

If a harmful sample appears even once, missed escalations in any risk slice exceed the bound, queue p95 exceeds twice the SLA, or owner fencing is absent, atomically repoint the policy alias to DRAFT_ONLY and increment the sender generation. Queued cases remain human-owned, and historical decisions and human edits cannot be overwritten. After the fix, replay the offline set and shadow traffic under a new revision. User-data retention and handoff visibility must comply with AI Data Privacy Compliance; rollback cannot be used as a reason to retain data longer.