Module 10

Escalation & Human Review: Triggers, Handoffs, and Confidence Calibration

This module covers the human side of reliable agent systems: which triggers should move a case from an autonomous agent to a human operator, how to package a handoff so the human can act without the transcript, and how to design human-review workflows that spend limited reviewer capacity where the model is least reliable.

Answer key Module10_Complete.ipynb

1. Explicit Escalation: Triggers as Policy

Escalation should be driven by written policy, not model vibes or sentiment alone.

1a. Hard Triggers

  • Customer requests: any explicit request for a human must be honored immediately without re-routing or attempting further autonomous resolution.
  • Policy gaps or silence: if a request touches an area where the provided policy is ambiguous or silent, such as a refund-window exception or competitor price match, the agent must escalate rather than improvising a new policy.
  • Inability to make meaningful progress: if the agent has looped through several turns or tool calls without advancing the case (repeating the same questions, retrying the same failing action, or circling the same diagnosis), it must escalate rather than continue burning the customer's time.
  • High-stakes actions: use the PreToolUse hooks from Module 9 to catch and escalate irreversible actions before they execute.
System prompt policy fragment
Escalate immediately when:
- The customer asks for a human, manager, representative, or supervisor.
- The policy does not explicitly cover the requested exception.
- You are not making meaningful progress on the case: you have repeated
  the same question, retried the same failing action, or gone several
  turns without moving the case forward.
- The requested action is irreversible, regulated, or above the
  configured approval threshold.

1b. Unreliable Triggers the Exam Expects You to Reject

Two commonly proposed triggers fail in practice, and the exam expects you to reject both:

  • Sentiment-based escalation: customer frustration does not correlate with case complexity. A furious customer with a standard damage claim is still a simple case the agent can resolve in one turn. Routing on sentiment sends easy cases to humans while hard-but-polite cases stay with the agent. When a customer expresses frustration but the issue is within the agent's capability, the correct behavior is to acknowledge the frustration and offer to resolve the issue, escalating only if the customer reiterates the request for a human.
  • Self-reported confidence scores: LLM confidence is poorly calibrated. The agent is already wrongly confident on exactly the hard cases, so a "escalate when confidence < 0.7" threshold routes the wrong cases: the model reports high confidence on the cases it is getting wrong.

The proportionate fix for mis-calibrated escalation behavior is explicit criteria plus few-shot examples in the system prompt demonstrating escalate-vs-resolve decisions, before reaching for classifiers, fine-tuning, or ML routing infrastructure. Show the model a frustrated-but-simple case being resolved and a policy-gap case being escalated, and most mis-routing disappears.

1c. Ambiguous Identity: Multiple Matches

Identity resolution has its own hard rule. When get_customer returns multiple matches, the agent must ask the customer for an additional identifier (an order number, a billing zip code) and re-query. It must never select a record by heuristic, such as picking the most recent account or the closest name match. A heuristic pick that lands on the wrong customer turns a lookup into a data-exposure incident.

2. The Structured Handoff Protocol

A blind handoff frustrates users. A structured payload ensures the human operator can resolve the issue quickly.

The final act of the agent is to call an escalate_to_human tool with a strict schema. Remember: the human receiving the handoff does not have the conversation transcript; the payload must stand alone. The exam's handoff checklist is: customer ID, root cause, amounts, and recommended action.

JSON (strict handoff schema)
{
  "name": "escalate_to_human",
  "description": "Transfer control to a human operator with enough context to resolve the issue without repeating failed steps.",
  "strict": true,
  "input_schema": {
    "type": "object",
    "properties": {
      "customer_id": { "type": "string" },
      "root_cause": { "type": "string" },
      "actions_attempted": {
        "type": "array",
        "items": { "type": "string" }
      },
      "amounts": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "description": { "type": "string" },
            "amount_usd": { "type": "number" }
          },
          "required": ["description", "amount_usd"],
          "additionalProperties": false
        }
      },
      "recommended_next_step": { "type": "string" }
    },
    "required": [
      "customer_id",
      "root_cause",
      "actions_attempted",
      "amounts",
      "recommended_next_step"
    ],
    "additionalProperties": false
  }
}

3. Human Review Workflows & Confidence Calibration

Escalation covers live conversations. Batch workloads (document extraction, classification, claims intake) need a different human-in-the-loop design: a review workflow that decides which outputs a human checks.

3a. Aggregate Accuracy Masks Segment Failures

A headline metric like "97% extraction accuracy" can hide a segment that is failing badly: 60% accuracy on one document type, or one field that is systematically wrong across every document. Before reducing human review, validate accuracy by document type and by field. The decision to pull humans out of the loop must be made per segment, never on the aggregate number.

3b. Field-Level Confidence, Calibrated Against Labels

Have the model output a confidence score for each extracted field, then calibrate review thresholds using a labeled validation set: for each confidence band, measure the actual error rate against ground truth, and set the review threshold where the measured error rate crosses your tolerance. Raw self-reported confidence is not trustworthy until it has been calibrated against labels; it becomes useful only as an empirically validated routing signal.

JSON (extraction output with per-field confidence)
{
  "document_type": "invoice",
  "fields": {
    "vendor_name":   { "value": "Acme Industrial Supply", "confidence": 0.98 },
    "invoice_total": { "value": 4820.50,                  "confidence": 0.95 },
    "due_date":      { "value": "2026-08-01",             "confidence": 0.62 },
    "po_number":     { "value": "PO-77813",               "confidence": 0.41 }
  }
}

With a calibrated threshold of 0.85, due_date and po_number route to the human review queue while the other two fields flow straight through.

3c. Stratified Random Sampling of High-Confidence Output

Never stop sampling just because confidence is high. Continuously pull a stratified random sample of high-confidence extractions for human review. This serves two purposes: it measures the true error rate in the auto-approved stream, and it detects novel error patterns (a new document layout or vendor format that the model confidently misreads) before they accumulate.

3d. Routing: Spend Reviewers Where the Model Is Least Reliable

Reviewer capacity is the scarce resource. Route to human review: (1) low-confidence extractions below the calibrated threshold, (2) source documents that are ambiguous or internally contradictory (a scan where two totals disagree cannot be resolved by any extraction model), and (3) the ongoing stratified sample from the high-confidence stream. Everything else auto-approves.

Exam tip: distinguish calibrated field-level confidence from self-reported confidence. Field-level scores validated against a labeled set are a legitimate routing signal for review queues. Asking the model "how confident are you, 1–10?" and acting on the raw answer is the same uncalibrated signal rejected as an escalation trigger in section 1.

Lab Exercise: Escalation Policy, Handoffs, and Review Calibration

Self-driven lab Module10_Self_Driven_Lab.ipynb

Objective: design a deterministic escalation policy, build a standalone handoff payload, and calibrate a human-review workflow with per-field confidence.

  1. Escalation criteria: add the three hard triggers (explicit human request, policy gap, and inability to make meaningful progress) to the system prompt, along with few-shot examples demonstrating escalate-vs-resolve decisions. Test with a frustrated-but-simple case (the agent should acknowledge the frustration and offer to resolve) and a policy-gap case such as a competitor price match (the agent should escalate rather than invent a discount).
  2. Multiple-match handling: make get_customer return two matching records and verify the agent asks for an additional identifier, such as an order number or billing zip, instead of picking one by recency or name similarity.
  3. Handoff payload: implement the escalate_to_human tool with a strict schema including customer_id, root_cause, actions_attempted, amounts, and recommended_next_step. Confirm the payload makes sense to a reader who has never seen the transcript.
  4. Confidence output: extend an extraction tool to emit a per-field confidence score, and route any field below your threshold to a review queue while the rest auto-approve.
  5. Calibration check: using the labeled set below, compute accuracy by document type and identify the segment that needs continued human review despite the strong aggregate number.
CSV (labeled validation set)
doc_id,doc_type,field,model_value,label_value,correct
D01,invoice,total,4820.50,4820.50,true
D02,invoice,total,1130.00,1130.00,true
D03,invoice,total,905.75,905.75,true
D04,invoice,total,2210.10,2210.10,true
D05,receipt,total,88.20,88.20,true
D06,receipt,total,41.99,41.99,true
D07,receipt,total,17.35,17.35,true
D08,purchase_order,total,15200.00,12500.00,false
D09,purchase_order,total,730.00,7300.00,false
D10,purchase_order,total,2650.00,2650.00,true

Exam tip: escalation triggers, handoff completeness, and review calibration are separate design decisions. A system can have perfect handoffs and still escalate the wrong cases.