When Should an AI Agent Escalate to a Human?

The exam guide names three:

1. The customer asks for a human. Escalate right away. Do not investigate first, and do not try to talk them out of it.
2. Policy is silent or ambiguous on this request. The guide's example: a customer asks for a competitor price match, but policy only covers adjustments on your own site. The agent should not invent a rule. A complex case is not automatically a policy gap; a damage replacement with photo evidence can involve several steps and still be fully covered.
3. The agent can't make meaningful progress. Repeated failed lookups, a tool it doesn't have, a loop that keeps circling. Escalate, and say what was tried.

Frustration alone is not on the list. If a customer is annoyed but the issue is something the agent can fix, the guide's pattern is to acknowledge the frustration and offer the fix. Escalate if they repeat that they want a person.

Multiple matches: ask, don't guess

When get_customer returns two accounts for "Sam Lee", the agent should ask for another identifier (email, order number, postcode). Picking the most recent account or the one with an open order is a heuristic, and heuristics are how refunds land on the wrong person. This is ambiguity resolution, not escalation, but the exam groups them together.

Two options appear in escalation questions again and again, and both are wrong as primary triggers:

• Sentiment analysis. Negative tone measures how the customer feels, not how hard the case is. An angry customer with a simple shipping question gets escalated; a calm customer asking for an exception the policy doesn't cover does not.
• The model's self-reported confidence. Asking the agent to rate itself 1–10 and routing below a threshold fails because that number is poorly calibrated. The agent that mishandles hard cases is usually confident about them.

Task 5.5 is where confidence does belong, in a different form. In extraction pipelines, field-level confidence scores are useful after you calibrate thresholds against a labeled validation set, and you keep stratified sampling of high-confidence outputs to catch errors the scores miss. Calibrated per-field scores for routing review work: fine. A raw "how sure are you?" deciding customer escalations: trap.

The refund row overlaps with task 1.5: a business rule that must always hold belongs in a tool-call hook, not a prompt instruction. The details are in hooks vs prompt enforcement.

The human picking up the case usually can't see the transcript. Task 1.4 says the handoff should carry customer details, root cause analysis and a recommended action. Make escalate_to_human take a schema instead of free text:

{
  "customer_id": "C-48213",
  "verified": true,
  "escalation_reason": "policy_gap",
  "summary": "Customer requests price match against a competitor listing.",
  "root_cause": "Refund policy covers own-site price drops only; competitor matching is not addressed.",
  "order_id": "ORD-99172",
  "amount_in_question": 42.50,
  "currency": "USD",
  "actions_taken": ["get_customer", "lookup_order: delivered 2026-10-11"],
  "recommended_action": "Decide whether to grant a one-time $42.50 credit; customer is otherwise eligible for own-site adjustments.",
  "customer_requested_human": false
}

Required fields like root_cause and recommended_action force the agent to finish its analysis, so the human can act without re-asking the customer. Using a schema to enforce shape is the same idea as in structured output.

When an agent escalates easy cases and handles hard ones itself, the first fix the exam favors is proportionate: write explicit escalation criteria into the system prompt and add a few examples of each decision. A classifier model or a sentiment pipeline comes later, if ever.

Escalate when: the customer asks for a human; policy does not address the request;
you cannot make progress after checking the relevant tools.
Do not escalate just because a case has several steps or the customer is upset.

Example: "My blender arrived cracked, here's a photo." -> Resolve: replacement is covered.
Example: "Another store has it $40 cheaper, match it." -> Escalate: policy_gap.
Example: "I don't want a bot. Human please." -> Escalate immediately.

A customer writes: "This is the third time I'm asking. I want to speak to a real person." Their question is a simple delivery address change the agent can make with its tools. What should the agent do?

A) Look up the order first so it can tell the human what's going on. B) Acknowledge the frustration and offer to change the address now, escalating only if the customer asks again. C) Escalate immediately with a structured handoff summary. D) Run sentiment analysis and escalate if the score crosses the threshold.

Answer: C. The customer explicitly asked for a human, and the guide says to honor that immediately.

• A investigates before honoring the request, which the guide rules out.
• B is the right move for frustration without an explicit request. Here the request is explicit.
• D uses a signal the exam treats as unreliable, and adds machinery to a case the request already settled.

• Escalate on an explicit human request, a policy gap, or a lack of progress.
• Sentiment and self-reported confidence are unreliable proxies for case complexity.
• Multiple customer matches mean asking for another identifier, never guessing.
• Hand off with a structured summary: customer ID, root cause, amount, recommended action.
• Fix bad calibration first with explicit criteria and few-shot examples in the system prompt.