Escalation & Ambiguity Resolution

Official Exam Guide Objectives

Task 5.2: Design effective escalation and ambiguity resolution patterns.

Knowledge of

• Appropriate escalation triggers: customer requests for a human, policy exceptions/gaps (not just complex cases), and inability to make meaningful progress
• The distinction between escalating immediately when a customer explicitly demands it versus offering to resolve when the issue is straightforward
• Why sentiment-based escalation and self-reported confidence scores are unreliable proxies for actual case complexity
• How multiple customer matches require clarification (requesting additional identifiers) rather than heuristic selection

Skills in

• Adding explicit escalation criteria with few-shot examples to the system prompt demonstrating when to escalate versus resolve autonomously
• Honoring explicit customer requests for human agents immediately without first attempting investigation
• Acknowledging frustration while offering resolution when the issue is within the agent's capability, escalating only if the customer reiterates their preference
• Escalating when policy is ambiguous or silent on the customer's specific request (e.g., competitor price matching when policy only addresses own-site adjustments)
• Instructing the agent to ask for additional identifiers when tool results return multiple matches, rather than selecting based on heuristics

What You Need to Know

Where the escalation line sits determines whether a support agent is useful. Set it wrong and first-contact resolution collapses in one direction or the other — everything handed to a human, or nothing that should have been. What the exam tests is which triggers are sound and which merely sound sound.

The Three Valid Escalation Triggers

Exactly three reasons justify handing a case to a person:

1. Customer explicitly requests a human. "I want to speak to a person" ends the matter. Do NOT attempt to resolve the issue first, and do not offer to try — no version of "let me see whether I can help with that first" is acceptable, however helpfully meant. A clear request has been made and the response is to act on it.

This is an absolute rule with no exceptions. The moment the customer explicitly asks for a human, the escalation happens.

2. Policy exceptions or gaps. The situation sits outside what policy covers — a request to match a competitor's price where policy addresses only adjustments against your own prices. Policy cannot be invented mid-conversation, so someone with the authority to make an exception has to decide.

Note the distinction from a violation, which the exam leans on. A refund requested outside the return window is a violation, and policy answers it: no. A gap is policy having nothing to say at all. Gaps escalate. Violations are simply applied.

3. Inability to make meaningful progress. Resolution was attempted and cannot advance — tools failing in ways local retry cannot clear, a situation needing system access the agent does not hold, a defect that belongs to engineering.

This is the catch-all, and it is conditional on the attempt actually having happened. Anticipating difficulty is not the trigger; exhausting what the agent can do is.

The Two Unreliable Triggers

The exam specifically tests whether you can identify these as anti-patterns:

Sentiment-based escalation. Routing on detected frustration fails because frustration and difficulty are unrelated quantities. A customer furious about a late delivery has an easy case — apologise, compensate, reship. A polite customer asking about competitor price matching has a policy gap requiring human judgement. Sentiment reports how someone feels, which tells you nothing about how hard their problem is.

Self-reported confidence scores. Asking the model for a 1-10 confidence and escalating below a threshold fails because that number is poorly calibrated. Hard cases attract confidence, since not knowing what it does not know is precisely the condition; easy cases attract hedging. The result is the failure the exam scenario describes — simple cases escalated while complex ones are attempted.

The Frustration Nuance

The exam tests a specific nuance about customer frustration:

• Frustrated, but the problem is simple: name the frustration and fix the thing — "I understand this is frustrating. I can process your replacement right now." No escalation.
• Asks again for a human after you have offered to help: escalate now. The offer was made and declined, which settles it.
• Opens by asking for a human: escalate at once. Nothing is investigated first and no help is offered first.

What separates the first case from the third is not how strongly the customer feels but whether they have asked for a person. Frustration accompanying a resolvable problem is answered by resolving it; a request for a human is answered by producing one.

Ambiguous Customer Matching

Where a lookup returns several candidates — a name search finding three John Smiths — the agent asks for something that discriminates: an email address, a phone number, an order number.

The agent must NOT:

• Take whichever record was created most recently
• Take whichever account looks busiest
• Apply any rule of thumb at all to break the tie

Every one of those is a guess dressed as a rule, and the cost of guessing wrong is not a retry. Reading out one customer's details to another is a privacy breach, and refunding the wrong account is a financial error made confidently. Asking one clarifying question is the only response with no downside.

Explicit Escalation Criteria in System Prompts

Calibration comes from writing the criteria down, with worked examples, in the system prompt. Those examples should cover:

• The cases that go to a person — a request for one, a policy gap, an attempt that has run out of road
• The cases the agent finishes itself, including the frustrated customer whose problem is simple
• What an escalation must contain when it happens: customer ID, root cause, recommended action

And this comes before any infrastructure. A classifier or a sentiment model is a larger commitment answering a problem that explicit criteria usually solve outright — prompt work first, architecture only if it genuinely remains.

Deep Dive

Hooks as a deterministic escalation gate

Prompt instructions ("escalate when X") are probabilistic — they fail some percentage of the time. Where escalation must be guaranteed rather than merely likely, the Agent SDK's hook system is the deterministic mechanism. Hooks are "callback functions that run your code in response to agent events, like a tool being called, a session starting, or execution stopping," and one of their named use cases is exactly this: to "require human approval for sensitive actions" rather than relying on the model to remember to ask. A PreToolUse hook intercepts the tool call itself — e.g. process_refund above a threshold, or any tool tied to a policy-gap scenario — before it executes, and can force a human-approval branch regardless of what the model "decided."

Sourcecode.claude.com › hooksfetched 2026-07-30

PreToolUse output and canUseTool for human-in-the-loop approval

A PreToolUse hook's output sets permissionDecision to one of "allow", "deny", "ask", or "defer", plus a permissionDecisionReason — "ask" is the mechanism for routing a specific action to a human before it runs. Separately, a canUseTool callback provides a human-approval gate at the SDK level, but it sits at the end of the permission evaluation order — it is called only "if not resolved by any of the above". The docs are blunt about the consequence: "Auto-approved tools never reach canUseTool. A tool call approved at any earlier step, by acceptEdits or bypassPermissions, or by an allow rule, skips your canUseTool callback, so permission checks you put there are silently bypassed for that tool." Hence the documented rule: "For checks that must run on every tool call, use a PreToolUse hook" — so "always ask before a refund over $500" belongs in a hook, not in canUseTool.

Sources: https://code.claude.com/docs/en/agent-sdk/hooks (PreToolUse output fields) · https://code.claude.com/docs/en/agent-sdk/permissions (evaluation order and canUseTool) (fetched 2026-07-30)

Hook decision priority when multiple checks apply

When several hooks or permission rules could apply to the same action, "deny takes priority over defer, which takes priority over ask, which takes priority over allow. If any hook returns deny, the operation is blocked regardless of other hooks." For an escalation architecture this means a hard business rule (deny) always wins over a softer "ask the human" rule. The permissions reference adds the same guarantee at the rule level: deny rules are checked before the permission mode, so "if a deny rule matches, the tool is blocked, even in bypassPermissions mode", and "a hook deny applies even in bypassPermissions mode". There is no permission mode that can silently bypass a genuine policy stop.

Sources: https://code.claude.com/docs/en/agent-sdk/hooks (decision priority) · https://code.claude.com/docs/en/agent-sdk/permissions (deny rules vs bypassPermissions) (fetched 2026-07-30)

Structured handoff protocol fields

When escalation fires, the exam guide's companion objective on workflow handoff (Task 1.4) specifies what a human agent needs, since they "lack access to the conversation transcript": a structured handoff summary containing customer ID, root cause analysis, and recommended action, plus (in refund-style cases) the specific amount involved. This is the concrete content behind this lesson's "structured handoff with customer ID, root cause, recommended action" — it is a required payload, not an optional nicety, because the receiving human has no other context.

Sourceanthropic-partners.skilljar.com › partner-certificationsfetched 2026-07-30

Tool-call interception for compliance-driven escalation

The same deterministic-vs-probabilistic distinction applies to policy enforcement. The exam guide's Task 1.5 knowledge point contrasts "hook patterns that intercept outgoing tool calls to enforce compliance rules (e.g., blocking refunds above a threshold)" against relying on prompt instructions for probabilistic compliance, and its paired skill is "implementing tool call interception hooks that block policy-violating actions... and redirect to alternative workflows (e.g., human escalation)." In other words: the third valid escalation trigger — inability to make progress — is sometimes not a model judgement call at all, but a hook-enforced redirect the moment a specific tool call is attempted.

Sourceanthropic-partners.skilljar.com › partner-certificationsfetched 2026-07-30

Quick Reference

Exam Traps

Practice Scenario

Build Exercise

Build an Escalation Decision Engine

Difficulty: Intermediate (2/4)

40 minutes

1. Create a system prompt with explicit escalation criteria covering all three valid triggers: explicit human request, policy exceptions/gaps, and inability to make progress

Why: Explicit escalation criteria in the system prompt are the proportionate first response before adding infrastructure like classifier models or sentiment analysis. The exam tests that prompt optimisation should always precede architectural changes for escalation calibration.

You should see: A system prompt with three clearly defined escalation triggers, each with a description and decision rule. The prompt should also explicitly list the two anti-patterns (sentiment-based and confidence-based escalation) as things to avoid.

2. Add few-shot examples showing: immediate escalation for explicit human request, autonomous resolution for a frustrated customer with a straightforward issue, and escalation for a policy gap

Why: Few-shot examples demonstrating when to escalate versus when to resolve autonomously directly address unclear decision boundaries. This is the exact technique the exam identifies as the correct improvement for a support agent with poor first-contact resolution rates.

You should see: Three examples in the system prompt, each showing a different scenario with the correct decision and reasoning. The frustrated-but-resolvable example should show the agent acknowledging frustration and offering the resolution directly.

3. Implement ambiguous customer matching logic that requests additional identifiers (email, phone, order number) instead of selecting heuristically

Why: Selecting from ambiguous matches using heuristics (most recent, most active) risks privacy violations and incorrect actions. The exam tests that the only safe response to multiple customer matches is to ask for additional identifiers to disambiguate.

You should see: A matching function that detects when multiple records are returned and immediately asks for disambiguation rather than applying any selection heuristic. The disambiguation request should suggest specific identifier types.

4. Test with four scenarios: frustrated customer with simple issue, calm customer requesting policy exception, customer explicitly requesting a human, and ambiguous customer match

Why: These four scenarios cover all critical decision boundaries the exam tests: the frustration nuance, policy gap versus violation distinction, absolute rule for explicit human requests, and privacy-safe disambiguation.

You should see: Correct handling of all four scenarios: resolution offered for the frustrated customer, escalation for the policy gap, immediate escalation for the explicit human request (no investigation first), and disambiguation request for the ambiguous match.

5. Verify the agent never attempts investigation before honouring an explicit human request and never selects from ambiguous matches using heuristics

Why: These are the two absolute rules the exam tests with no exceptions. Any attempt to investigate before escalating on an explicit human request, or any heuristic selection from ambiguous matches, is a critical failure that would cost marks on the exam.

You should see: For explicit human requests: the escalation happens in the very first response with zero investigation steps. For ambiguous matches: the response always asks for additional identifiers, never selects a record. Both rules should hold across multiple phrasings and edge cases.

Sources

• Claude Certified Architect Foundations Exam Guide — Domain 5, Task Statement 5.2 — Anthropic
• Anthropic Agent SDK Documentation — Human-in-the-loop — Anthropic
• Anthropic Customer Support Best Practices — Anthropic
• Agent SDK — Hooks — Anthropic
• Agent SDK — Permissions — Anthropic

Appendix A — Build Exercise Step Hints

Progressive hints revealed by the "Stuck? Get a nudge" control on each step.

Step 1. Create a system prompt with explicit escalation criteria covering all three valid triggers: explicit human request, policy exceptions/gaps, and inability to make progress

Why: Explicit escalation criteria in the system prompt are the proportionate first response before adding infrastructure like classifier models or sentiment analysis. The exam tests that prompt optimisation should always precede architectural changes for escalation calibration.

You should see: A system prompt with three clearly defined escalation triggers, each with a description and decision rule. The prompt should also explicitly list the two anti-patterns (sentiment-based and confidence-based escalation) as things to avoid.

const systemPrompt = `## Escalation Criteria\n\n` +
  `1. EXPLICIT HUMAN REQUEST: If the customer says they want a human, escalate IMMEDIATELY. Do not attempt to resolve first.\n` +
  `2. POLICY GAP: If the request falls outside documented policy (not a violation, but a gap where policy is silent), escalate for human judgement.\n` +
  `3. INABILITY TO PROGRESS: If you have attempted resolution and cannot advance (tool errors, missing system access, engineering intervention needed), escalate with context.\n\n` +
  `DO NOT escalate based on: customer frustration level, your own confidence score, or sentiment analysis.`;

system_prompt = """## Escalation Criteria

1. EXPLICIT HUMAN REQUEST: If the customer says they want a human, escalate IMMEDIATELY. Do not attempt to resolve first.
2. POLICY GAP: If the request falls outside documented policy (not a violation, but a gap where policy is silent), escalate for human judgement.
3. INABILITY TO PROGRESS: If you have attempted resolution and cannot advance (tool errors, missing system access, engineering intervention needed), escalate with context.

DO NOT escalate based on: customer frustration level, your own confidence score, or sentiment analysis."""

Step 2. Add few-shot examples showing: immediate escalation for explicit human request, autonomous resolution for a frustrated customer with a straightforward issue, and escalation for a policy gap

Why: Few-shot examples demonstrating when to escalate versus when to resolve autonomously directly address unclear decision boundaries. This is the exact technique the exam identifies as the correct improvement for a support agent with poor first-contact resolution rates.

You should see: Three examples in the system prompt, each showing a different scenario with the correct decision and reasoning. The frustrated-but-resolvable example should show the agent acknowledging frustration and offering the resolution directly.

const examples = `\n## Examples\n\n` +
  `Customer: I want to speak to a real person right now.\n` +
  `Action: ESCALATE IMMEDIATELY. Customer explicitly requested a human. Do not investigate or offer to help first.\n\n` +
  `Customer: This is ridiculous! My package is a week late and nobody seems to care!\n` +
  `Action: RESOLVE. Issue is straightforward (late delivery). Acknowledge frustration, apologise, offer reshipment or compensation.\n` +
  `Response: I understand this is frustrating. I can see your package is delayed. Let me arrange a replacement shipment right now.\n\n` +
  `Customer: I purchased this from a competitor but want to return it at your store. Your website does not say anything about this.\n` +
  `Action: ESCALATE. Policy gap — competitor returns are not covered in documented policy. Requires human judgement on whether to make an exception.`;

examples = """
## Examples

Customer: I want to speak to a real person right now.
Action: ESCALATE IMMEDIATELY. Customer explicitly requested a human. Do not investigate or offer to help first.

Customer: This is ridiculous! My package is a week late and nobody seems to care!
Action: RESOLVE. Issue is straightforward (late delivery). Acknowledge frustration, apologise, offer reshipment or compensation.
Response: I understand this is frustrating. I can see your package is delayed. Let me arrange a replacement shipment right now.

Customer: I purchased this from a competitor but want to return it at your store. Your website does not say anything about this.
Action: ESCALATE. Policy gap — competitor returns are not covered in documented policy. Requires human judgement on whether to make an exception."""

Step 3. Implement ambiguous customer matching logic that requests additional identifiers (email, phone, order number) instead of selecting heuristically

Why: Selecting from ambiguous matches using heuristics (most recent, most active) risks privacy violations and incorrect actions. The exam tests that the only safe response to multiple customer matches is to ask for additional identifiers to disambiguate.

You should see: A matching function that detects when multiple records are returned and immediately asks for disambiguation rather than applying any selection heuristic. The disambiguation request should suggest specific identifier types.

function handleCustomerLookup(results) {
  if (results.length === 0) {
    return { action: "not_found", message: "No matching customer records found." };
  }
  if (results.length === 1) {
    return { action: "matched", customer: results[0] };
  }
  // Multiple matches — NEVER select heuristically
  return {
    action: "disambiguate",
    message: "I found multiple accounts matching that name. " +
      "Could you provide one of the following to help me find the right account?\n" +
      "- Email address\n- Phone number\n- Order number\n- Postcode",
    matchCount: results.length
  };
}

def handle_customer_lookup(results: list[dict]) -> dict:
    if not results:
        return {"action": "not_found", "message": "No matching customer records found."}
    if len(results) == 1:
        return {"action": "matched", "customer": results[0]}
    # Multiple matches — NEVER select heuristically
    return {
        "action": "disambiguate",
        "message": (
            "I found multiple accounts matching that name. "
            "Could you provide one of the following to help me find the right account?\n"
            "- Email address\n- Phone number\n- Order number\n- Postcode"
        ),
        "match_count": len(results),
    }

Step 4. Test with four scenarios: frustrated customer with simple issue, calm customer requesting policy exception, customer explicitly requesting a human, and ambiguous customer match

Why: These four scenarios cover all critical decision boundaries the exam tests: the frustration nuance, policy gap versus violation distinction, absolute rule for explicit human requests, and privacy-safe disambiguation.

You should see: Correct handling of all four scenarios: resolution offered for the frustrated customer, escalation for the policy gap, immediate escalation for the explicit human request (no investigation first), and disambiguation request for the ambiguous match.

const testScenarios = [
  { input: "This is SO frustrating! My order arrived broken!", expected: "resolve", reason: "Straightforward damage replacement" },
  { input: "I want you to match the price I saw at a competitor.", expected: "escalate", reason: "Policy gap — competitor matching not in policy" },
  { input: "I want to talk to a real human being.", expected: "escalate_immediate", reason: "Explicit human request — no investigation" },
  { input: "Look up my account, name is John Smith.", expected: "disambiguate", reason: "Multiple matches, ask for additional identifier" }
];

for (const scenario of testScenarios) {
  const result = await processScenario(scenario.input);
  console.assert(result.action === scenario.expected, `Failed: ${scenario.reason}`);
}

test_scenarios = [
    {"input": "This is SO frustrating! My order arrived broken!", "expected": "resolve", "reason": "Straightforward damage replacement"},
    {"input": "I want you to match the price I saw at a competitor.", "expected": "escalate", "reason": "Policy gap — competitor matching not in policy"},
    {"input": "I want to talk to a real human being.", "expected": "escalate_immediate", "reason": "Explicit human request — no investigation"},
    {"input": "Look up my account, name is John Smith.", "expected": "disambiguate", "reason": "Multiple matches, ask for additional identifier"},
]

for scenario in test_scenarios:
    result = process_scenario(scenario["input"])
    assert result["action"] == scenario["expected"], f"Failed: {scenario['reason']}"

Step 5. Verify the agent never attempts investigation before honouring an explicit human request and never selects from ambiguous matches using heuristics

Why: These are the two absolute rules the exam tests with no exceptions. Any attempt to investigate before escalating on an explicit human request, or any heuristic selection from ambiguous matches, is a critical failure that would cost marks on the exam.

You should see: For explicit human requests: the escalation happens in the very first response with zero investigation steps. For ambiguous matches: the response always asks for additional identifiers, never selects a record. Both rules should hold across multiple phrasings and edge cases.

// Test absolute rules with varied phrasings
const humanRequests = [
  "Transfer me to a human.",
  "I want to speak to a real person.",
  "Get me a manager.",
  "Let me talk to someone real, not a bot."
];

for (const request of humanRequests) {
  const result = await processScenario(request);
  console.assert(result.action === "escalate_immediate", "Must escalate immediately");
  console.assert(result.investigationSteps === 0, "Zero investigation before escalation");
}

// Test ambiguous match with tempting heuristic
const ambiguousResults = [
  { name: "John Smith", lastActive: "2024-03-14", city: "London" },
  { name: "John Smith", lastActive: "2023-01-02", city: "Manchester" }
];
const matchResult = handleCustomerLookup(ambiguousResults);
console.assert(matchResult.action === "disambiguate", "Never select heuristically");

# Test absolute rules with varied phrasings
human_requests = [
    "Transfer me to a human.",
    "I want to speak to a real person.",
    "Get me a manager.",
    "Let me talk to someone real, not a bot.",
]

for request in human_requests:
    result = process_scenario(request)
    assert result["action"] == "escalate_immediate", "Must escalate immediately"
    assert result["investigation_steps"] == 0, "Zero investigation before escalation"

# Test ambiguous match with tempting heuristic
ambiguous_results = [
    {"name": "John Smith", "last_active": "2024-03-14", "city": "London"},
    {"name": "John Smith", "last_active": "2023-01-02", "city": "Manchester"},
]
match_result = handle_customer_lookup(ambiguous_results)
assert match_result["action"] == "disambiguate", "Never select heuristically"

Appendix B — Interactive Study Prompts

Two prompts to paste into Claude. B1 drills the judgement the exam actually measures; B3 reviews the work you produced for the Build Exercise above. The exam simulator between them is the interactive quiz on this page.

B1. Concept Check — Discrimination Drill

B2. Exam Simulator

B3. Build Coach — Code Review

The Build Exercise and its hint ladder are already on this page. This prompt is for the one thing the page cannot do: review the escalation policy and the handling you actually wrote.