Domain 1: Agentic Architecture & Orchestration (27%)

7 Task Statements / Lessons

1.1 Agentic Loops

Core idea: An agent = Claude + tools + the deterministic code that runs the loop.

Lifecycle:

1. Send Messages API request (system + history + tool definitions)
2. Read stop_reason
3. "tool_use" → execute tool(s), append tool_result user message, loop
4. "end_turn" → present final answer and stop

Key rule: stop_reason is the only reliable control signal. Never rely on:

• Natural language completion phrases
• Presence of text content
• Fixed iteration limits as primary stop

Exam trap: “Stop after N iterations” is offered as a fix for premature termination — reject it. Caps are safety nets only.

Build exercise focus: Multi-tool agent that correctly continues across sequential tool calls.

1.2 Multi-Agent Orchestration

Patterns for coordinating multiple specialised agents (supervisor, hierarchical, peer-to-peer, sequential pipelines).
Decide when a single agent with tools is sufficient vs when sub-agents earn their own context.

1.3 Subagent Invocation and Context Passing

How to invoke a subagent, what context to pass, what to keep private, how results return to the parent.

1.4 Workflow Enforcement and Handoff

When to enforce deterministic business rules in code vs letting the model decide.
Handoff protocols between agents or between agent and human.

1.5 Agent SDK Hooks

Using hooks for pre/post tool execution, logging, guardrails, and custom control flow inside the Agent SDK.

1.6 Task Decomposition Strategies

Breaking complex goals into subtasks that map cleanly to agents/tools.
Avoid over-decomposition that multiplies context-switching cost.

1.7 Session State and Resumption

Persisting conversation / tool state across sessions, resuming long-running agent work, handling interrupted turns (pause_turn etc.).

---

Study priority: Domain 1 is the single highest-weighted area. Master the loop lifecycle and the three anti-patterns before anything else.

CCAR-F Domain 1 · Task 1.1

What You Need to Know

On its own, Claude answers one request with one response. To act, such as looking up an order, it needs tools: functions in your code that you describe to Claude in the request. Claude does not run a tool you define. When it needs one, its response asks for the call, and your code runs the function and sends the result back. An agent is Claude, its tools and the code that keeps this exchange going.

That code is the agentic loop, the core execution cycle behind every Claude-based agent. It is deterministic control flow, defined in code, not a prompt trick, a retry loop or a chatbot turn. Your code sends a request, runs any tools Claude asks for, and sends the results back until Claude has finished. The stop_reason field in each response says whether to go round again. The other Domain 1 lessons, on orchestration, subagents, hooks and sessions, all build on this loop.

A glazier runs an agent that answers customer messages. When a customer asks for their fitting date, the agent must look up the order and check the fitting diary before it replies. An agent with a broken loop stops halfway through a task like this in production.

The Agentic Loop Lifecycle

The loop has four steps, repeated until Claude has finished.

1. Send a request to Claude via the Messages API. It includes the conversation history: system prompt, prior messages, and any tool results from the previous iteration.
2. Inspect the stop_reason field in the response. It is the authoritative signal for what happens next. Two of its values matter for agentic loops:
   • "tool_use": Claude wants to call one or more tools. The loop continues.
   • "end_turn": Claude has finished its work. The loop terminates.
3. If stop_reason is "tool_use", execute the requested tool(s), append the tool results to the conversation history as a new message, and send the updated conversation back to Claude.
4. If stop_reason is "end_turn", the agent has finished. Present the final response to the user.

The glazier's agent gets "tool_use" for the order lookup and again for the diary check, then "end_turn" with the reply.

Step 3 is where loops break. Tool results must be appended to the conversation history. Otherwise the model never sees what the tool returned, so it has nothing new to reason about on the next iteration.

Key Concept: The stop_reason field is the only reliable signal for loop control. It is deterministic and unambiguous. Never use natural language parsing, text content checks, or arbitrary iteration caps as your primary stopping mechanism.

Model-Driven Decision-Making

In an agentic loop, Claude decides which tool to call from the current context. This is model-driven decision-making: the model reads the task, weighs the available tools and picks one. In a pre-configured decision tree or fixed tool sequence, the developer hard-codes which tool runs when.

Model-driven approaches flex. Claude adapts to situations the developer never mapped out, handles edge cases, and chains tools in orders nobody planned.

The exception is business logic that demands deterministic compliance, such as financial operations, security checks and regulatory requirements. There, programmatic enforcement overrides that flexibility. Task Statement 1.4 covers this.

The Three Anti-Patterns

Anti-Pattern 1: Parsing natural language signals. The code checks whether Claude said "I'm done" or "task complete". Natural language is ambiguous. stop_reason exists to remove that ambiguity.

Anti-Pattern 2: Arbitrary iteration caps as the primary stopping mechanism. The code stops after a fixed count. Caps are acceptable as a safety net against runaway agents, never as the primary control.

Anti-Pattern 3: Checking for assistant text content as a completion indicator. The code uses response.content[0].type == "text" to decide the loop is finished. Claude can return text alongside tool_use blocks. Text presence does not tell you whether the agent is finished.

Practical Example: The Premature Termination Bug

The glazier's agent works for simple queries but sometimes stops mid-task on complex ones. Its code checks if response.content[0].type == "text" to determine completion. Claude returns "Let me look up your order" alongside a tool_use block. The code sees text in position [0], concludes the agent is finished and returns the incomplete response.

The fix is to check stop_reason instead of the content type: continue on "tool_use", terminate on "end_turn".

In the exam

Get this lifecycle right and most of Domain 1 falls into place. The keyed answer continues on "tool_use", terminates on "end_turn", and rejects all three anti-patterns. The exam favours model-driven tool selection because it flexes, except where deterministic compliance calls for programmatic enforcement.

Common Exam Distractor: The exam frequently presents iteration caps as a fix for premature termination. Reject these answers. Caps address runaway loops, not premature exits.

Current state note (checked 6 October 2026): The Messages API also returns pause_turn, max_tokens, stop_sequence, refusal and model_context_window_exceeded. A production loop must handle them. Treat any value other than end_turn as "not finished, check why".

Exam Traps

• Using response.content[0].type == 'text' to determine loop completion
• Setting arbitrary iteration caps as the primary stopping mechanism
• Parsing natural language phrases like 'I'm done' to decide loop termination
• Leaving tool results out of the conversation history

Practice Scenario

A customer support agent sometimes exits too early. Its loop decides it is finished whenever response.content[0].type == 'text', so it stops even while Claude still has tools to call. What is wrong, and what is the fix?

Build Exercise: Build a Multi-Tool Agent Loop (45 minutes)

What you'll learn:

• How the agentic loop lifecycle works with the Messages API
• Why stop_reason is the authoritative signal for loop control
• How to handle tool_use and end_turn stop_reason values correctly
• How to append tool results to conversation history for multi-turn execution
• When safety iteration caps are appropriate versus inappropriate

Steps:

1. Set up a Claude API client with two tools: a calculator tool and a web search stub.
2. Implement the agentic loop that sends requests to Claude and inspects stop_reason after each response.
3. Handle the tool_use stop_reason by executing the requested tool, creating a tool result message, and appending it to conversation history.
4. Handle the end_turn stop_reason by extracting and returning the final response.
5. Test with a prompt that requires multiple sequential tool calls.
6. Add a safety iteration cap of 20 as a maximum bound (not the primary stopping mechanism).

Sources

• Claude Agent SDK Overview — Anthropic
• Messages API Reference — Anthropic
• Tool use overview — Anthropic
• Building with Claude API (Skilljar) — Anthropic
• CCAR-F Exam Guide v1.0: Task Statement 1.1 — Anthropic

CCAR-F Domain 1 · Task 1.2

What You Need to Know

Multi-agent orchestration is several Claude agents working together on one complex task. A coordinator agent receives the task and splits it up. Subagents each handle one specialised task. In the hub-and-spoke pattern, the coordinator is the hub and the subagents are the spokes. The coordinator's split of a task into subtopics is its decomposition.

Hub-and-Spoke Architecture

The coordinator receives the initial task and decomposes it. It decides which subagents to invoke and passes context to them. It aggregates their results, handles errors, and routes information between them. Each subagent receives instructions from the coordinator and returns results to it.

All communication flows through the coordinator. Subagents never communicate directly with each other.

One hub gives three things:

1. Observability: you can log and monitor every message in one place.
2. Consistent error handling: the coordinator applies uniform error recovery policies.
3. Controlled information flow: the coordinator decides what context each subagent receives.

Key Concept: Routing all inter-subagent communication through the coordinator is the foundational architectural constraint of hub-and-spoke orchestration.

The Critical Isolation Principle

Isolation is the most misunderstood idea in multi-agent systems. Subagents do not automatically inherit the coordinator's conversation history. A new subagent starts with only what the coordinator explicitly includes in its prompt. It has no access to:

• The coordinator's system prompt (unless explicitly included)
• Previous messages in the coordinator's conversation
• Results from other subagents (unless the coordinator passes them)
• Any "shared memory" or global state

Subagents also do not share memory between invocations. Every piece of information a subagent needs goes in its prompt, explicitly.

Coordinator Responsibilities

1. Dynamic subagent selection. Analyse what a query requires and select only the subagents it needs.
2. Research scope partitioning. Partition the research scope to minimise duplication. Assign each agent distinct subtopics or source types.
3. Iterative refinement loops. Evaluate the synthesis output for gaps. If incomplete, re-delegate with targeted queries.
4. Centralised communication routing. All subagent communication routes through the coordinator.

The Narrow Decomposition Failure

Overly narrow task decomposition by the coordinator leads to incomplete coverage of broad research topics. Each subagent researches only what it is assigned. A subtopic nobody is assigned never gets researched.

When subagents execute their assigned tasks correctly but coverage is missing, the root cause is what the coordinator assigned them. The fault sits in the coordinator's decomposition, not any downstream agent.

In the exam

The exam tests one orchestration pattern: hub-and-spoke, with a coordinator at the centre. It tests all four coordinator responsibilities. Direct subagent-to-subagent communication is the wrong answer. The exam leans hard on the isolation confusion.

When a report misses entire categories, check the decomposition before blaming the subagents.

Exam Traps

• Blaming downstream subagents for coverage gaps when the coordinator's task decomposition was too narrow
• Assuming subagents share memory or inherit the coordinator's conversation history
• Proposing direct inter-subagent communication as an efficiency improvement
• Routing every query through the full subagent pipeline

Practice Scenario

A multi-agent research system produces a report on 'renewable energy technologies' that only covers solar and wind, missing geothermal, tidal, biomass, and nuclear fusion. Each subagent produced thorough coverage of its assigned topic. Where is the root cause?

Build Exercise: Build a Hub-and-Spoke Research Coordinator (60 minutes)

What you'll learn:

• How hub-and-spoke architecture centralises all communication through a coordinator
• Why subagent isolation means every piece of context must be explicitly passed
• How to implement broad task decomposition that avoids the narrow decomposition failure
• How iterative refinement loops detect and fill coverage gaps

Steps:

1. Create a coordinator agent that accepts a broad research topic as input.
2. Implement task decomposition logic that breaks the topic into at least 5 distinct subtopics covering the full breadth.
3. Spawn two subagents (web search and document analysis) with explicit context passing.
4. Aggregate results from both subagents and evaluate coverage completeness.
5. Implement an iterative refinement loop for coverage gaps.
6. Test with the topic "renewable energy technologies" and verify full coverage.

Sources

• Claude Agent SDK Overview — Anthropic
• Building with Claude API (Skilljar) — Anthropic
• CCAR-F Exam Guide v1.0: Task Statement 1.2 — Anthropic

CCAR-F Domain 1 · Task 1.3

What You Need to Know

A coordinator is the agent that runs a multi-agent task and hands parts of it to subagents. Invocation is how it starts a subagent. Context passing is how it gives that subagent the information it needs.

The Task Tool

The Task tool is how a coordinator spawns subagents. It is the API mechanism that makes multi-agent orchestration work in the Claude Agent SDK.

Current state (checked 6 October 2026): Claude Code renamed it Agent in v2.1.63. The name Task still works as an alias.

The coordinator's allowedTools must include "Task" (or "Agent"). This is a binary gate. Without it, the coordinator cannot invoke any subagent.

Each subagent is defined by an AgentDefinition, which specifies:

1. Description: what the subagent does. The coordinator reads it to decide when to invoke.
2. System prompt: the instructions the subagent follows.
3. Tool restrictions: which tools the subagent can access, scoped to its role.

Context Passing

Subagents have isolated context. A subagent receives only what the coordinator writes into its prompt. Three rules follow:

Rule 1: Include complete findings from prior agents. A synthesis subagent cannot look up earlier results. If it needs web search results and document analysis output, the coordinator must pass both in full.

Rule 2: Use structured data that separates content from metadata. Content is the claim. Metadata says where it came from (source URL, document name, page number). When a coordinator compresses findings and drops the link between claim and source, attribution is lost.

Rule 3: Specify goals, not procedures. A coordinator prompt should tell a subagent what to achieve and which quality criteria to meet, not give step-by-step instructions.

Structured Metadata Format

{
  "findings": [
    {
      "claim": "Solar panel efficiency has increased 25% in the last decade",
      "source_url": "https://example.com/solar-report",
      "document_name": "Annual Solar Industry Report 2024",
      "page_number": 14,
      "confidence": "high",
      "retrieved_by": "web_search_agent"
    }
  ]
}

When Attribution Fails

If both research subagents return well-sourced work but the coordinator passes the content without the metadata, the synthesis subagent writes a proposal with no source attribution. Changing the synthesis prompt does not fix this. The coordinator must pass structured metadata alongside the content.

Parallel vs Sequential Spawning

When a coordinator needs several subagents for independent tasks, it should emit multiple Task tool calls in a single response. Sequential spawning means one subagent per coordinator turn and adds unnecessary latency.

Key Concept: Spawn independent subagents in parallel by emitting multiple Task tool calls in a single coordinator response.

fork_session

fork_session creates independent branches from a shared analysis baseline. After an initial analysis, a coordinator can fork the session to explore divergent approaches. After the branching point, each fork works independently.

fork_session is not the same as --resume. Resume continues a specific named session. Fork creates a new independent branch.

In the exam

Exam guide v1.0 uses the name Task tool. Answer "Task tool" even where current code shows Agent. When a synthesis agent's report has unsourced claims while the research subagents work correctly, the root cause is that the coordinator passed content without structured metadata.

Exam Traps

• Assuming subagents automatically have access to the coordinator's conversation history or other subagents' outputs
• Blaming the synthesis agent's prompt when claims lose their source citations
• Proposing sequential subagent invocation for tasks that can run independently
• Writing a subagent's prompt as an exact step-by-step procedure

Practice Scenario

A synthesis agent produces a report where several claims have no source attribution. The synthesis agent's prompt and tool set are unchanged. The web search and document analysis subagents are working correctly and returning well-sourced results. What is the most likely root cause?

Build Exercise: Implement Context Passing with Structured Metadata (50 minutes)

What you'll learn:

• Why the coordinator allowedTools must include Task (or Agent)
• How to design structured metadata that separates content from source attribution
• Why context passing failures cause attribution errors in downstream agents
• How to spawn independent subagents in parallel
• The difference between fork_session and parallel Task tool invocation

Sources

• Claude Agent SDK Overview — Anthropic
• CCAR-F Exam Guide v1.0: Task Statement 1.3 — Anthropic

CCAR-F Domain 1 · Task 1.4

What You Need to Know

Some agent workflows have steps that must run in a set order. Prompt-based guidance sets that order with a system prompt instruction. Programmatic enforcement sets it in code: hooks, prerequisite gates or code-level checks that physically block downstream tools until their prerequisites complete.

Prompt Guidance Versus Programmatic Enforcement

A prompt instruction works most of the time (perhaps 90-95%). It still has a non-zero failure rate because the model is probabilistic. A gate works every time — it is code, so it is deterministic.

Decision rule: If a single failure would cause financial loss, a security breach or a compliance violation, use programmatic enforcement.

• Financial operations (refunds, transfers, payments) → programmatic
• Security operations (identity verification, access control) → programmatic
• Compliance operations (AML checks, regulatory requirements) → programmatic
• Low-stakes operations (formatting, style) → prompt guidance is acceptable

How a Prerequisite Gate Works

1. The gate checks whether a prior condition has been met for this session.
2. If yes, the tool executes normally.
3. If no, the tool returns an error telling the model to complete the prerequisite first.

The model cannot bypass the gate.

Subagent Lifecycle Hooks

• SubagentStart: fires when a subagent is spawned. Can add additionalContext. Cannot block.
• SubagentStop: fires when a subagent finishes. Can validate output (exit code 2 keeps the subagent running). Cannot rewrite the result.

Subagents can define their own hooks in frontmatter, scoped to their lifetime.

Multi-Concern Request Handling

1. Decompose the request into distinct items.
2. Investigate each in parallel using shared context.
3. Synthesise a unified resolution that addresses all items in a single response.

Structured Handoff Protocols

When escalating to a human, the handoff summary must be self-contained and include:

• Customer ID
• Conversation summary
• Root cause analysis
• Refund amount (if applicable)
• Recommended action

Exam Traps

• Enhanced system prompt / few-shot as the fix for high-stakes compliance failures
• Handling multi-concern requests sequentially across separate replies
• Incomplete handoff summaries

Practice Scenario

Production data shows that in 8% of cases an agent processes refunds without verifying account ownership. The system prompt already tells it to check first. What is the most appropriate fix?

Build Exercise: Build a Prerequisite Gate for Financial Operations (60 min)

CCAR-F Domain 1 · Task 1.5

What You Need to Know

An Agent SDK hook is code that intercepts a tool call or a tool result. Hooks are deterministic; the model is probabilistic. Hooks sit at the boundary between the model's decisions and the real world.

Two Types of Hooks

Hook	When it runs	What it can do
PreToolUse	Before tool executes	Block, modify arguments, redirect
PostToolUse	After tool executes, before model sees result	Transform / normalise the result

Key Concept: PostToolUse transforms data after execution. PreToolUse enforces policy before execution.

PostToolUse: Data Normalisation

Different tools return data in different formats (Unix timestamps vs ISO 8601 vs DD/MM/YYYY; numeric codes vs English strings). A PostToolUse hook converts every result to a consistent schema before the model processes it.

PreToolUse: Policy Enforcement

Examples:

• Block process_refund when amount > $500 → escalate to human
• Block transfer_funds until AML check has passed in this session
• Pause approve_discount for discounts > 20% for manager approval

Decision Framework

Requirement	Mechanism	Guarantee
Must be followed 100% of the time	Hooks	Deterministic
Preferred but occasional deviation OK	Prompts	Probabilistic

Exam Traps

• Using PostToolUse to block policy-violating actions (too late — action already happened)
• Enhanced prompts as the solution for 100% compliance requirements
• Leaving the model to normalise mixed data formats
• Using PreToolUse to clean up tool results (wrong direction)

Practice Scenario

An agent occasionally processes international transfers without required AML checks. Compliance requires 100% enforcement. What is the correct approach?

Build Exercise: Implement Hooks for Normalisation and Policy Enforcement (60 min)

CCAR-F Domain 1 · Task 1.6

What You Need to Know

Task decomposition breaks complex work into pieces an agentic system can handle.

Fixed Sequential Pipelines (Prompt Chaining)

Each step takes the previous step's output as input. The sequence does not change based on intermediate results.

Suits predictable, structured tasks: code reviews, document processing, data extraction, compliance checks.

Advantages: consistent results, easy debugging, easy monitoring.
Limitation: cannot adapt to unexpected findings.

Dynamic Adaptive Decomposition

The plan evolves as the agent learns. New information may change the remaining steps.

Suits open-ended investigation: legacy system exploration, security audits, research, debugging unfamiliar codebases.

Choosing a Pattern

Task Characteristics	Pattern
Steps known in advance, structured input	Fixed pipeline
Open-ended, unknown scope	Dynamic decomposition
Multi-file code review	Fixed pipeline
Legacy codebase exploration	Dynamic decomposition

The Attention Dilution Problem

Occurs when an agent processes too many items in a single pass. Symptoms:

• Detailed feedback on first few items, shallow analysis on later ones
• Same pattern flagged in one item, approved in another
• Obvious bugs missed in some items while minor issues caught in others

The Fix: Multi-Pass Architecture

1. Per-item local analysis passes — each file/document gets its own pass with full attention budget.
2. Cross-item integration pass — looks for data flow, inconsistent patterns, cross-file dependencies.

A better model or larger context window does not fix attention dilution; the structure does.

Exam Traps

• Suggesting a more powerful model / larger context / better prompt as the fix for attention dilution
• Choosing dynamic decomposition for a structured task with known steps
• Applying fixed pipelines to open-ended investigation
• Batching files without a cross-file integration pass

Practice Scenario

A code review agent processes 14 files and produces detailed feedback for the first 5 but misses obvious bugs in files 10-14. It also flags a pattern in one file while approving identical code in another. What is the root cause and solution?

Build Exercise: Build a Multi-Pass Code Review Pipeline (60 min)

CCAR-F Domain 1 · Task 1.7

What You Need to Know

A session is one conversation with an agent that you can come back to. Session management determines how an agent keeps continuity across work sessions.

Three Session Management Options

Option	Purpose	When to use
--resume	Continue the same session	Prior context is mostly still valid; files have not changed significantly
fork_session	Create independent branch from shared baseline	Exploring divergent approaches after initial analysis
Fresh start + summary injection	Clean baseline with preserved knowledge	Prior tool results are stale (files changed) or context is degraded

Key Concept: Resume for continuation, fork for divergent exploration, fresh start with summary for stale tool results.

The Stale Context Problem

Occurs when an agent resumes a session after files have been modified. The history still contains old tool results. The model reasons from stale data and gives contradictory advice.

Simply resuming and asking the agent to re-read changed files is incomplete — the stale results remain in history. The correct fix is a fresh session with a structured summary of prior findings, plus targeted re-analysis of only the changed files.

Decision Matrix

Scenario	Best Option
Continuing work, no files changed	--resume
Comparing two approaches	fork_session
Resuming after core files changed	Fresh start + summary
Long session with cluttered history	Fresh start + summary
Dependency updates	Fresh start + summary

Exam Traps

• Suggesting full re-exploration when only a few files changed
• Resuming when most earlier tool results describe files that have since changed
• Using fork_session to continue a single line of investigation
• Using fork_session to handle stale context

Practice Scenario

A developer resumes a session after modifying 3 files in a 50-file codebase. The 3 files are the core modules. The agent gives contradictory advice because of stale tool results. The other 47 files are untouched. What is the correct approach?

Build Exercise: Implement Session Management Strategies (45 min)