Escalation and ambiguity resolution

What you’ll be able to do

• Write explicit escalation criteria with few-shot examples that separate escalate-now cases from resolve-autonomously cases
• Honor an explicit request for a human immediately, and distinguish it from frustration on a straightforward issue
• Escalate when policy is ambiguous or silent on the customer’s specific request
• Ask for additional identifiers when a lookup returns multiple matches instead of picking one heuristically

What you need to know

The triggers that justify escalation

An agent that escalates too often wastes human capacity and fails first-contact resolution targets. One that escalates too rarely makes decisions it isn't authorized to make. The exam frames the appropriate triggers as three categories:

• The customer asks for a human. An explicit request is honored.
• Policy exceptions or gaps. The request falls outside what policy allows, or policy doesn't address it at all. This is about policy coverage, not about how complicated the case feels: a long, multi-step case fully covered by policy can be resolved autonomously.
• Inability to make meaningful progress. The agent has tried the available paths and is stuck.

Explicit criteria and examples, not vibes

When an agent escalates easy cases and attempts hard ones, the root cause is usually unclear decision boundaries. The proportionate fix is to add explicit escalation criteria to the system prompt, with few-shot examples that show both sides: a standard damaged-item replacement with photo evidence, resolved autonomously; a request for a refund outside the return window, escalated as a policy exception. Examples teach the boundary in a way a single rule ("escalate complex cases") can't.

Two shortcuts look attractive and are wrong:

• Sentiment-based escalation. How upset a customer sounds doesn't track how hard their case is. An angry customer with a simple late-delivery refund is an easy case; a calm customer asking for an unusual exception is a hard one.
• Self-reported confidence scores. Asking the model to rate its confidence 1–10 and escalating below a threshold fails exactly where it matters: an agent that is mishandling hard cases is usually confidently wrong about them. Self-reported confidence is a poor proxy for actual complexity.

“I want a human” versus “I’m frustrated”

These are different situations and the agent should treat them differently.

• Explicit demand for a human: escalate immediately. Don't first investigate, look up the account, or try to solve it "just to see." The customer has stated what they want; overriding it damages trust and wastes their time.
• Frustration on a straightforward issue: acknowledge the frustration and offer to resolve it, since it's within the agent's capability. If the customer then reiterates that they want a person, escalate.

When policy is silent, escalate

Policies are written for the cases someone anticipated. Suppose the price-adjustment policy covers price drops on your own site, and a customer asks you to match a competitor's price. The policy doesn't say yes and doesn't say no. It's silent. The agent should not stretch the own-site rule to cover competitors, and it shouldn't flatly refuse on the agent's own authority either. Ambiguous or silent policy on the customer's specific request is an escalation trigger, because deciding it means making policy, and that belongs to a human.

Multiple matches: ask, don’t guess

A lookup by name returns three customers called "J. Martinez." Choosing one, whether the most recent, the one with an open order, or the first in the list, is a heuristic that will sometimes pick the wrong account, and in support that means acting on someone else's data. The correct behavior is to ask the customer for an additional identifier (email, order number, postcode) and look up again. Put this in the instructions explicitly: when a tool returns more than one match, request clarification instead of selecting.

Ambiguity resolution and escalation share a principle: when the agent lacks the information or the authority to act correctly, it gets the missing piece (from the customer or a human) rather than filling the gap with a guess.

Key concept

Escalate on explicit triggers: a customer asking for a human (immediately), a policy gap or exception, or no meaningful progress. Teach the boundary with explicit criteria and few-shot examples. Don’t use sentiment or self-rated confidence as proxies, and when a lookup returns several matches, ask for another identifier.

When a scenario shows escalation that's miscalibrated in both directions, the fix is clearer criteria and examples in the prompt, not a confidence threshold or a sentiment classifier.

Practice scenario

Build exercise — Calibrate an escalation policy

Intermediate · 25 min

What you’ll learn

• Writing escalation criteria grounded in triggers rather than proxies
• Using paired few-shot examples to teach a decision boundary
• Handling multiple-match lookups with clarification

1. List ten realistic support requests. Label each as resolve, escalate-immediately (explicit human request), or escalate (policy gap/exception, no progress), and write one sentence of reasoning for each.

   • Why: Writing the reasoning exposes whether your boundary is about policy coverage or just about how hard a case feels.
   • You should see: Some long, involved cases labeled “resolve” and some short ones (like competitor price matching) labeled “escalate.”

2. Turn four of them into few-shot examples in the system prompt, including one frustrated-but-straightforward case where the agent acknowledges and offers resolution, and one explicit human request where it escalates without investigating.

   • Why: Contrasting examples show the model where the line is better than a rule stated in the abstract.
   • You should see: The agent handling the remaining six cases consistently with your labels.

3. Add an instruction for multiple-match lookups and test it with a name that returns three customers.

   • Why: Heuristic selection eventually acts on the wrong record.
   • You should see: The agent asking for an email or order number, and making no account-specific changes until a single match is confirmed.

Exam traps

Escalating on negative sentiment as a proxy for case complexity

How upset a customer is doesn’t indicate whether policy covers their case. Sentiment solves a different problem.

Routing to humans based on the model’s self-reported confidence score

Self-reported confidence is poorly calibrated, and the agent is often most confident on the cases it gets wrong.

Investigating or attempting resolution first when the customer has explicitly asked for a human

An explicit request is honored immediately. Investigating first overrides what the customer asked for.

Escalating every frustrated customer even when the issue is within the agent’s capability

Acknowledge the frustration and offer resolution. Escalate if the customer reiterates that they want a person.

Stretching an existing policy to cover a case it doesn’t address instead of escalating

Silent or ambiguous policy is an escalation trigger. Extending the rule means the agent is making policy.

Picking the most recent or most likely record when a lookup returns several matches

Ask for an additional identifier. A heuristic choice will sometimes act on the wrong customer’s account.

Sources

• Claude Developer Platform Docs
• Anthropic, Claude Certified Architect – Foundations Exam Guide v1.0 (July 2026)