Skip to lesson

AnthropicClaude Certified Architect – Foundations2026-105.2 Design effective escalation and ambiguity resolution patterns

Teach escalation decisions with contrastive examples

Completed by the knowledge check

Learning objective

Use specific escalation criteria and targeted few-shot examples to distinguish autonomous resolution from escalation.

Core idea

A prompt that says “escalate complex or sensitive cases” leaves the deciding terms unresolved. Add explicit criteria, then show short cases on both sides of the decision. The examples should demonstrate why the action changes, rather than teaching an accidental association between anger and handoff.

See 4.2.1 for the general example-selection method. Anthropic suggests three to five examples for best results. For escalation, use that small set to contrast covered resolution with required handoff, varying customer mood independently of the decision. A collection of ordinary refunds leaves the escalation boundary untested.

How it works

State criteria before demonstrations

Use the Messages API’s top-level system parameter for the standing support contract. It carries the rules governing when to resolve, clarify, or initiate handoff. In the Claude Agent SDK, pass the criteria as a custom prompt string through systemPrompt (TypeScript) or system_prompt (Python).

The criteria should name the three triggers in 5.2.1 and the priority of explicit human requests in 5.2.2. Also state the non-trigger that caused the observed defect: frustration alone does not demand transfer when a covered remedy is available. For multiple matching records, request an identifier instead of choosing a candidate; see 5.2.6.

Keep the instruction operational. “Be cautious with policy” leaves room for a confident exception. “When the supplied policy does not cover the requested adjustment, call escalate_to_human for a policy decision; do not approve the adjustment” identifies the missing authority and the next action.

The tool name in that instruction is a custom operation your application defines, not an Anthropic built-in. Supply it in tools with a matching description and input_schema. A prompt cannot transfer a case unless the surrounding application implements the transfer path.

Select examples that reveal the boundary

Start from the observed mistakes. If the agent escalates angry customers and approves polite policy gaps, pair an angry covered request with a calm uncovered request. If it investigates after a human request, add an easy case that nevertheless transfers first. If it guesses between records, include a successful lookup with multiple matches that produces a question rather than a refund.

Keep the policy and tool names faithful to the deployed support workflow. Do not make every escalation example long and emotional while every autonomous example is short and polite; that can teach message style as the deciding feature. The customer input, decisive policy or progress evidence, intended action, and short explanation should show why a covered case remains autonomous or a trigger requires handoff.

The excerpt uses the <example> and <examples> organization taught in 4.2.1. Those tags organize prompt text; they do not enforce a transfer or authorize a refund.

The following excerpt illustrates five targeted demonstrations; it is prompt text, not an executable policy engine:

Escalate for an explicit human request, a policy exception or gap,
or inability to progress after permitted recovery. Human requests
come before investigation. Frustration alone is not a trigger.
If lookup results match several records, ask for an identifier.
<examples>
<example>
Customer: "Another late parcel. I'm furious."
Evidence: Late-delivery fee refund is covered and eligibility is verified.
Action: Acknowledge frustration and offer process_refund.
</example>
<example>
Customer: "Could you match a competitor's lower price?"
Evidence: Supplied policy covers only our own price reductions.
Action: escalate_to_human for a policy_gap; do not promise approval.
</example>
<example>
Customer: "It's an easy refund, but I'd like a representative."
Action: escalate_to_human for human_request before lookup_order.
</example>
<example>
Evidence: lookup_order remains unavailable after permitted recovery.
Action: escalate_to_human for blocked_progress; preserve unknown status.
</example>
<example>
Customer: "I'm Sam Patel."
Evidence: get_customer returns three matches.
Action: Ask for an order number or account email; select no candidate.
</example>
</examples>

The tools and reason labels in this excerpt are application-specific. The return and price-adjustment policies are illustrative retailer rules. Replace them with the deployed policies and exact operation names before using the examples in a support system.

Align rules, examples, and descriptions

Check each demonstration against the written criteria. If an example transfers a customer solely for anger, it contradicts the rule. If an example performs a refund before honoring a human request, it teaches the wrong sequence even if the final verdict says “escalate.”

Also inspect tool descriptions. Anthropic documents description as explaining what a tool does, when to use it, and how it behaves. A handoff description that requires exhaustion of all remedies conflicts with the immediate-human-request rule. Repair both surfaces so the model does not have to choose between contradictory instructions.

Decision examples in the system prompt differ from the tool-definition field input_examples. The latter supplies example argument objects for a tool. A valid escalation argument object can teach formatting without demonstrating whether escalation was the right decision. Use decision examples for routing judgment and argument examples only for the tool inputs they illustrate.

Measure whether the repair transfers

Replay labeled cases that include the observed failures and unseen variants. Inspect actual tool sequences as well as final wording. A human-request test should fail if lookup_order runs first, even when the final response promises a person.

Separate unnecessary transfers, missed transfers, and successful covered resolution. Anthropic’s customer-support guide recommends measuring correctly escalated cases and cases that should have escalated but did not. Add clarification cases so the evaluation does not reward handing every ambiguous lookup to a person.

Prompting is a proportionate first repair when the defect is an unstated decision rule. It does not replace execution checks for policy-sensitive operations; see 1.5.3. A perfect-looking example set cannot authorize a refund or prove that the handoff queue accepted a request.

Key distinctions and trade-offs

Criteria versus examples: Criteria state the rule. Examples settle interpretations and show the deciding evidence. Either alone can leave gaps; together they make the intended behavior clearer.

Decision example versus argument example: <example> prompt text can demonstrate when to call a tool. input_examples demonstrates its argument shape. Valid arguments do not imply a valid business decision.

Prompt repair versus trained routing infrastructure: If transcripts show missing criteria, repair those criteria and measure the result first. A separate classifier introduces another component without necessarily fixing the undefined policy. Escalation enforcement still belongs to the application’s operations.

Architecture / decision scenario

A support agent over-transfers covered complaints and under-transfers competitor price-match requests. Its system prompt says only “escalate complex cases.” Add explicit triggers and the five demonstrations, using the retailer’s real policies and tool names.

Keep separate evaluation variants: a neutral late-delivery complaint, a polite human request about the same refund, an angry competitor request, a persistent lookup failure, and multiple customer matches. The expected outcomes follow the evidence rather than matching the example wording. Review actual tool_use calls to confirm that explicit requests precede investigation and ambiguous identities produce clarification.

If the repaired prompt improves the examples but fails those variants, refine the unresolved criterion or demonstration. Do not declare success because the model can repeat the correct explanation. The observable result is its next action in the support workflow.

Common exam traps

  • Replacing a vague criterion with an uncalibrated confidence threshold.
  • Showing only escalations or only routine autonomous resolutions.
  • Teaching anger, length, or politeness as the hidden routing signal.
  • Confusing input_examples with worked decision examples.
  • Accepting a correct final explanation after an incorrect tool sequence.

What to remember

Write explicit criteria and demonstrate the disputed choices with relevant, varied examples. Use system for standing policy, <examples> for prompt organization, and consistent tool descriptions for selection. Verify transfer to unseen cases through actual operations and outcomes.

Knowledge check

References