S1 · Customer Support Resolution Agent

spans 60% of the blueprint D1 27% D2 18% D5 15% ~15 items per lab on the exam 20 items in the bank

Domains this lab exercises

Expected items apply the blueprint weight to a 60-item exam. Bank items are what exists for this lab today — a coverage figure, never a score.

Domain	Weight	Expected items	Statements	Bank items for this lab
D1 Agentic Architecture & Orchestration	27%	16.2	7	9
D2 Tool Design & MCP Integration	18%	10.8	5	5
D5 Context Management & Reliability	15%	9.0	6	6

Task statements in play 8 of 30

Each statement is a published objective; every practice item on this site cites one. Expand a row for the guide's key facts and, where the guide names them, the anti-patterns that supply that statement's distractors.

ID	Statement	Domain	Bank items
1.1	Design and implement agentic loops for autonomous task execution Keys The agentic loop lifecycle: sending requests to Claude, inspecting stop_reason ("tool_use" vs "end_turn"), executing requested tools, and returning results for the next iteration How tool results are appended to conversation history so the model can reason about the next action The distinction between model-driven decision-making (Claude reasons about which tool to call next based on context) and pre-configured decision trees or tool sequences Implementing agentic loop control flow that continues when stop_reason is "tool_use" and terminates when stop_reason is "end_turn" Adding tool results to conversation context between iterations so the model can incorporate new information into its reasoning Avoiding anti-patterns such as parsing natural language signals to determine loop termination, setting arbitrary iteration caps as the primary stopping mechanism, or checking for assistant text content as a completion indicator Anti-patterns parsing natural language signals to determine loop termination setting arbitrary iteration caps as the primary stopping mechanism checking for assistant text content as a completion indicator	D1	3
1.4	Implement multi-step workflows with enforcement and handoff patterns Keys The difference between programmatic enforcement (hooks, prerequisite gates) and prompt-based guidance for workflow ordering When deterministic compliance is required (e.g., identity verification before financial operations), prompt instructions alone have a non-zero failure rate Structured handoff protocols for mid-process escalation that include customer details, root cause analysis, and recommended actions Implementing programmatic prerequisites that block downstream tool calls until prerequisite steps have completed (e.g., blocking process_refund until get_customer has returned a verified customer ID) Decomposing multi-concern customer requests into distinct items, then investigating each in parallel using shared context before synthesizing a unified resolution Compiling structured handoff summaries (customer ID, root cause, refund amount, recommended action) when escalating to human agents who lack access to the conversation transcript	D1	3
1.5	Apply Agent SDK hooks for tool call interception and data normalization Keys Hook patterns (e.g., PostToolUse) that intercept tool results for transformation before the model processes them Hook patterns that intercept outgoing tool calls to enforce compliance rules (e.g., blocking refunds above a threshold) The distinction between using hooks for deterministic guarantees versus relying on prompt instructions for probabilistic compliance Implementing PostToolUse hooks to normalize heterogeneous data formats (Unix timestamps, ISO 8601, numeric status codes) from different MCP tools before the agent processes them Implementing tool call interception hooks that block policy-violating actions (e.g., refunds exceeding $500) and redirect to alternative workflows (e.g., human escalation) Choosing hooks over prompt-based enforcement when business rules require guaranteed compliance	D1	5
2.1	Design effective tool interfaces with clear descriptions and boundaries Keys Tool descriptions as the primary mechanism LLMs use for tool selection; minimal descriptions lead to unreliable selection among similar tools The importance of including input formats, example queries, edge cases, and boundary explanations in tool descriptions How ambiguous or overlapping tool descriptions cause misrouting (e.g., analyze_content vs analyze_document with near-identical descriptions) The impact of system prompt wording on tool selection: keyword-sensitive instructions can create unintended tool associations Writing tool descriptions that clearly differentiate each tool's purpose, expected inputs, outputs, and when to use it versus similar alternatives Renaming tools and updating descriptions to eliminate functional overlap (e.g., renaming analyze_content to extract_web_results with a web-specific description) Splitting generic tools into purpose-specific tools with defined input/output contracts (e.g., splitting a generic analyze_document into extract_data_points, summarize_content, and verify_claim_against_source) Reviewing system prompts for keyword-sensitive instructions that might override well-written tool descriptions	D2	3
2.2	Implement structured error responses for MCP tools Keys The MCP isError flag pattern for communicating tool failures back to the agent The distinction between transient errors (timeouts, service unavailability), validation errors (invalid input), business errors (policy violations), and permission errors Why uniform error responses (generic "Operation failed") prevent the agent from making appropriate recovery decisions The difference between retryable and non-retryable errors, and how returning structured metadata prevents wasted retry attempts Returning structured error metadata including errorCategory (transient/validation/permission), isRetryable boolean, and human-readable descriptions Including retriable: false flags and customer-friendly explanations for business rule violations so the agent can communicate appropriately Implementing local error recovery within subagents for transient failures, propagating to the coordinator only errors that cannot be resolved locally along with partial results and what was attempted Distinguishing between access failures (needing retry decisions) and valid empty results (representing successful queries with no matches)	D2	3
5.2	Design effective escalation and ambiguity resolution patterns Keys 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 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	D5	3
5.3	Implement error propagation strategies across multi-agent systems Keys Structured error context (failure type, attempted query, partial results, alternative approaches) as enabling intelligent coordinator recovery decisions The distinction between access failures (timeouts needing retry decisions) and valid empty results (successful queries with no matches) Why generic error statuses ("search unavailable") hide valuable context from the coordinator Why silently suppressing errors (returning empty results as success) or terminating entire workflows on single failures are both anti-patterns Returning structured error context including failure type, what was attempted, partial results, and potential alternatives to enable coordinator recovery Distinguishing access failures from valid empty results in error reporting so the coordinator can make appropriate decisions Having subagents implement local recovery for transient failures and only propagate errors they cannot resolve, including what was attempted and partial results Structuring synthesis output with coverage annotations indicating which findings are well-supported versus which topic areas have gaps due to unavailable sources Anti-patterns Why silently suppressing errors (returning empty results as success) or terminating entire workflows on single failures are both anti-patterns	D5	4
5.5	Design human review workflows and confidence calibration Keys The risk that aggregate accuracy metrics (e.g., 97% overall) may mask poor performance on specific document types or fields Stratified random sampling for measuring error rates in high-confidence extractions and detecting novel error patterns Field-level confidence scores calibrated using labeled validation sets for routing review attention The importance of validating accuracy by document type and field segment before automating high-confidence extractions Implementing stratified random sampling of high-confidence extractions for ongoing error rate measurement and novel pattern detection Analyzing accuracy by document type and field to verify consistent performance across all segments before reducing human review Having models output field-level confidence scores, then calibrating review thresholds using labeled validation sets Routing extractions with low model confidence or ambiguous/contradictory source documents to human review, prioritizing limited reviewer capacity	D5	5

The lab

Rendered from certs/ccar-f-architect-foundations/scenarios/s1.md — the lab document is the source, this page is a view of it.

Primary domains: D1 Agentic Architecture & Orchestration (27%) · D2 Tool Design & MCP Integration (18%) · D5 Context Management & Reliability (15%) — spans 60%

Identical domain profile to s3.md. Whoever owns one should own the other.

Brief

A customer-support resolution agent on the Claude Agent SDK, handling high-ambiguity requests — returns, billing disputes, account issues. It reaches backend systems through custom MCP tools: get_customer, lookup_order, process_refund, escalate_to_human. Target is 80%+ first-contact resolution while knowing when to escalate.

Task statements in play

ID	Statement
1.1	Design and implement agentic loops for autonomous task execution
1.4	Implement multi-step workflows with enforcement and handoff patterns
1.5	Apply Agent SDK hooks for tool call interception and data normalization
2.1	Design effective tool interfaces with clear descriptions and boundaries
2.2	Implement structured error responses for MCP tools
5.2	Design effective escalation and ambiguity resolution patterns
5.3	Implement error propagation strategies across multi-agent systems
5.5	Design human review workflows and confidence calibration

The decisions it tests

Enforcement versus instruction — this exam's favourite distinction. When compliance must be guaranteed, prompt instructions are the wrong tool: they carry a non-zero failure rate. Use programmatic enforcement — hooks and prerequisite gates. The guide's own example: block process_refund until get_customer has returned a verified customer ID. A hook that intercepts the outgoing call and refuses is deterministic; "always verify identity first" in the system prompt is a probability.

Same shape for policy limits: a refund over a threshold gets blocked by an interception hook and redirected to human escalation, not discouraged in prose.

Structured handoff to someone with no transcript. When escalating, the human agent lacks access to the conversation transcript. The guide names four fields in the structured handoff summary — customer ID, root cause, refund amount, recommended action — a structured payload, not "the customer is upset about an order." All four; an answer that drops one is incomplete.

MCP error taxonomy. The isError flag communicates tool failures back to the agent, and the guide draws a distinction between four kinds: transient errors (timeouts, service unavailability), validation errors (invalid input), business errors (policy violations), and permission errors. Uniform responses (a generic "Operation failed") prevent the agent from making appropriate recovery decisions. The structured error metadata the guide asks for is errorCategory (transient/validation/permission), an isRetryable boolean, and human-readable descriptions — plus retriable: false flags and customer-friendly explanations for business rule violations.

On what to do with each kind, the guide states only two dispositions: retry transient errors, and explain business errors to the user. Retrying a business error forever is a classic wrong answer.

> Ours, not the guide's. The guide does not prescribe a disposition for validation or permission > errors. This lab treats validation as fix-the-arguments-and-retry-once and permission as escalate, > because that is what we would ship — but neither arrow is exam content, and neither should be > memorised as though the guide said it. What the guide does say is that retryable and non-retryable > must be distinguishable from the returned metadata so retries are not wasted, and that a subagent > should recover locally from transient failures and propagate only what it cannot resolve, along with > partial results and what was attempted.

Normalizing heterogeneous tool output. Different backends return Unix epochs, ISO 8601 strings, and numeric status codes. A PostToolUse hook normalizes them before the model reasons over them, rather than asking the model to cope.

Reference build

Four stub MCP tools matching the published names, each returning structured errors across all four categories
A prerequisite gate: process_refund refuses until a verified customer ID exists in state
An interception hook blocking refunds above a threshold and redirecting to escalation
A PostToolUse hook normalizing three deliberately mismatched timestamp formats
A structured escalation payload, with a test asserting every required field is present

Traps

Hope over enforcement — a system-prompt instruction where a gate is required. If the question says "must", "guaranteed", or "always", the answer is programmatic.
Detect over prevent — logging refunds for later audit, or adding a confirmation step, instead of removing or gating the capability. Least privilege means removing what the role does not need.
Scale over design — a more capable model to follow instructions "more reliably".
Escalating with a conversation dump instead of a structured summary.
Treating every tool failure as retryable.