Domain 1: Agentic Architecture & Orchestration (27%)

Weight: 27% of scored content — this is the largest domain on the exam.

This domain covers how to design, implement, and manage autonomous agent systems using the Claude Agent SDK. You need to understand agentic loops, multi-agent coordination, subagent configuration, workflow enforcement, SDK hooks, task decomposition, and session management.

Task Statement 1.1: Design and implement agentic loops for autonomous task execution

The Agentic Loop Lifecycle

An agentic loop is the core runtime pattern for any Claude-based agent. The cycle is:

1. Send a request to Claude with a system prompt, conversation history, and available tools
2. Inspect stop_reason on the response:
3. "tool_use" → Claude wants to call a tool. Execute it and loop back to step 1 with the result appended
4. "end_turn" → Claude considers the task complete. Present the final response
5. Append tool results to the conversation history so Claude can reason about what happened
6. Repeat until stop_reason is "end_turn"

# Simplified agentic loop
import anthropic

client = anthropic.Anthropic()
messages = [{"role": "user", "content": user_request}]

while True:
    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=4096,
        system=system_prompt,
        tools=tools,
        messages=messages
    )

    # Append assistant response to history
    messages.append({"role": "assistant", "content": response.content})

    if response.stop_reason == "end_turn":
        break  # Task complete

    if response.stop_reason == "tool_use":
        tool_results = []
        for block in response.content:
            if block.type == "tool_use":
                result = execute_tool(block.name, block.input)
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": result
                })
        messages.append({"role": "user", "content": tool_results})

Key Principle: Model-Driven Decision-Making

Claude decides which tool to call next based on context — this is model-driven decision-making. The alternative (pre-configured decision trees or fixed tool sequences) is a pre-configured pipeline, which removes the model's ability to adapt.

The exam tests whether you understand that the agentic loop trusts the model to decide what to do next, rather than hardcoding tool sequences.

Anti-Patterns to Avoid

• Parsing natural language to determine loop termination (e.g., checking if Claude said "I'm done") — use stop_reason instead
• Arbitrary iteration caps as the primary stopping mechanism — the loop should terminate on "end_turn", not after N iterations
• Checking assistant text content as a completion indicator — stop_reason is the authoritative signal

Connection to Other Domains

• Tool results accumulate in context → see Context Management & Reliability
• Tool descriptions affect which tools Claude selects → see Tool Design & MCP Integration

Task Statement 1.2: Orchestrate multi-agent systems with coordinator-subagent patterns

Hub-and-Spoke Architecture

In a multi-agent system, a coordinator agent manages everything: it decomposes tasks, delegates to specialized subagents, aggregates results, and handles errors. All communication flows through the coordinator — subagents never talk to each other directly.

         ┌──────────────┐
         │  Coordinator  │
         └──────┬───────┘
        ┌───────┼────────┐
        ▼       ▼        ▼
   ┌─────────┐ ┌──────┐ ┌──────────┐
   │ Search  │ │Analyze│ │Synthesize│
   │ Agent   │ │ Agent │ │  Agent   │
   └─────────┘ └──────┘ └──────────┘

Subagent Isolation

Subagents operate with isolated context — they do not automatically inherit the coordinator's conversation history. Whatever a subagent needs to know must be explicitly provided in its prompt. This is by design: it keeps each agent focused and prevents context pollution.

The Coordinator's Responsibilities

1. Task decomposition — break the user's request into subtasks
2. Delegation — decide which subagents to invoke and what to tell them
3. Result aggregation — combine outputs from multiple subagents
4. Error handling — decide how to proceed when a subagent fails
5. Quality evaluation — check if results are complete before responding

The Narrow Decomposition Problem

A critical risk is the coordinator decomposing tasks too narrowly. For example, given "research the impact of AI on creative industries," a poorly designed coordinator might create subtasks only for visual arts, missing music, writing, and film entirely. The subagents execute their assigned tasks perfectly — the problem is what they were assigned.

Exam tip: If a question describes subagents working correctly but the final output has gaps, look at the coordinator's decomposition first.

Iterative Refinement Loops

A strong coordinator doesn't just fire-and-forget. It evaluates the synthesized output for gaps, then re-delegates to search and analysis subagents with targeted queries until coverage is sufficient. This is an iterative refinement loop.

Why Route Everything Through the Coordinator

• Observability — you can log all inter-agent communication in one place
• Consistent error handling — one place to implement retry/fallback logic
• Controlled information flow — the coordinator decides what each subagent sees

Connection to Other Domains

• Error propagation patterns → see Context Management & Reliability
• Task decomposition strategies → see Task Statement 1.6

Task Statement 1.3: Configure subagent invocation, context passing, and spawning

The Task Tool

Subagents are spawned using the Task tool in the Claude Agent SDK. For a coordinator to spawn subagents, its allowedTools configuration must include "Task".

AgentDefinition Configuration

Each subagent type is defined via an AgentDefinition that specifies: - Description — what this agent does (helps the coordinator decide when to use it) - System prompt — the agent's instructions and persona - Tool restrictions — which tools this agent can access (allowedTools)

Context Passing: Explicit, Not Inherited

Subagents do not automatically inherit the coordinator's context or share memory between invocations. Everything a subagent needs must be included directly in its prompt. This means:

• If a search agent found results and you want the synthesis agent to use them, you must pass those results in the synthesis agent's prompt
• Use structured data formats (JSON, markdown with headers) to separate content from metadata (source URLs, page numbers, dates)

# Good: explicit context passing
synthesis_prompt = f"""
Synthesize these research findings into a report:

## Web Search Results
{json.dumps(search_results, indent=2)}

## Document Analysis
{json.dumps(doc_analysis, indent=2)}

Preserve source attribution for all claims.
"""

Parallel Subagent Execution

You can spawn multiple subagents in parallel by emitting multiple Task tool calls in a single coordinator response. This is significantly faster than sequential execution.

# Coordinator emits in ONE response:
Task(agent="web_search", prompt="Research topic A...")
Task(agent="doc_analysis", prompt="Analyze documents about A...")
# Both run concurrently

Fork-Based Session Management

fork_session creates independent branches from a shared analysis baseline. This is useful for exploring divergent approaches — for example, comparing two testing strategies or refactoring approaches from the same codebase analysis.

Design Coordinator Prompts for Adaptability

Coordinator prompts should specify research goals and quality criteria rather than step-by-step procedural instructions. This lets subagents adapt their approach based on what they discover.

# Bad: rigid procedural instructions
"Step 1: Search for X. Step 2: Search for Y. Step 3: Combine."

# Good: goal-oriented with quality criteria
"Research [topic]. Ensure coverage across [dimensions].
Each finding must include source URL and publication date.
Flag any conflicting data with source attribution."

Connection to Other Domains

• Tool distribution across agents → see Tool Design & MCP Integration
• Session management → see Task Statement 1.7

Task Statement 1.4: Implement multi-step workflows with enforcement and handoff patterns

Programmatic Enforcement vs. Prompt-Based Guidance

This is one of the most important distinctions on the exam:

When to use programmatic enforcement: Any time deterministic compliance is required — especially for financial operations, identity verification, or safety-critical sequences. If the business consequence of skipping a step is significant, don't rely on the prompt alone.

Prerequisite Gates

A prerequisite gate blocks a downstream tool call until a required upstream step has completed:

# Block process_refund until get_customer has returned a verified ID
def execute_tool(name, input):
    if name in ["lookup_order", "process_refund"]:
        if not session.get("verified_customer_id"):
            return {
                "error": "Customer identity must be verified first",
                "isRetryable": False,
                "required_step": "Call get_customer first"
            }
    # ... proceed with tool execution

Structured Handoff Protocols

When escalating to a human agent mid-process, the handoff must include structured context because the human won't have the conversation transcript:

{
  "customer_id": "C-12345",
  "issue_summary": "Requesting refund for damaged item",
  "root_cause": "Item arrived with visible damage, photo evidence provided",
  "steps_completed": ["identity_verified", "order_located", "damage_confirmed"],
  "refund_amount": 89.99,
  "recommended_action": "Process full refund — meets standard damage policy",
  "escalation_reason": "Refund exceeds agent authorization threshold ($50)"
}

Multi-Concern Decomposition

When a customer raises multiple issues in one message, the agent should decompose them into distinct items, investigate each (potentially in parallel using shared context), and then synthesize a unified resolution.

Connection to Other Domains

• Escalation patterns → see Context Management & Reliability
• Hook implementation → see Task Statement 1.5

Task Statement 1.5: Apply Agent SDK hooks for tool call interception and data normalization

What Are Hooks?

Hooks are programmatic interceptors in the Agent SDK that run before or after tool calls. They let you transform data, enforce rules, and redirect workflows without relying on prompt instructions.

PostToolUse Hooks — Data Normalization

A PostToolUse hook intercepts tool results before the model processes them. Use cases:

• Normalize heterogeneous data formats — convert Unix timestamps to ISO 8601, standardize numeric status codes to human-readable strings, unify date formats across different MCP tools
• Trim verbose responses — strip irrelevant fields from API responses before they consume context tokens

# PostToolUse hook: normalize timestamps from different MCP tools
def post_tool_use(tool_name, tool_result):
    if "timestamp" in tool_result:
        # Convert Unix timestamp to ISO 8601
        if isinstance(tool_result["timestamp"], (int, float)):
            tool_result["timestamp"] = datetime.fromtimestamp(
                tool_result["timestamp"]
            ).isoformat()
    return tool_result

Tool Call Interception Hooks — Policy Enforcement

These hooks intercept outgoing tool calls to enforce compliance rules before execution:

# Intercept refund requests above $500
def pre_tool_use(tool_name, tool_input):
    if tool_name == "process_refund":
        if tool_input.get("amount", 0) > 500:
            # Block and redirect to escalation
            return {
                "blocked": True,
                "reason": "Refund exceeds $500 threshold",
                "redirect": "escalate_to_human",
                "context": {
                    "customer_id": tool_input["customer_id"],
                    "requested_amount": tool_input["amount"]
                }
            }
    return None  # Allow the call to proceed

Hooks vs. Prompt Instructions

Exam tip: When a question asks about enforcing a business rule that must always be followed, hooks are the answer. When it's about behavioral guidance that's acceptable to occasionally miss, prompt instructions may suffice.

Connection to Other Domains

• Structured error responses from tools → see Tool Design & MCP Integration
• Programmatic enforcement patterns → see Task Statement 1.4

Task Statement 1.6: Design task decomposition strategies for complex workflows

Fixed Pipelines vs. Dynamic Decomposition

Prompt Chaining Pattern

Break a review into sequential steps, each with focused attention:

Step 1: Analyze each file individually for local issues
Step 2: Run a cross-file integration pass for data flow analysis
Step 3: Synthesize findings into a unified report

This avoids attention dilution — when a model processes too many files at once, it gives detailed feedback to some and superficial comments to others.

Dynamic Decomposition Pattern

For open-ended tasks, start by mapping the structure, identify high-impact areas, then create a prioritized plan that adapts as dependencies are discovered:

Phase 1: Map the codebase structure (imports, dependencies, entry points)
Phase 2: Identify high-impact areas (most called functions, critical paths)
Phase 3: Create prioritized plan based on findings
Phase 4: Execute plan, adapting as new dependencies emerge

Splitting Large Code Reviews

For a pull request modifying many files, split into: 1. Per-file local analysis passes — each file gets focused attention 2. A separate cross-file integration pass — examines data flow, API contracts, and consistency across files

This prevents the "detailed for some, superficial for others" problem of single-pass reviews.

Connection to Other Domains

• Multi-pass review architectures → see Prompt Engineering & Structured Output
• Plan mode vs. direct execution → see Claude Code Configuration & Workflows

Task Statement 1.7: Manage session state, resumption, and forking

Named Session Resumption

Use --resume <session-name> to continue a specific prior conversation. This preserves the full context from the previous session.

# Start a named session
claude --session "refactor-auth-module"

# Resume it later
claude --resume "refactor-auth-module"

fork_session

fork_session creates independent branches from a shared analysis baseline. Use cases: - Comparing two testing strategies from the same codebase analysis - Exploring two refactoring approaches without contaminating either exploration - A/B testing different prompt strategies

When to Resume vs. Start Fresh

Key Insight: Stale Context

Starting a new session with a structured summary is often more reliable than resuming a session where prior tool results are stale. When you resume, the model may reason based on outdated information from earlier tool calls.

If you do resume after file changes, tell the agent what changed so it can do targeted re-analysis rather than re-exploring everything.

Connection to Other Domains

• Context degradation in long sessions → see Context Management & Reliability
• /compact for reducing token usage → see Context Management & Reliability