Effective Escalation and Ambiguity Resolution Patterns

Task statement 5.2 of the Claude Certified Architect — Foundations (CCA-F) exam — "Design effective escalation and ambiguity resolution patterns" — sits inside Domain 5 (Context Management & Reliability, 15 % exam weight) but reaches into every other domain through the agentic loop. Although Domain 5 is the lightest-weighted of the five domains, community pass reports repeatedly flag task 5.2 as the area where otherwise-strong candidates lose two to three scored questions because they conflate escalation with failure, default to assumption over clarification for high-stakes scenarios, or design escalation payloads that omit the context a human reviewer actually needs. The customer-support-resolution-agent scenario exercises this task statement hardest, with a recurring pattern of questions that force the candidate to choose between "ask", "assume and flag", "degrade gracefully", and "escalate" — with only one correct answer given the stakes and the confidence state described in the scenario stem.

This study note walks through the full surface CCA-F expects you to design: how to detect that a task specification is insufficient, how to shape a targeted clarification request (single-question vs batched), when to ask before executing versus attempt with stated assumptions, the canonical trigger conditions for human escalation, how to assemble an escalation payload that makes human review tractable, how tiered routing works (specialist → manager → system owner), how to produce graceful-degradation output with explicit uncertainty flags, how to resume agent execution after a human supplies clarification, ambiguity ownership in multi-agent systems, threshold calibration to avoid over-escalation, and feeding resolutions back into CLAUDE.md so the same ambiguity never has to be resolved twice. A common-traps section, practice anchors tied to the customer-support-resolution-agent scenario, and a six-question FAQ close the note.

Why Escalation and Ambiguity Resolution Is an Architecture Problem, Not a Prompt Problem

Candidates who approach task 5.2 as "tell Claude to ask for clarification when unsure" consistently pick wrong answers on CCA-F. The exam treats escalation as an architectural capability with four concrete surfaces: a detection mechanism that decides ambiguity exists, a request-or-escalate decision policy that chooses between clarifying and routing to a human, a payload shape the human reviewer consumes, and a re-entry protocol that resumes agent execution with the new information. Every one of those four surfaces is programmatic — schema-enforced tool calls, structured error responses, session state that persists across a human pause, and rule updates written back to configuration files. Prompt-level guidance ("ask if unsure") alone cannot produce any of those surfaces reliably.

Community pain point pp-01 — programmatic enforcement versus prompt-based guidance — applies directly here. When a CCA-F answer choice offers "add a stronger system prompt telling Claude to ask" and a competing answer offers "define a request_clarification tool with a structured schema that the agent must call before high-stakes actions," the structured-tool answer is almost always the correct one. The exam rewards designs that make the escalation pathway a first-class object in the architecture, not a hope that the model does the right thing.

Ambiguity Detection — Identifying When Task Specification Is Insufficient

The first architectural surface is detection. Before an agent can ask a question or escalate, it has to notice that the task as specified is not executable with acceptable confidence. CCA-F treats ambiguity detection as a set of concrete signals — not a vague "the model senses something is wrong."

Six Signals That Should Trigger Ambiguity Handling

1. Missing referent — The task refers to "the user," "the account," or "the report" but multiple candidates exist and the correct one is not distinguishable from context.
2. Underspecified threshold — The task asks for "recent orders" or "high-value customers" without defining the numeric cutoff, and the cutoff materially changes the result.
3. Conflicting constraints — Two instructions in the conversation, system prompt, or CLAUDE.md contradict each other for the current case.
4. Out-of-scope request — The user is asking for something the agent's tool allowlist cannot accomplish, or the request is outside the scope documented in the agent's system prompt.
5. Confidence below threshold on a classification — A tool-based classifier returned a score below the configured confidence threshold.
6. Novel edge case — The current case does not match any of the few-shot examples or runbook patterns provided, suggesting the agent is extrapolating.

Each signal maps to a distinct architectural response. Missing referents and underspecified thresholds are fixed by clarification requests. Out-of-scope requests are fixed by graceful degradation plus escalation. Confidence-below-threshold signals trigger either clarification or escalation depending on stakes. Novel edge cases often trigger escalation with a detailed payload so the resolution can later become a CLAUDE.md rule.

Detection Is a Tool Call, Not a Vibe

The cleanest architecture is to give the agent a structured evaluate_task_completeness tool (or equivalent named tool) that returns a typed verdict: ok, missing_field, ambiguous_reference, out_of_scope, or low_confidence, with an optional details object. The agentic loop then branches on the verdict: ok proceeds, missing_field or ambiguous_reference triggers a clarification request, out_of_scope triggers immediate escalation, and low_confidence consults a stakes table before deciding.

Clarification Request Design — Targeted Single-Question Clarifications vs Batched Questions

Once the agent has decided a clarification is needed, the next design decision is shape: ask one targeted question at a time, or batch several together in a single round-trip. CCA-F tests the trade-off directly.

Single-Question Clarification — When to Prefer It

Single-question clarifications are the right shape when:

• The answer to the first question materially changes which follow-up questions are needed.
• The user is in a conversational channel (chat, voice) where a long questionnaire would feel interrogative.
• The task can proceed incrementally — each answered question unlocks the next planned step.

The cost of single-question clarification is conversational round-trips; the benefit is that you never ask a question whose answer has already been made irrelevant by an earlier answer.

Batched Clarification — When to Prefer It

Batched clarifications are the right shape when:

• The user is a technical operator (API client, ticket submitter) who can answer a structured form in one pass.
• The questions are independent — no answer invalidates any other question.
• The task is high-context-cost to resume repeatedly (for example, a long research task whose setup is expensive).

A batched clarification is typically rendered as a JSON form or a numbered list of yes/no / short-answer questions, with each question tagged by field name so the agent can map answers back programmatically.

The Hybrid Pattern

In practice, production agents alternate. A customer-support agent working a chat channel asks one question at a time; the same agent working an async email ticket sends a single consolidated questionnaire and waits for the response. The choice is controlled by the agent's channel awareness, not by a global preference.

Clarification Timing — Ask Before Executing vs Attempt With Stated Assumptions

A subtler design choice than shape is timing. Should the agent ask for clarification before attempting any action, or should it proceed with a stated assumption and surface the assumption as part of the answer?

Ask Before Executing — When Stakes Are High

Ask before executing when:

• The action is destructive or irreversible (delete account, issue refund, publish content, merge to main).
• The action has external blast radius (sends email to customers, charges a card, calls a paid third-party API).
• The action is bounded by compliance (GDPR data deletion, HIPAA-governed disclosure, financial regulation).

For these cases, proceeding on an unverified assumption and correcting afterward is not a valid recovery — you cannot "un-send" an email or "un-charge" a card. The clarification pause is cheap; the mistake is expensive.

Attempt With Stated Assumptions — When Stakes Are Low and Reversal Is Cheap

Attempt with stated assumptions when:

• The action is read-only (look up a record, fetch a document, generate a draft).
• The output is a draft that a human will review before it becomes authoritative.
• Waiting for clarification would dominate total latency and the user explicitly values speed (for example, a developer-productivity agent assisting mid-keystroke).

In this mode, the agent produces its best-effort output and prefixes or annotates it with the assumption ("I assumed 'last month' means the prior calendar month; confirm if you meant a rolling 30-day window"). The human can either accept or redirect.

The Stakes × Reversibility Matrix

Combine the two dimensions and the policy becomes explicit:

• High stakes, low reversibility → ask before executing. Always.
• High stakes, high reversibility → ask before executing for first-time operations; proceed with flagged assumptions for repeated operations where the pattern is known.
• Low stakes, low reversibility → ask before executing (rare combination; if it exists, the reversibility is the constraint that dominates).
• Low stakes, high reversibility → proceed with stated assumptions.

Escalation Trigger Conditions — Confidence Below Threshold, Missing Authority, Novel Edge Case

Escalation — as opposed to clarification — transfers control to a human (or more authoritative agent). CCA-F expects you to recognize three canonical trigger conditions.

Trigger 1: Confidence Below Threshold

The agent or an underlying classifier returned a confidence score below the configured threshold for the current action's stakes. A refund-issuing agent might require 0.95 confidence on "is this refund policy-compliant"; anything below triggers escalation to a human refund specialist. Thresholds are stakes-scaled — higher-stakes actions demand higher confidence before the agent proceeds autonomously.

Trigger 2: Missing Authority

The agent does not have the tool, permission, or role to perform the requested action. A support agent with read-only CRM access cannot update a billing address; the correct response is not to refuse, not to pretend, and not to attempt a workaround — it is to escalate to an agent (human or otherwise) that has the authority. Missing-authority escalation is almost always correct in scenarios where the tool allowlist excludes the needed action.

Trigger 3: Novel Edge Case

The case does not match any known runbook, CLAUDE.md rule, or few-shot example. The agent's options are (a) extrapolate and pray, (b) escalate with a detailed payload so a human can resolve and document. CCA-F consistently picks (b). Novel cases are the highest-value escalations because their resolution becomes tomorrow's rule.

The Fourth, Implicit Trigger: Explicit User Request

Any time the user says "let me talk to a human," the agent must escalate. This is less an architectural choice and more a compliance floor.

Escalation Payload Design — What Context to Include for Effective Human Review

Escalation is only useful if the human on the receiving end can act quickly. A payload that forces the human to re-investigate the case from scratch destroys most of the value of the autonomous agent's earlier work. CCA-F expects you to design escalation payloads as structured, self-contained hand-offs.

The Minimum Viable Escalation Payload

Every escalation payload should carry:

1. Case identifier — Ticket ID, session ID, user ID; anything that lets the reviewer pull ancillary records.
2. Task summary — One to three sentences stating what the user asked for in plain language.
3. Agent's current hypothesis — What the agent believes the correct action is, with a confidence score.
4. Ambiguity or trigger reason — The specific signal that caused the escalation (which field is missing, which authority is absent, which threshold was missed).
5. Evidence — The subset of tool results, documents, or prior conversation relevant to the decision. Never the full unfiltered history.
6. Proposed options — Two or three concrete actions the reviewer can take with one-click acceptance.
7. Reversibility note — Whether each proposed option is reversible, and what the blast radius is.

A payload that is missing any of items 1–5 creates rework for the human reviewer. Items 6 and 7 are the difference between a 30-second triage and a 10-minute investigation.

Provenance Must Survive the Hand-Off

Every fact in the payload should carry a provenance tag — which tool produced it, which document it came from, when it was observed. The reviewer must be able to distinguish "Claude was told this by the CRM" from "Claude inferred this from the support thread." Provenance loss during escalation is a root cause of human reviewers rubber-stamping bad agent decisions.

Escalation Path Routing — Tiered Escalation (Specialist → Manager → System Owner)

Not every escalation goes to the same human. CCA-F expects you to design tiered routing that matches the nature of the escalation to the appropriate reviewer.

Tier 1: Domain Specialist

The first-line reviewer for routine ambiguities — a support specialist, an on-call engineer, a billing analyst. The specialist has the domain context to resolve most cases and has the authority to act (issue the refund, approve the merge, correct the record). The agent should route here by default when the trigger is a confidence-below-threshold or a missing-field ambiguity.

Tier 2: Team Lead or Manager

The second-line reviewer for cases the specialist cannot resolve. The lead has broader authority (larger refund limits, cross-team coordination, policy interpretation). The agent does not typically route directly here — the specialist does, after first-line review fails.

Tier 3: System Owner or Engineering

The third-line reviewer for issues that are not case-specific but expose a defect in the agent itself — a tool returning inconsistent data, a CLAUDE.md rule producing contradictions, a confidence threshold calibrated wrong. The agent should route here automatically when the trigger is repeated novel-edge-case escalations on the same pattern within a short window — the pattern itself is the problem, not any individual case.

Routing Metadata

A well-designed escalation system tags every payload with the tier and the specific queue. The routing is a function of trigger reason, stakes, and load — a routing service decides which human queue receives the case based on the metadata the agent attaches.

Graceful Degradation — Producing Partial Output With Explicit Uncertainty Flags

Between "resolve autonomously" and "escalate completely" there is a middle path: produce the part of the output the agent is confident about, flag the uncertain part explicitly, and let the downstream consumer decide how to proceed. CCA-F calls this graceful degradation.

When Graceful Degradation Is the Right Choice

• The task has multiple sub-components and only some are blocked by ambiguity.
• The user is a technical consumer that can handle partial output (a pipeline step, an API client).
• Waiting for full resolution would starve downstream consumers with nothing to work on.

A research agent that has confidently answered four of five sub-questions and is uncertain on the fifth should emit the four confident answers with citations and return {answer: null, reason: "insufficient_evidence", trigger_escalation: true} for the fifth — not discard the four confident answers or block until the fifth is resolved.

Uncertainty Flag Shape

Every uncertain component of the output should carry:

• An explicit null or sentinel value instead of a fabricated plausible answer.
• A reason field (insufficient_evidence, ambiguous_reference, out_of_scope, confidence_below_threshold).
• An optional candidates list when the agent has narrowed down to a small set but cannot disambiguate.
• A suggested_action field (request_clarification, escalate_to_specialist, retry_with_context).

Structured uncertainty is the signal downstream consumers need to branch correctly. Prose qualifiers like "I think this is probably correct but I am not sure" do not compose into automated pipelines.

Graceful Degradation Is Not a Substitute for Escalation

Graceful degradation handles the outputs the agent is confident about; the uncertain parts still need an escalation or a clarification. Emitting a structured null and walking away is an abandonment, not a degradation — the flag must be paired with a pathway that eventually resolves it.

Re-entry After Escalation — Resuming Agent Execution With Human-Provided Clarification

An escalation that cannot be re-entered cleanly forces the user to restart the task from scratch, destroying the value of the autonomous work that preceded the escalation. CCA-F expects you to design re-entry as a first-class state-machine transition, not a restart.

Four Components of Clean Re-entry

1. Session persistence — The agent's session state (message history, tool results, partial plan) must be stored when the escalation fires. Agent SDK session APIs handle this; forgetting to persist is a correctness bug.
2. Clarification binding — The human-supplied answer must be bound into the session as if it had been provided upstream, not simply appended as a new user message. A structured resolution payload maps answers back to the specific fields that triggered the pause.
3. Guard-rail re-evaluation — After the clarification is applied, the agent must re-run the ambiguity detection step. If the clarification resolved the original trigger but introduced a new one, the agent must pause again, not barrel through.
4. Audit trail — The resumption record must include who resolved the ambiguity, when, and how. This is required for compliance on high-stakes actions and powers the feedback loop that updates CLAUDE.md.

Forks vs Resumes

Session forking lets you resume from a pre-escalation checkpoint while keeping the escalation record intact — useful when the human wants to explore an alternative resolution without losing the original context. Forking is a task 1.7 topic but its re-entry usage lives in task 5.2.

Ambiguity Resolution in Multi-Agent Systems — Which Agent Owns Clarification

In a coordinator-subagent system, an ambiguity can surface at any level — inside a subagent's task, at the coordinator's decomposition step, or at the user-facing layer. CCA-F expects you to know which agent owns the clarification.

Rule 1: The Subagent Escalates to the Coordinator, Not Directly to the User

A subagent that encounters ambiguity during its assigned sub-task returns a structured escalation to the coordinator — not a direct message to the end user. The coordinator has the full task context; the subagent has only its slice. User-facing communication is a coordinator responsibility. This boundary is a direct consequence of subagent context isolation (community pain point pp-03): the subagent cannot assume it understands what the user originally asked.

Rule 2: The Coordinator Resolves, Delegates, or Escalates

When the coordinator receives a subagent escalation, it has three options:

1. Resolve locally — The coordinator has context the subagent lacked; the coordinator answers the sub-question itself (for example, by supplying a default that is safe in context) and re-dispatches the subagent with the clarification bound in.
2. Delegate to a peer — A different subagent with different tools or data may be able to resolve the ambiguity. The coordinator routes the question to that peer before going to the user.
3. Escalate to the user or a human reviewer — If neither local resolution nor peer delegation works, the coordinator presents the ambiguity to the user or human reviewer with a consolidated payload.

Rule 3: Never Broadcast Ambiguity Questions to Users from Multiple Agents

Parallel subagents that each independently discover the same ambiguity should not each ask the user the same question. The coordinator aggregates and deduplicates. A user who receives three near-identical clarification questions in rapid succession is the symptom of a broken multi-agent design.

Avoiding Over-Escalation — Setting Thresholds to Prevent Trivial Human Interruptions

A system that escalates too often is almost as broken as one that escalates too rarely. Over-escalation burns human attention, destroys automation ROI, and trains reviewers to rubber-stamp requests without reading them. CCA-F tests threshold calibration as a deliberate architectural choice.

Symptoms of Over-Escalation

• Escalation rate above 20 % of tasks (exact thresholds vary; CCA-F scenarios often give you a number).
• Repeated escalations on the same pattern (the same missing field, the same authority gap) across different cases.
• Reviewer queue accumulating faster than reviewers can clear it.
• Reviewers approving without reading ("approve-all" behaviour).

Three Levers for Reducing Over-Escalation

1. Lower the confidence threshold for low-stakes actions — A threshold of 0.9 for a routine address lookup is miscalibrated; 0.7 is often adequate. Thresholds should be set per-action, not globally.
2. Codify common resolutions into CLAUDE.md rules — If the same ambiguity pattern escalates repeatedly, the resolution should be captured as a rule. The next instance resolves autonomously.
3. Introduce a clarification path before the escalation path — If the ambiguity is user-resolvable (missing field), ask first. If clarification fails or the user is unavailable, then escalate.

Under-Escalation Symptoms — The Other Failure Mode

• Irreversible actions taken on low-confidence decisions.
• High false-positive rate on customer-facing outputs.
• Downstream human rework because the agent produced bad data that was trusted as correct.

The target is a calibrated middle. Threshold calibration uses data: start conservative, measure escalation rate and false-negative rate together, and tune the thresholds until both are inside tolerance bands.

Documenting Ambiguity Resolutions — Feeding Resolutions Back to CLAUDE.md or Rules

The most valuable escalation is one that never has to happen again. When a human resolves an ambiguity, the resolution should flow back into the agent's configuration so the next instance of the same pattern is handled autonomously. CCA-F expects you to recognize CLAUDE.md and rule updates as the feedback loop.

The Three-Stage Feedback Loop

1. Capture — Every resolved escalation records the original trigger, the human's decision, and the reasoning.
2. Pattern detection — A periodic review (weekly or automated) looks for escalation patterns that repeat across cases — same trigger reason, same resolution.
3. Codification — The repeating pattern becomes a rule in CLAUDE.md (or a path-specific scoped rule) that instructs the agent how to handle the pattern autonomously on future occurrences.

What to Write Into CLAUDE.md

A codified resolution rule has four parts:

• Trigger pattern — The observable signal that identifies this ambiguity (for example, "the user says 'recent' without a date").
• Default assumption — The resolution the agent should apply autonomously (for example, "interpret 'recent' as the prior 30 calendar days").
• Safety boundary — The conditions under which the default does not apply and escalation is still required (for example, "if the user is in a regulated-reporting context, still ask").
• Source link — A pointer to the original escalation(s) that motivated the rule, for audit and future tuning.

Rule Scoping

Codified rules should live at the narrowest CLAUDE.md scope that covers their applicability — project-level for patterns specific to one agent, directory-level for patterns specific to a codebase area, user-level for personal-preference patterns. Global CLAUDE.md should only carry resolutions that are universally true; over-globalization of project-specific resolutions creates the monolithic-CLAUDE.md anti-pattern (community pain point pp-08).

Plain-English Explanation

The mechanics above become intuitive when mapped to systems candidates already know. Three analogies from very different domains cover the full task 5.2 surface.

Analogy 1: The New Hire at the Front Desk

Picture a brand-new hire working the front desk at a hotel, trained well but still learning the edge cases. A guest asks for something routine — the Wi-Fi password — and the new hire answers instantly (low stakes, high confidence, no escalation). A guest asks for a room upgrade — the new hire checks the system and finds an ambiguity ("the guest is booked for a deluxe but the note says 'upgrade on availability' without specifying to which tier"). The new hire does not guess and hand out a presidential suite; they do not ignore the note and stick with deluxe either. They ask a targeted single question — "would you like a junior suite or a standard suite upgrade?" — because the channel is conversational. A guest asks to be comped three nights for a complaint. This is over the new hire's authority; the system does not even have a "comp three nights" tool in their allowlist. They escalate to the shift manager with a structured payload: guest name, complaint summary, what was already offered, the system's suggested compensation range, and a reversibility note. The manager approves with one click and the case resumes. The next week, the manager notices a dozen similar comp requests; the shift manager writes a new rule ("up to two nights comp allowed for verified room-not-ready complaints") and publishes it to the desk handbook. The new hire can now resolve those cases autonomously. That handbook update is CLAUDE.md codification. The new hire is the Claude agent, the handbook is CLAUDE.md, the manager is the tier-1 specialist, and the hotel is the production system. Every design decision in task 5.2 has a direct counterpart.

Analogy 2: The Airport Control Tower — Tiered Escalation and Authority

An airport control tower runs three tiers of controllers. Ground controllers handle taxiway movements. Tower controllers handle takeoffs and landings. Approach controllers handle the airspace above the airport. Each tier has a defined authority envelope; each tier escalates to the next when the situation exceeds its authority. A pilot asking for an unusual taxi route goes to ground. If ground cannot resolve (the route crosses an active runway), ground escalates to tower. If tower cannot resolve (the unusual route is tangled with an arrival), tower escalates to approach. The pilot never calls approach directly — the chain of tiers preserves authority boundaries and keeps radio traffic coherent. When an unprecedented situation happens — say, a new aircraft type with unusual taxi characteristics — the resolution becomes a new procedure the airport documents. All future instances are handled at ground. The control-tower architecture is the coordinator-subagent escalation pattern: the lower tier always escalates up, never sideways, never jumping a tier; the resolution is codified into procedures so authority at the lower tier expands over time.

Analogy 3: The Emergency Room Triage — Graceful Degradation and Thresholds

An emergency room triage nurse sees a patient and makes three parallel decisions: what can I definitely conclude, what is uncertain, and what is outside my authority. The nurse can confidently record vital signs (confident output). The nurse is uncertain whether a symptom is cardiac or musculoskeletal (uncertain output — flagged, not fabricated). The nurse does not have authority to prescribe morphine (out-of-authority — escalated to a doctor). The nurse hands the doctor a structured chart: patient ID, vitals, observations, suspected categories with a confidence score, and proposed next actions. The doctor reviews the chart and makes the authoritative call. The chart is the escalation payload; the vitals are the gracefully-degraded confident output; the suspected categories are the candidates list; the chart's structured shape is why the doctor can act in thirty seconds instead of thirty minutes. This is exactly the task 5.2 pattern — produce what you can, flag what you cannot, escalate with structure, preserve provenance.

Which Analogy Fits Which Exam Question

• Questions about clarification timing and codification → new-hire analogy.
• Questions about tiered routing and coordinator-subagent escalation → control-tower analogy.
• Questions about graceful degradation and escalation payload shape → ER triage analogy.

Common Exam Traps

Community pass reports identify five recurring trap patterns around task 5.2 that appear disguised as plausible distractor choices. All five are worth memorizing before exam day.

Trap 1: Treating Escalation as Task Failure

Escalation is a successful architectural outcome, not a failure. An agent that escalates a low-confidence refund to a specialist has done the right thing. Distractor answers frame escalation as "the agent failed to complete the task" and propose instead to lower the confidence threshold or strengthen the prompt so the agent proceeds autonomously. Both proposals are wrong for high-stakes actions. Escalation is not a bug; it is the feature.

Trap 2: Picking Assumption Over Clarification for High-Stakes Tasks

For high-stakes or irreversible actions, clarification is preferred over assumption — full stop. Distractor answers argue for "proceed with a stated assumption to avoid slowing the user down" even on refund, account-delete, or publish-to-production actions. These answers are wrong. Speed optimization is never a valid reason to skip clarification on an irreversible operation.

Trap 3: Dumping the Full Conversation Into the Escalation Payload

Escalation payloads must be structured summaries with explicit provenance, not raw conversation transcripts. Answers that propose "forward the full chain-of-thought and tool history to the reviewer" are wrong because they bury the decision-relevant information and destroy review throughput.

Trap 4: Subagent Escalates Directly to the User

In a coordinator-subagent design, subagents escalate up to the coordinator, and the coordinator escalates up to the user or human reviewer. Answers that describe a subagent asking the end user for clarification directly are wrong. The boundary is architectural, not stylistic.

Trap 5: Always-Escalate as the Safe Default

Over-escalation is a distinct failure mode from under-escalation. Answers that propose "escalate any case with less than full confidence" destroy automation value and train reviewers into approve-all behaviour. The correct posture is stakes-scaled thresholds — high-stakes actions get high thresholds and mandatory escalation on uncertainty; low-stakes actions get lower thresholds and graceful degradation on uncertainty.

Practice Anchors

Task 5.2 concepts show up most heavily in the customer-support-resolution-agent scenario. Multi-agent-research-system exercises the coordinator-subagent escalation boundary. Treat the two scenarios below as the architecture spine for task 5.2 questions.

Customer-Support-Resolution-Agent Scenario

In this scenario, a customer-support agent handles inbound tickets spanning FAQ lookups, order-status queries, refund requests, and account changes. Task 5.2 questions target: the ambiguity detection step that classifies tickets before routing; the clarification shape (single-question in the chat channel, batched in email intake); the decision policy for high-stakes actions (refund approvals require explicit clarification, not assumption); the escalation payload design (structured ticket summary plus confidence score plus proposed action, not the raw chat log); the tiered routing between support specialists, team leads, and engineering; and the re-entry flow when a specialist supplies a clarification and the agent resumes the ticket. Expect questions that pit "stronger system prompt telling the agent to ask" against "structured request_clarification tool with a typed schema" — the structured tool is almost always correct.

Multi-Agent-Research-System Scenario

In this scenario, a coordinator dispatches research subagents to parallel sub-topics, and each subagent may encounter ambiguity in its slice of the task. Task 5.2 questions target: the rule that subagents escalate to the coordinator (not directly to the user); the coordinator's three-way decision between local resolution, peer delegation, and user escalation; graceful degradation when some sub-topics are confidently answered and others require clarification; and the consolidation of multiple subagent ambiguities into a single aggregated user-facing clarification rather than a broadcast of three separate questions.

FAQ — Escalation and Ambiguity Top 6 Questions

When should a Claude agent ask for clarification instead of proceeding with an assumption?

Ask for clarification whenever the action is high-stakes or irreversible — refunds, account changes, publishing content, merging to production branches, charging cards, sending customer-facing communication. Proceed with a stated assumption only when the action is low-stakes and easily reversible — generating a draft, running a read-only query, returning a best-effort search result that a human will review. The stakes-reversibility matrix is the decision rule. On CCA-F, for high-stakes actions, "ask before executing" is almost always the correct answer; candidates who pick "proceed with a confidence disclaimer" to avoid slowing the user down consistently miss this pattern.

What is the difference between clarification and escalation in a Claude agent?

Clarification is a user-facing question the agent asks to resolve a missing or ambiguous input — the user is presumed able to answer and the task resumes immediately when they do. Escalation is a transfer of control to a human reviewer (or a more authoritative agent) when the trigger is something the user cannot resolve — missing authority, confidence below threshold on a stakes-scaled action, or a novel edge case that requires human judgment. Clarification keeps the user in the loop; escalation brings a third party in. A well-designed agent has both pathways and uses each for the cases it fits.

How should I design an escalation payload so a human reviewer can act quickly?

Include seven fields at minimum: case identifier, task summary in plain language, agent's current hypothesis with a confidence score, the specific ambiguity or trigger reason, filtered evidence with provenance tags (not the full conversation), two or three proposed actions the reviewer can approve with one click, and a reversibility note for each proposed action. A reviewer should be able to triage the case in about thirty seconds. The worst anti-pattern — which CCA-F penalizes — is dumping the raw agent conversation history into the payload and asking the reviewer to read through it.

How do I prevent an agent from over-escalating and burning out human reviewers?

Three levers: (1) calibrate confidence thresholds per-action, not globally — routine lookups should use lower thresholds than irreversible writes; (2) introduce a clarification path before the escalation path so user-resolvable ambiguities never reach a human reviewer; (3) codify repeating resolution patterns into CLAUDE.md rules so the same ambiguity does not escalate twice. Over-escalation is a distinct failure mode from under-escalation, and CCA-F scenarios often present "always-escalate on uncertainty" as a plausible but wrong answer because it trains reviewers into approve-all behaviour.

In a coordinator-subagent system, which agent should ask the user for clarification?

The coordinator, not the subagent. Subagents escalate up to the coordinator through a structured escalation record; the coordinator has three options — resolve locally using context the subagent lacked, delegate to a peer subagent that may be able to resolve the ambiguity, or escalate up to the user or a human reviewer. Direct subagent-to-user communication is wrong in a well-designed multi-agent system because subagent context isolation (community pain point pp-03) means the subagent does not have the full task context to present a coherent question. The coordinator also deduplicates when multiple parallel subagents discover the same ambiguity.

How do I resume agent execution cleanly after a human resolves an escalation?

Four components are required: persist the agent's session state (message history, tool results, partial plan) when the escalation fires; bind the human's resolution as a structured payload mapped back to the specific fields that triggered the pause (not as a raw appended user message); re-run the ambiguity detection step after the clarification is applied so any new trigger is caught before the agent proceeds; and record an audit trail of who resolved the ambiguity, when, and how. Session forking lets you branch from the pre-escalation checkpoint when the human wants to explore an alternative resolution without discarding the original context. On CCA-F, answers that propose "restart the task with the clarification prepended to the original prompt" or "append the answer as a new user message" are wrong because they lose state.

Further Reading

• Building effective agents — escalation and human-in-the-loop: https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop
• Handle tool calls — tool_result format and error responses: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Subagents in the Agent SDK — error propagation and session re-entry: https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• CLAUDE.md configuration — codifying resolutions as rules: https://docs.anthropic.com/en/docs/claude-code/claude-md
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents

Related ExamHub topics: Conversation Context Across Long Interactions, Human Review Workflows and Confidence Calibration, Multi-Step Workflows Enforcement and Handoff, Error Propagation in Multi-Agent Systems.