Reliability is not only about catching errors after the fact; it is about not committing to a wrong interpretation in the first place. When intent is ambiguous, a well-built agent asks rather than assumes. This chapter is the exam angle on that discipline — the mechanism and its limits — and points to the handbook for the hands-on use-side workflow. The principle is durable; the tool that carries it is the illustration, so this is an architectural pattern.

Escalate, don’t guess

The foundational move is to surface a decision the model cannot make on its own. “While working on a task, Claude sometimes needs to check in with users. It might need permission before deleting files, or need to ask which database to use for a new project. Your application needs to surface these requests to users so Claude can continue with their input.” [Official] Handle approvals and user input · AnthropicT1-official original An architect’s job is to make those check-ins possible and routine — to design the agent so that hitting an ambiguity raises a question instead of silently resolving it.

AskUserQuestion: structured clarification

The mechanism is a built-in tool with a deliberately bounded shape. Each AskUserQuestion call carries 1–4 questions, each question a header (≤12 characters) and 2–4 options with a label and a description; the response maps each question to the chosen label, and free-text is handled by offering an “Other” choice and passing the typed text rather than the literal "Other". [Official] Handle approvals and user input · AnthropicT1-official original The structure is the point: bounded multiple-choice makes the human’s answer fast to give and unambiguous to route back into the agent’s flow.

The application side: the canUseTool callback

AskUserQuestion is the tool Claude calls; canUseTool is the callback your application implements to receive these interruptions and answer them. It fires on two triggers: when Claude wants to use a tool (a permission check) and when Claude calls AskUserQuestion (a clarification). [Official] Handle approvals and user input · AnthropicT1-official original So one callback is the single surface through which your app both gates tools and answers questions; it returns PermissionResultAllow / PermissionResultDeny (Python) or { behavior: "allow" | "deny" } (TS). [Official] Handle approvals and user input · AnthropicT1-official original

And its response is far richer than yes/no — the docs document six patterns:

Two interactions are worth memorizing. The callback is skipped in dontAsk mode — anything not pre-approved is denied without ever calling it (it is the last step of the permission chain, and dontAsk short-circuits before reaching it). [Official] Handle approvals and user input · AnthropicT1-official original And for a human who is not watching the terminal, the PermissionRequest hook can fire an external notification (Slack, email, push) when Claude is waiting on approval. [Official] Handle approvals and user input · AnthropicT1-official original

The interview pattern: escalate before you start

Escalation is strongest when it is proactive — ask the questions before any work depends on the answers. That is the interview pattern from D3.5: Claude interviews you with AskUserQuestion, writes a spec, and a fresh session implements from it. [Official] Best practices for Claude Code · AnthropicT1-official original The natural home for this is plan mode, since “clarifying questions are especially common in plan mode, where Claude explores the codebase and asks questions before proposing a plan.” [Official] Handle approvals and user input · AnthropicT1-official original Front-loading the questions resolves ambiguity while it is still cheap — before a single edit is built on a guessed interpretation.

The check-in as a control point

A clarifying question is also a deliberate pause, and the SDK treats it as one: the canUseTool callback “can stay pending indefinitely” while a human decides, and for long delays the agent can return a "defer" decision that ends the query and resumes later from the persisted session. [Official] Handle approvals and user input · AnthropicT1-official original That makes escalation the upstream half of human-in-the-loop — the agent yields control at the moment of uncertainty, and the human resolves what the model could not (the downstream half, routing low-confidence output to review, is D5.5). The hands-on, use-side treatment of when and how to prompt for clarification is the handbook’s territory (its escalation-patterns chapter is forthcoming).

Practice

Exam essentials

• Escalate, don’t guess — design the agent to surface an ambiguous or blocked decision rather than silently pick an interpretation; the cost of asking is one round trip, the cost of guessing wrong is the whole task.
• AskUserQuestion — 1–4 questions per call, 2–4 bounded options each (label + description, short header); the answer maps question to chosen label; free-text via an “Other” option. The bounded shape makes answers fast and routable.
• canUseTool — the app-side callback — fires on two triggers (Claude wants a tool / Claude calls AskUserQuestion); six response patterns: approve, approve-with-changes (updatedInput), approve-and-remember (PermissionUpdate), reject, suggest-alternative, redirect-entirely. Skipped in dontAsk mode; the PermissionRequest hook sends external notifications while waiting.
• Proactive beats reactive — the interview pattern and plan mode front-load clarifying questions, resolving ambiguity while it is still cheap, before work is built on a guess.
• Subagents cannot escalate — AskUserQuestion is unavailable in subagents, so resolve open questions in the coordinator before delegating a fully-specified task.
• Check-in as control point — a clarifying question is a deliberate pause; the callback can stay pending or defer-and-resume, making escalation the upstream half of human-in-the-loop (D5.5 is the downstream half).