Domains D1

Agentic Architecture & Orchestration

D1 is 27% of CCAR-F — about 16.2 of the 60 items — across 7 published task statements, roughly 2.3 items per statement.

Weight
27%
Expected items
16.2/60
Task statements
7
Scenarios reaching it
3/6
Named anti-patterns
3
Items in bank
26

Scenarios that reach D1

3 of the 6 published scenarios name D1 as a primary domain, and any exam presents 4 of the 6.

  • S1 Customer Support Resolution Agent

    An Agent SDK support agent handling returns, billing disputes, and account issues through custom MCP tools (get_customer, lookup_order, process_refund, escalate_to_human), targeting 80%+ first-contact resolution while knowing when to escalate.

    D1 — this domain D2 D5 spans 60% of the blueprint
  • S3 Multi-Agent Research System

    A coordinator agent delegating to specialized subagents — web search, document analysis, synthesis, report generation — producing comprehensive cited reports.

    D1 — this domain D2 D5 spans 60% of the blueprint
  • S4 Developer Productivity with Claude

    An Agent SDK productivity agent helping engineers explore unfamiliar codebases, understand legacy systems, generate boilerplate, and automate repetitive tasks, using the built-in tools (Read, Write, Bash, Grep, Glob) and integrating MCP servers.

    D1 — this domain D2 D3 spans 65% of the blueprint

All 6 scenarios →

All 7 task statements

  1. 1.1

    Design and implement agentic loops for autonomous task execution

    3 items

    What the guide expects you to know

    • 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 the guide names for 1.1

    The guide names these explicitly as practices to avoid. It says nothing about how exam items are constructed, so treat them as engineering guidance rather than as a prediction of the options you will be shown. In our experience they also make the most authentic practice distractors, which is our judgement, not the guide’s.

    • 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
  2. 1.2

    Orchestrate multi-agent systems with coordinator-subagent patterns

    4 items

    What the guide expects you to know

    • Hub-and-spoke architecture where a coordinator agent manages all inter-subagent communication, error handling, and information routing
    • How subagents operate with isolated context—they do not inherit the coordinator's conversation history automatically
    • The role of the coordinator in task decomposition, delegation, result aggregation, and deciding which subagents to invoke based on query complexity
    • Risks of overly narrow task decomposition by the coordinator, leading to incomplete coverage of broad research topics
    • Designing coordinator agents that analyze query requirements and dynamically select which subagents to invoke rather than always routing through the full pipeline
    • Partitioning research scope across subagents to minimize duplication (e.g., assigning distinct subtopics or source types to each agent)
    • Implementing iterative refinement loops where the coordinator evaluates synthesis output for gaps, re-delegates to search and analysis subagents with targeted queries, and re-invokes synthesis until coverage is sufficient
    • Routing all subagent communication through the coordinator for observability, consistent error handling, and controlled information flow
  3. 1.3

    Configure subagent invocation, context passing, and spawning

    3 items

    What the guide expects you to know

    • The Task tool as the mechanism for spawning subagents, and the requirement that allowedTools must include "Task" for a coordinator to invoke subagents
    • That subagent context must be explicitly provided in the prompt—subagents do not automatically inherit parent context or share memory between invocations
    • The AgentDefinition configuration including descriptions, system prompts, and tool restrictions for each subagent type
    • Fork-based session management for exploring divergent approaches from a shared analysis baseline
    • Including complete findings from prior agents directly in the subagent's prompt (e.g., passing web search results and document analysis outputs to the synthesis subagent)
    • Using structured data formats to separate content from metadata (source URLs, document names, page numbers) when passing context between agents to preserve attribution
    • Spawning parallel subagents by emitting multiple Task tool calls in a single coordinator response rather than across separate turns
    • Designing coordinator prompts that specify research goals and quality criteria rather than step-by-step procedural instructions, to enable subagent adaptability
  4. 1.4

    Implement multi-step workflows with enforcement and handoff patterns

    3 items

    What the guide expects you to know

    • 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
  5. 1.5

    Apply Agent SDK hooks for tool call interception and data normalization

    5 items

    What the guide expects you to know

    • 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
  6. 1.6

    Design task decomposition strategies for complex workflows

    5 items

    What the guide expects you to know

    • When to use fixed sequential pipelines (prompt chaining) versus dynamic adaptive decomposition based on intermediate findings
    • Prompt chaining patterns that break reviews into sequential steps (e.g., analyze each file individually, then run a cross-file integration pass)
    • The value of adaptive investigation plans that generate subtasks based on what is discovered at each step
    • Selecting task decomposition patterns appropriate to the workflow: prompt chaining for predictable multi-aspect reviews, dynamic decomposition for open-ended investigation tasks
    • Splitting large code reviews into per-file local analysis passes plus a separate cross-file integration pass to avoid attention dilution
    • Decomposing open-ended tasks (e.g., "add comprehensive tests to a legacy codebase") by first mapping structure, identifying high-impact areas, then creating a prioritized plan that adapts as dependencies are discovered
  7. 1.7

    Manage session state, resumption, and forking

    3 items

    What the guide expects you to know

    • Named session resumption using --resume <session-name> to continue a specific prior conversation
    • fork_session for creating independent branches from a shared analysis baseline to explore divergent approaches
    • The importance of informing the agent about changes to previously analyzed files when resuming sessions after code modifications
    • Why starting a new session with a structured summary is more reliable than resuming with stale tool results
    • Using --resume with session names to continue named investigation sessions across work sessions
    • Using fork_session to create parallel exploration branches (e.g., comparing two testing strategies or refactoring approaches from a shared codebase analysis)
    • Choosing between session resumption (when prior context is mostly valid) and starting fresh with injected summaries (when prior tool results are stale)
    • Informing a resumed session about specific file changes for targeted re-analysis rather than requiring full re-exploration