Escalation and ambiguity

Escalation triggers that hold up

This task statement asks you to design escalation, which means deciding in advance what causes it. A trigger is good if it predicts that the agent cannot or should not finish the job on its own. Three hold up well. An explicit request for a human should be honoured straight away — the customer has told you what resolution they want. A policy gap or exception — a refund above the agent’s limit, a situation the policy does not cover, a request to override a rule — needs someone with authority, because the agent was never given it. And a genuine blocker — the agent has tried the available tools and cannot make progress — is the case Anthropic’s agent guidance describes when it says agents can pause for human feedback when they encounter blockers.

Two tempting triggers do not hold up. Sentiment measures how the customer feels, not how hard the problem is: an angry customer with a simple damaged-item claim needs a fast fix, while a calm customer asking for a contract exception needs a human. And the model’s own self-reported confidence is a number it produced, not a measurement checked against outcomes — it can be high on a wrong answer. (How to calibrate confidence properly is covered in 5.5.)

Write the triggers into the system prompt as explicit criteria, with the reason behind each and a few short examples of the boundary. Anthropic’s prompting guidance stresses both halves: be prescriptive about which actions need confirmation and which are safe to take autonomously, and explain why, because the reason lets the model generalise to cases your examples did not cover.

Escalate to a human agent
if the customer is upset or
if you are not confident.

Escalate when:
- the customer asks for a person
  (do it immediately);
- a refund exceeds $200, or the
  policy does not cover the case;
- tools fail and you cannot
  make progress.
Do NOT escalate only because the
customer is frustrated: acknowledge
it and resolve the issue if it is
within policy. Refund limits exist
because finance must approve them.

Resolving ambiguity: look it up, then ask

Ambiguity is a different problem from escalation. A request is ambiguous when it has more than one reasonable reading and the readings lead to different actions. The first move is to reduce it with tools: Anthropic’s suggested proactive-agent prompt tells Claude to use tools to discover missing details instead of guessing. If the ambiguity survives — two customers match the name, “cancel my subscription” could mean one plan or all three — ask one targeted question. Do not pick the most likely reading with a heuristic when acting on the wrong one would be hard to undo.

How cautious to be is a design choice you state in the prompt. Anthropic’s prompting guide offers both ends: a snippet that tells Claude to infer the most useful action and proceed, and one that tells it to default to research and recommendations when intent is ambiguous. It also suggests asking before actions that are hard to reverse, affect shared systems, or could be destructive, while taking local, reversible actions freely.

Asking through the Agent SDK

In the Agent SDK, Claude asks clarifying questions by calling the built-in AskUserQuestion tool. The call arrives in your canUseTool callback, like a permission request; your application shows the multiple-choice questions and returns the user’s answers. Each call carries one to four questions with two to four options, and you should offer a free-text “Other” path, because the options will not always fit. If you restrict the agent with a tools list, include AskUserQuestion or it cannot ask at all.

async def can_use_tool(tool_name, input_data, context):
    if tool_name == "AskUserQuestion":
        answers = {}
        for q in input_data["questions"]:          # 1–4 questions per call
            # show q["question"] and q["options"] (2–4) plus a free-text "Other"
            answers[q["question"]] = await ui.ask(q)   # label, or the user's own text
        return PermissionResultAllow(updated_input={
            "questions": input_data["questions"],  # pass the originals back
            "answers": answers,
        })
    if is_destructive(tool_name, input_data):
        # Claude sees this message and can adjust its approach
        return PermissionResultDeny(message="Needs a supervisor. Summarise and hand off.")
    return PermissionResultAllow(updated_input=input_data)

options = ClaudeAgentOptions(
    tools=["Read", "Grep", "AskUserQuestion", "mcp__crm__lookup_customer"],
    can_use_tool=can_use_tool,
)

The handoff itself

An escalation is only as good as what the human receives. A human picking up a case should not have to read forty turns of transcript, and the customer should not have to repeat themselves. Have the agent produce a structured handoff at the moment it escalates — ideally through a dedicated tool whose input schema forces the fields — and tell the customer what will happen next. Anthropic’s customer-support use-case guide lists escalation efficiency among the success criteria to measure, alongside a guardrail that the agent should not make promises it is not authorised to make — both are easier to meet when handoffs are structured and triggers are explicit.

Traps the wrong answers are built from

You should now be able to

• Define explicit escalation triggers and write them into the system prompt with reasons and examples.
• Distinguish reliable triggers from sentiment and self-reported confidence.
• Resolve ambiguity by looking up missing details first, then asking one targeted question.
• Handle AskUserQuestion and approvals through canUseTool, knowing subagents cannot ask the user.
• Design a structured handoff that lets a human act without rereading the conversation.