Table of Contents

Click any entry to jump straight to it. You can also use the sidebar on the left at any time, filter chapters with the search box, and move with the ← / → arrow keys.

How to Use This Book

This guide is a complete course, not a summary. Read it front to back once, then use the practice questions and quick-reference tables to drill weak spots.

The book is organized to mirror the exam itself. After this front matter and an exam-strategy chapter, there is one chapter per exam domain, weighted roughly to how heavily that domain is tested. A cross-cutting chapter collects the "anti-patterns" (the wrong answers the exam loves to dangle in front of you), because recognizing them is often the fastest route to the correct choice. The book closes with a readiness self-assessment, thirty worked scenario-style practice questions, a glossary, and a footnote of official external resources.

How the reader works

Use the table of contents on the left to jump anywhere. The arrow buttons at the bottom of each page move you forward and back, and your keyboard's ← / → arrow keys do the same. The progress bar at the top tracks how far through the book you are. Everything is on one page, so you can also use your browser's Find (Ctrl/Cmd-F) to search the entire book, and Print (Ctrl/Cmd-P) produces a clean, expanded PDF with all answer explanations revealed.

Legend for the callout boxes

The Exam at a Glance

What the Claude Certified Architect Foundations (CCAR-F) credential tests, how it is scored, and how to spend your 120 minutes.

What the credential means

The Claude Certified Architect Foundations (often abbreviated CCA‑F or CCAR‑F) validates that a practitioner can make sound architectural trade-off decisions when building real production systems on Claude. It is deliberately not a coding test. Anthropic frames the target candidate as a solution architect with roughly six months of hands-on experience across four technologies: the Claude API, Claude Code, the Claude Agent SDK, and the Model Context Protocol (MCP). If you can build with all four and reason about when to reach for each, you are the intended audience.

Format and logistics

The five domains and their weights

Every question maps to one of five domains. The weightings tell you where to invest study time: Agentic Architecture alone is more than a quarter of the exam.

The six scenario contexts

The scenarios are the recurring "worlds" the questions live in. You will see four of these six. Knowing them in advance means the framing never surprises you; only the specific trade-off does.

1. Customer Support Resolution Agent: an agent that resolves returns, billing, and account issues; heavy on ambiguity handling, escalation, and MCP tools into backend systems.
2. Code Generation with Claude Code: using Claude Code to generate, refactor, and document code; configuration and workflow decisions.
3. Multi-Agent Research System: a coordinator delegating to research subagents; orchestration, context isolation, and synthesis.
4. Developer Productivity Tools: internal tooling built on the API/SDK; structured output and reliability.
5. Claude Code in CI/CD: headless Claude Code in pipelines; non-interactive mode, permissions, structured output.
6. Structured Data Extraction: pulling schema-valid JSON from messy documents; validation and edge cases.

How to spend the 120 minutes

Two minutes per question is comfortable if you do not stall. A reliable rhythm: read the last sentence of the scenario first (it contains the actual question), then read the scenario body knowing what to look for. Eliminate the two obviously wrong distractors, then choose between the remaining two by asking which one an experienced architect would defend in a design review. Flag anything that takes more than 90 seconds and return to it; there is no penalty for guessing, so never leave a question blank.

Agentic Architecture & Orchestration

The single largest domain. It tests whether you can design the control flow of an agent (the loop that turns a language model into something that acts), and whether you can coordinate several agents without the system collapsing into chaos.

1.1 What "agentic" actually means

A plain language-model call is a single turn: you send messages, you get text back, you are done. An agent is what you get when you wrap that call in a loop and give the model tools it can invoke. The model is no longer just producing text; it is deciding, step by step, which action to take next, observing the result, and deciding again, until the task is complete. The intelligence that used to live in your hard-coded control flow now lives in the model's choices. Your job as an architect is to build the harness around that intelligence: the loop, the tools, the stopping conditions, and the guardrails.

Anthropic draws a useful distinction between two shapes of system. A workflow is one where the steps are predetermined and orchestrated by code you wrote: the LLM fills in blanks at fixed points. An agent is one where the model itself dynamically directs the steps and tool use, deciding the path at runtime. Both are valid; the exam wants you to know that you should reach for the simplest thing that works. Do not build a multi-agent swarm when a single well-prompted call, or a fixed workflow, would do the job more cheaply and predictably.

1.2 The agentic loop

The heartbeat of every Claude agent is the same four-beat cycle. Commit it to memory because the exam phrases many questions in its terms.

1. Send the conversation (system prompt, message history, and the list of available tools) to the model.
2. Inspect the response's stop_reason to learn why the model stopped.
3. Act: if the model asked to use a tool, execute that tool and append the result to the conversation as a tool_result.
4. Repeat: loop back to step 1 with the appended result, until the model returns end_turn, signalling it is finished.

# The canonical agentic loop (Messages API, Python)
messages = [{"role": "user", "content": user_request}]

while True:
    response = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=2048,
        tools=tools,
        messages=messages,
    )
    messages.append({"role": "assistant", "content": response.content})

    if response.stop_reason == "end_turn":
        break                          # Claude is done: return final text

    if response.stop_reason == "tool_use":
        tool_results = []
        for block in response.content:
            if block.type == "tool_use":
                result = run_tool(block.name, block.input)   # YOUR code executes the tool
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": result,
                })
        messages.append({"role": "user", "content": tool_results})
        continue                       # loop again with the tool output in context

1.3 Reading stop_reason: your control signal

The stop_reason field is how the model tells your loop what to do next. Treating it as an afterthought is a classic source of broken agents. Learn all of them.

Single Agent or Many?

The most consequential architectural decision in this domain. Choosing multi-agent when a single agent would do is the more common, and more heavily penalized, mistake.

1.4 When a single agent is right

A single agent with a good loop and a well-chosen tool set handles the large majority of real tasks. Keep to one agent when the task is essentially sequential, when all the work shares the same context, and when the total context comfortably fits the window. One agent is cheaper, easier to debug, has no coordination overhead, and never suffers from information getting lost in hand-offs. The exam's default expectation is a single agent unless the scenario gives you a concrete reason to split.

1.5 When multi-agent earns its keep

Multi-agent systems shine on tasks that decompose into independent, parallelizable subtasks, each of which needs its own large context. Anthropic's own multi-agent research system is the canonical example: a lead agent plans the research, then spawns several subagents that each investigate a different sub-question simultaneously, each burning through its own context window reading sources, before returning a compact summary to the lead for synthesis. The wins are real: parallel exploration is faster, and each subagent's heavy reading never pollutes the others' or the coordinator's context.

1.6 Orchestration topologies

Hub-and-spoke (coordinator / orchestrator-worker)

The recommended topology is a hub-and-spoke (also called orchestrator-worker or coordinator-subagent) design. One coordinator agent owns the task: it decomposes the work, spawns subagents, hands each a scoped instruction, collects their results, and synthesizes the final answer. Subagents talk only to the coordinator, never directly to each other. This gives you a single point of control, clear information provenance, and a predictable flow.

            ┌─────────────────┐
            │   Coordinator   │   plans, delegates, synthesizes
            └───┬────┬────┬────┘
                │    │    │        (spokes: scoped tasks in,
        ┌───────┘    │    └───────┐  summaries out)
        ▼            ▼            ▼
   ┌─────────┐  ┌─────────┐  ┌─────────┐
   │Subagent │  │Subagent │  │Subagent │   each: own context,
   │   A     │  │   B     │  │   C     │   own tools, returns a summary
   └─────────┘  └─────────┘  └─────────┘

Task decomposition

Good decomposition is what makes hub-and-spoke work. The coordinator should split a task into subtasks that are independent (one subagent's work does not depend on another's mid-flight), clearly scoped (each subagent gets an unambiguous objective and only the tools it needs), and appropriately sized (not so fine-grained that coordination overhead dominates). The coordinator's prompt is where you tell it how aggressively to fan out and how to recombine results.

Subagents, Context Forking & the Agent SDK

How delegation actually works in practice: the mechanics of spawning isolated subagents, and the lifecycle hooks that let you enforce rules deterministically.

1.7 Context forking

Context forking is the mechanism behind subagent isolation. When a coordinator delegates, the subagent runs in a forked context: a fresh window that does not carry the coordinator's full history, and whose own token consumption never flows back except as the summary the subagent chooses to return. This is the difference between "the subagent read 50 pages" and "the coordinator now has 50 pages jammed into its context." Forking is what lets you explore expensively without paying for it downstream.

1.8 Delegation in the Claude Agent SDK

The Claude Agent SDK (the same engine that powers Claude Code, exposed for you to build your own agents) provides first-class primitives for this. Delegation happens through a Task tool (sometimes called the "Agent" or subagent tool): the main agent invokes it with a description and an agent type, and the SDK runs that subagent in its own isolated context, returning only its final message. Subagent types can be defined with their own system prompts, their own restricted tool sets, and their own model choice, so a "researcher" subagent might have web tools and a big model, while a "formatter" subagent has no tools and a small one.

1.9 Lifecycle hooks: deterministic control

A hook is your own code that the runtime executes automatically at a defined point in the agent's lifecycle. Hooks are how you enforce things you must not leave to the model's discretion. The key lifecycle points:

• PreToolUse: runs before a tool executes. Can inspect the call and block it (e.g. deny a rm -rf, require approval for a production write). Deterministic guardrail.
• PostToolUse: runs after a tool returns. Good for logging, validation, formatting, or reacting to the result (e.g. auto-run tests after an edit).
• UserPromptSubmit, Stop, SubagentStop, SessionStart, PreCompact and others let you hook input handling, turn completion, subagent completion, and context compaction.

1.10 Session & state management

Agents that run over long or resumable interactions need somewhere to keep state: the evolving message history, intermediate results, and any facts that must survive across turns. The context window is the working memory, but it is finite, so for anything long-lived you externalize state (to a store, a file, a scratchpad) and re-inject only what is relevant. The SDK supports session persistence and resumption so an agent can pause and pick up later. The architectural point the exam probes: don't rely on the context window as durable storage; treat it as a working set and keep the source of truth elsewhere when the interaction outlives a single window. (Context-preservation strategy is developed fully in Domain 5.)

The Five Workflow Patterns & Guardrails

Before you reach for a fully autonomous agent, know the five composable workflow patterns from Anthropic's "Building Effective Agents." The exam expects you to name the right pattern for a scenario, and to prefer the simplest one that fits.

1.11 The pattern ladder

These build from simplest to most flexible. The rule of thumb: climb the ladder only as far as the task forces you.

1.12 Workflow vs. autonomous agent: the deciding question

A workflow orchestrates LLM calls through predefined code paths: you keep control of the flow. An autonomous agent lets the model direct its own actions in a loop, using tools and environmental feedback until a stopping condition. Agents buy flexibility at the price of predictability, higher cost, and compounding errors. Anthropic's explicit guidance: "find the simplest solution possible, and only increase complexity when needed." Often a single optimized call with retrieval and good examples is enough, no agent at all.

1.13 Guardrails

Because agents act with real tools and can compound mistakes, guardrails are part of the architecture, not an afterthought. The exam-relevant guardrail layers:

• Permissions & hooks (deterministic): allow/deny/ask rules and PreToolUse blocks for anything destructive or irreversible. The hard guarantees.
• Bounded loops: a maximum-iteration / --max-turns ceiling so a stuck agent can't spin or burn budget forever.
• Sandboxing & least privilege: run agents in isolated/ephemeral environments with only the tools and access the task needs.
• Human-in-the-loop checkpoints: approvals (plan mode, permission prompts) before high-impact actions.
• Validation & monitoring: check outputs programmatically (Domain 4) and log/trace actions for auditability.

1.14 Parallel tool use

Within a single turn, Claude can request multiple tool calls at once: several tool_use blocks in one response. Your loop should execute them (ideally concurrently) and return all the corresponding tool_result blocks together in the next user message, each keyed by its tool_use_id. Handling only the first tool call and dropping the rest is a subtle bug that stalls agents. This is the intra-turn cousin of the parallelization pattern above.

Tool Design & MCP Integration

Tools are how an agent touches the world. This domain tests whether you can design tools Claude uses correctly, return errors it can act on, and wire in external systems through the Model Context Protocol.

2.1 A tool is a prompt

From Claude's perspective, a tool is defined entirely by its name, its description, and its input schema. Claude cannot see the code behind the tool. So the description is not documentation for humans: it is instructions to the model about when and how to use this capability. A vague or ambiguous description is the number-one cause of tools being called at the wrong time, with the wrong arguments, or not at all.

{
  "name": "get_order_status",
  "description": "Look up the current fulfillment status of a customer order by its
    order ID. Use this when the customer asks where their order is or whether it
    has shipped. Do NOT use this to modify an order; use update_order for that.
    Returns status, carrier, and estimated delivery date.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "The order ID, formatted like 'ORD-12345'. Ask the
          customer for it if not provided; never guess."
      }
    },
    "required": ["order_id"]
  }
}

2.2 Structured, actionable error responses

When a tool fails, how you report the failure decides whether the agent recovers gracefully or spirals. Returning a bare stack trace or an opaque "Error 500" gives Claude nothing to reason about. Instead, return a structured error that tells the model what went wrong and whether it is worth trying again.

# A recoverable error the agent can act on
{
  "isError": true,
  "isRetryable": false,
  "errorCategory": "validation",
  "message": "No order found for 'ORD-9'. IDs look like 'ORD-12345' (5 digits).
    Ask the customer to re-check the number."
}

The Model Context Protocol

MCP is the open standard for connecting Claude to external tools and data. Anthropic calls it "a USB-C port for AI": one protocol so any client can talk to any server. The exam leans on MCP heavily.

2.3 Why MCP exists

Before MCP, every integration between an AI application and an external system (a database, GitHub, Slack, a filesystem) was bespoke: an M×N explosion of custom connectors. MCP replaces that with a single, open, client-server protocol. A host application (Claude Desktop, Claude Code, your own agent) runs one or more MCP clients, each of which connects to an MCP server that exposes some capability. Write a server once and any MCP-speaking client can use it; add a client once and it can use any MCP server.

2.4 The three primitives

An MCP server can expose three kinds of things. Know all three and who controls each.

2.5 Transports

MCP clients and servers communicate over a transport. Two matter for the exam:

• stdio: the server runs as a local subprocess and communicates over standard input/output. Ideal for local tools (filesystem, a local script) where client and server live on the same machine. Fast, simple, no network.
• Streamable HTTP (the modern remote transport, superseding the older HTTP+SSE): the server runs as a remote service reached over HTTP, supporting streaming. Ideal for hosted/shared servers and remote APIs, and where auth (e.g. OAuth) is needed.

Underneath, MCP uses JSON-RPC 2.0 as its message format regardless of transport. Choose stdio for local, single-user tools; choose Streamable HTTP for remote, multi-user, or networked services.

2.6 Configuring MCP servers

In Claude Code and SDK-based agents, MCP servers are declared in configuration, most commonly a .mcp.json file. Each entry names a server and says how to launch or reach it (command + args for stdio, or a URL for HTTP), plus any environment/credentials.

// .mcp.json: checked into the repo so the whole team shares these servers
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./src"]
    },
    "github": {
      "type": "http",
      "url": "https://api.githubmcp.example/mcp",
      "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" }
    }
  }
}

2.7 Distributing tools across agents

When you have many tools and (per Domain 1) multiple agents, who gets what is an architectural choice. The guiding principle: give each agent only the tools its role requires.

Advanced Tool & MCP Engineering

Beyond a good description, the details that separate a tool Claude uses flawlessly from one it fumbles, and the MCP capabilities the exam expects you to recognize.

2.8 Designing tools that are hard to misuse

Anthropic frames tool design as interface design: put as much effort into your tools as you would into a good human-computer interface. Several concrete techniques:

2.9 MCP capabilities you should recognize

Beyond the three primitives (tools, resources, prompts) and the two transports (stdio, Streamable HTTP), the exam may touch these MCP concepts:

• Authentication / OAuth: remote (HTTP) MCP servers commonly authenticate via OAuth 2.0 so a server can act on a user's behalf against a third-party API. Local stdio servers typically rely on local credentials/env vars.
• Roots: a client-provided set of filesystem/URI boundaries that tell a server where it's allowed to operate; a scoping/safety mechanism.
• Sampling: a server can ask the client's model to generate a completion on its behalf (the client stays in control of model choice and approval). Enables agentic behavior inside a server without the server holding its own model keys.
• Discovery: clients query a server at connect time to list its available tools/resources/prompts, so capabilities are advertised dynamically rather than hard-coded.

2.10 MCP configuration scopes

When you register MCP servers for Claude Code (e.g. via claude mcp add), you choose a scope: the same shared-vs-personal split that recurs across the exam:

Claude Code Configuration & Workflows

Claude Code is Anthropic's agentic coding tool in the terminal. This domain tests how you configure it (memory, rules, skills, permissions) and how you drive it in real developer and CI/CD workflows.

3.1 CLAUDE.md: the project's memory

CLAUDE.md is a special file Claude Code automatically loads into context at the start of a session. It is where you record the things Claude should always know about this project: architecture and conventions, how to build and test, coding standards, naming patterns, "do this / never do that" rules, and pointers to key files. Think of it as the durable, version-controlled briefing you'd give a new engineer, except Claude re-reads it every session.

The memory hierarchy

Claude Code reads memory from several locations and merges them, with more-specific scopes layering on top of broader ones. Know the levels and precedence.

Nested files let a monorepo give each package its own conventions; the closest file to the code being edited wins on conflicts, layered over the broader files. You can also pull in other files with @path/to/file imports to avoid duplication.

3.2 Rules & path-scoping

Beyond a single memory file, Claude Code supports a .claude/rules/ directory of rule files that use YAML frontmatter to declare when each rule applies, most importantly, scoping a rule to file paths via glob patterns. This lets you say "these constraints apply only to files under src/payments/" without loading them for unrelated work.

# .claude/rules/payments.md
---
globs: "src/payments/**/*.ts"
description: "Rules for the payments module"
---
- Never log full card numbers; mask all but the last four digits.
- All monetary amounts are integers in the smallest currency unit (cents).
- Every write to the ledger must go through `postTransaction()`.

Skills, Slash Commands & Plan Mode

The extensibility surface of Claude Code (reusable capabilities and workflows), plus the single most-tested workflow decision: plan first, or execute directly.

3.3 Custom slash commands

A slash command is a reusable prompt saved as a Markdown file, invoked by typing /name. Project commands live in .claude/commands/ (shared via the repo); personal ones in ~/.claude/commands/. They can take arguments (via $ARGUMENTS or positional $1, $2) and are perfect for codifying repeated workflows, such as "/review", "/write-tests", or "/changelog", so the whole team runs them the same way.

# .claude/commands/fix-issue.md  →  invoked as: /fix-issue 123
---
description: "Investigate and fix a GitHub issue"
allowed-tools: ["Bash(git*)", "Edit", "Read"]
---
Look at GitHub issue #$1. Reproduce it, find the root cause,
fix it, and add a regression test. Explain the fix before committing.

3.4 Skills

Agent Skills package expertise (instructions, and optionally scripts and resources) into a folder with a SKILL.md that Claude loads when relevant. Skills are model-invoked (Claude decides to use one based on its description) and progressively disclosed (only the metadata is always in context; the body loads on demand), which keeps them cheap. Two frontmatter options the exam calls out:

3.5 Permissions & hooks in Claude Code

Claude Code gates tool actions through a permission system: rules that allow, deny, or ask for each kind of action (e.g. allow Read, ask before Bash(git push), deny Bash(rm -rf*)). Settings live in .claude/settings.json (project, committed) or user settings. Combined with hooks (PreToolUse, PostToolUse, etc.), this is your deterministic safety layer.

3.6 Plan mode vs. direct execution

Plan mode puts Claude Code into a read-only research phase: it explores the codebase and proposes a plan without making any changes, and waits for your approval before executing. Direct execution lets it act immediately (read, edit, run) as it goes.

Claude Code in CI/CD

Running Claude Code non-interactively (in pipelines, scripts, and automation) where no human is there to approve prompts and outputs must be machine-parseable.

3.7 Headless / non-interactive mode

The -p (or --print) flag runs Claude Code in headless mode: it takes a prompt, does the work, prints the result, and exits, with no interactive session. This is the entry point for CI/CD, cron jobs, git hooks, and any scripted use.

# Headless run in a CI pipeline
claude -p "Review the diff on this PR for security issues and summarize findings" \
  --output-format json \
  --allowedTools "Read" "Bash(git diff*)" \
  --max-turns 15

3.8 Structured output for pipelines

Because a pipeline stage consumes Claude's output programmatically, you want it typed and predictable. --output-format json gives you a machine envelope; --json-schema forces the content into a shape you define (e.g. {"verdict": "pass|fail", "issues": [...]}). A CI gate can then branch on verdict without parsing prose. This is the Claude Code cousin of the API's structured-output techniques in Domain 4.

Claude Code Subagents, Settings & Integrations

How Claude Code delegates to specialized subagents, how its settings resolve, and how it plugs into the wider toolchain.

3.9 Custom subagents in Claude Code

Claude Code lets you define reusable custom subagents as Markdown files with YAML frontmatter. Each runs in its own context window, with its own system prompt, its own restricted tool access, and optionally its own (cheaper/faster) model. When Claude hits a task matching a subagent's description, it delegates automatically; the subagent works in isolation and returns only its result, keeping the main conversation clean.

# .claude/agents/code-reviewer.md
---
name: code-reviewer
description: "Reviews diffs for bugs and security issues. Use after writing code."
tools: [Read, Grep, Bash(git diff*)]     # least privilege
model: haiku                              # route to a cheaper model
---
You are a meticulous code reviewer. Check the diff for bugs, security
issues, and missing tests. Return a prioritized list of findings only.

3.10 Settings precedence

Claude Code merges settings from several layers, most-specific winning: the same hierarchy shape as memory. Know the order:

Settings files hold permission rules, hook definitions, environment variables, and model/tool defaults. Committed settings.json is how a team ships shared permissions and hooks; settings.local.json is your private override.

3.11 Integrations & the SDK relationship

Claude Code is built on the Claude Agent SDK: the same engine you can import to build your own agents in TypeScript or Python. Practical integration surfaces the exam may reference:

• Headless in CI/CD: the -p flag (Domain 3.7) drives pipelines, git hooks, and cron jobs.
• GitHub Actions / PR automation: Claude Code can run in CI to review PRs, triage issues, or implement changes on a branch, gated by an allowlist.
• IDE and terminal: interactive use with the same config (CLAUDE.md, rules, permissions) applying everywhere.
• Agent SDK: when you need a custom agent (not the coding assistant), build directly on the SDK; you get the loop, subagents, hooks, permissions, and MCP support described throughout this guide.

Prompt Engineering & Structured Output

Not "prompt tricks," but engineering: writing prompts precise enough for production, and getting output that downstream code can rely on. Plus the economics of batch processing.

4.1 The core techniques

Anthropic's prompt-engineering guidance is a toolbox applied roughly in this order of impact. You should recognize each by name and know why it works.

4.2 Structured output via tool_use

When you need JSON your code can parse, the reliable method is not "ask nicely for JSON." It's to define a tool with a JSON input schema and let Claude "call" it. Because the API constrains the tool call to your input_schema, you get output matching the schema's shape and types. This is far more reliable than parsing prose and hoping the braces line up.

# Force schema-valid extraction by defining a tool
tools = [{
  "name": "record_invoice",
  "description": "Save the fields extracted from an invoice.",
  "input_schema": {
    "type": "object",
    "properties": {
      "invoice_number": {"type": "string"},
      "total_cents":    {"type": "integer"},
      "due_date":       {"type": "string", "format": "date"},
      "currency":       {"type": "string", "enum": ["USD","EUR","GBP"]}
    },
    "required": ["invoice_number", "total_cents", "currency"]
  }
}]
# Force the call so Claude MUST return this structure:
tool_choice = {"type": "tool", "name": "record_invoice"}

Validation Loops, Multi-Pass Review & Batch

Turning "usually right" into "reliably right," and knowing when to trade latency for half-price throughput.

4.3 Validation-retry loops

For production reliability you close the loop: take Claude's output, validate it programmatically, and if it fails, feed the specific error back and ask for a corrected version. Validation can be schema checks, business rules (does the invoice total equal the line items?), a checksum, a compile/test run, or a database lookup. The retry includes what was wrong so the model can fix it rather than guess again.

result = extract(document)
for attempt in range(MAX_RETRIES):
    errors = validate(result)          # YOUR deterministic checks
    if not errors:
        break
    result = extract(document, feedback=errors)   # retry WITH the specific errors
else:
    escalate_to_human(result, errors)  # bounded: give up cleanly after N tries

4.4 Multi-pass review

Some quality goals are better met by separating generation from evaluation: one pass produces the work, a second pass (a fresh call, often with a critic prompt) reviews it against explicit criteria, and optionally a third revises. Because the reviewer starts clean and is told exactly what to check, it catches issues the generator was blind to. This "generator → critic → reviser" pattern is more reliable than asking a single pass to be perfect, and maps onto multi-agent review architectures from Domain 1.

4.5 Confidence & escalation

4.6 The Message Batches API

For large volumes of independent, non-urgent requests (nightly document processing, bulk classification, dataset generation, evaluations), the Message Batches API processes them asynchronously at roughly 50% lower cost, with results returned within a 24-hour window (often much sooner). You submit a batch, poll for completion, then retrieve results. It's the economical choice whenever you can tolerate latency.

Extended Thinking & Empirical Prompting

Giving Claude room to reason on hard problems, placing long inputs well, and treating prompt quality as something you measure, not guess.

4.7 Extended thinking

Extended thinking lets Claude produce internal reasoning (thinking content blocks) before its final answer, materially improving accuracy on complex math, analysis, and coding. You enable it and set a budget_tokens target for how much internal reasoning it may use. Reach for it when a task genuinely needs multi-step reasoning; skip it for simple, latency-sensitive calls where it just adds cost and delay.

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "enabled", "budget_tokens": 10000},
    messages=[{"role": "user", "content": hard_problem},
)

4.8 Temperature and determinism

temperature controls randomness. For extraction, classification, and anything you'll validate against a schema or expect to be reproducible, use a low temperature (near 0) for consistency. For brainstorming, creative drafting, or voting-style diversity, a higher temperature helps. Match the setting to whether you want the same answer every time or varied answers.

4.9 Placing long context well

When a prompt includes large inputs (documents, transcripts), where you put them matters because of attention effects (Domain 5). Best practices from Anthropic's long-context guidance:

• Put large documents near the top of the prompt, above the instructions and the question; this tends to improve quality noticeably on long inputs.
• Wrap each input in XML tags (<document>…</document>) with metadata (title, source) so Claude can reference and cite them precisely.
• Put the specific instruction/question last, after the data, so it's fresh at generation time.
• Ask Claude to ground answers in quotes pulled from the documents first, then answer, improving faithfulness on long context.

4.10 Empirical prompting: define success, then measure

The professional discipline the exam rewards: don't eyeball prompt quality. Define success criteria and evaluate against them. Build a small eval set of representative inputs with expected outputs (or graded rubrics), run prompt variants against it, and pick the winner on evidence. This is what turns "seems good" into "measurably meets the bar," and it's the same criteria-first mindset behind explicit instructions and validation loops.

Context Management & Reliability

The context window is finite and attention within it is imperfect. This domain is about preserving what matters across long interactions, controlling cost, and making multi-component systems fail safely.

5.1 The context window is a budget, not a warehouse

Everything the model reasons over (system prompt, memory files, tool definitions, history, tool results) competes for one finite window. Two failure modes follow. First, you can simply run out of room on long tasks. Second, and subtler, is attention dilution (sometimes "context rot" or "lost in the middle"): as a window fills, the model attends less reliably to any given token, and information buried in the middle of a huge context is more likely to be overlooked. More context is not more understanding.

5.2 Strategies for preserving critical information

5.3 Large-codebase exploration: per-file passes

A recurring scenario: an agent must understand or modify a codebase far too large to fit in context. The wrong instinct is to jam as much of the repo as possible into one window. The right approach is multi-pass, per-file (or per-module) processing: examine one unit at a time in a focused context, extract a compact finding, and accumulate those findings. Each pass gets the model's full attention on a manageable slice, and the running summary, not the raw files, is what persists.

Prompt Caching, Deterministic Routing & Failure Handling

Cutting cost and latency on repeated context, routing without trusting the model's self-assessment, and keeping failures from silently corrupting a multi-agent system.

5.4 Prompt caching

Prompt caching lets you mark a stable prefix of your prompt (a long system prompt, a big document, a fixed tool set, few-shot examples) so it is cached and reused across calls instead of re-processed every time. Cache reads are much cheaper (roughly a 90% discount on the cached portion) and faster; writing to the cache carries a small premium. It shines in high-volume workflows and multi-turn conversations that repeatedly send the same large context.

5.5 Deterministic routing & escalation

Reliable systems decide when to escalate, retry, or hand off using deterministic logic, not the model's vibe. Route on verifiable signals: a validation failure, a value crossing an explicit threshold, a category returned by a classifier step, a business rule, or disagreement between independent passes. Define the thresholds in code so the behavior is predictable, testable, and auditable.

5.6 Error propagation in multi-agent systems

In a coordinator/subagent system, a subagent failure that isn't surfaced is dangerous: the coordinator synthesizes a final answer on top of a missing or wrong piece, and no one notices. This is silent failure propagation. Reliable designs make every subagent failure visible to the coordinator through the structured error contract from Domain 2 (isError, category, retryability), so the coordinator can retry, route around, flag the gap, or escalate, rather than treating an empty result as success.

Prompt-Cache Mechanics & Agent Memory

The precise mechanics behind caching that questions like to probe, plus how modern agents keep memory across very long or unbounded tasks.

5.7 How prompt caching actually works

You already know why to cache (reuse a stable prefix; ~90% cheaper reads; see §5.4). Here are the mechanics worth knowing precisely:

5.8 Memory beyond the window: context editing & the memory tool

For agents that run for a very long time or across many turns, the context window alone isn't enough. Two complementary mechanisms handle this:

• Context editing / compaction: the runtime automatically trims or summarizes stale content (e.g. old tool results) as the window fills, keeping the working set relevant. In Claude Code this is automatic; the PreCompact hook lets you influence what's preserved.
• The memory tool / external memory: the agent writes durable facts, decisions, and progress to storage outside the context (files, a memory store) and reads them back when needed. This lets knowledge persist across sessions and beyond any single window: the source of truth lives outside the prompt.

5.9 Reliability extras: citations & verification

Two more reliability levers the exam may nod to. Citations: having the model ground claims in, and cite, specific source passages (natively supported for documents) reduces hallucination and makes outputs auditable. Independent verification: cross-checking an answer with a separate pass or a deterministic check (the evaluator-optimizer/voting ideas) catches errors self-review misses. Both push reliability toward evidence and away from trusting a single unverified generation.

The Seven Anti-Patterns

The exam is built around trade-offs, and its distractors recycle a small set of tempting-but-wrong ideas. Learn to spot these seven and you can eliminate a wrong answer on sight.

Rapid-Review Cheat Sheet

The night-before, one-screen distillation. If you can explain every line here, you're ready.

Agentic loop & stop_reason

Loop = send → check stop_reason → run tool → append tool_result → repeat until end_turn. tool_use → you execute; max_tokens → truncated, continue; pause_turn → send back to continue; refusal → 200, not an error, rephrase/fallback; stop_sequence → check which fired. Always cap iterations.

Single vs. multi-agent

Default single. Go multi only for independent, parallel subtasks each needing its own large context. Real reason = context isolation via forking. Topology = hub-and-spoke, never flat. Subagents return summaries, not transcripts. Multi-agent = more tokens/latency/failure surface.

Tools & MCP

A tool = name + description + schema (Claude can't see the code). Great descriptions steer selection. Structured errors: isError, isRetryable, errorCategory, message. MCP primitives: tools (do, model-driven), resources (data, app-driven), prompts (templates, user-driven). Transports: stdio (local) vs Streamable HTTP (remote); JSON-RPC underneath. Config in .mcp.json (project=shared, user=personal). Scope tools per agent role.

Claude Code

CLAUDE.md hierarchy: enterprise → project (committed) → project-local (git-ignored) → user; nested subdir files; closest wins. .claude/rules/ + YAML frontmatter globs: for path-scoping. Slash commands (.claude/commands/) & skills; context: fork = isolate, allowed-tools = restrict. Plan mode for big/risky/unfamiliar; direct execution for small/reversible. CI/CD: -p headless + --output-format json/--json-schema + allowlist + --max-turns. Hard rules = permissions + hooks (PreToolUse blocks).

Prompt engineering & structured output

Explicit criteria > vague; examples (few-shot); think step-by-step; XML tags; roles; prefill; chain. Structured output = define a tool with JSON schema + force tool_choice. Schema-valid ≠ correct → validation-retry loop (bounded, feed errors back, escalate). Multi-pass generator→critic→reviser with checklists. Batch API = ~50% off, ≤24h, offline only.

Context & reliability

Window = budget; beware attention dilution: bigger ≠ better. Compact/summarize, externalize state, retrieve on demand, per-file passes for big codebases. Prompt caching = reuse stable prefix (~90% off reads) for real-time repeats. Deterministic routing/escalation on verifiable signals, never self-reported confidence. Surface subagent errors instead of letting them propagate silently.

Readiness Self-Assessment

If you can answer every prompt below out loud without notes, you have the coverage to pass. Any you stumble on points you back to the exact section to revisit.

Domain 1: Agentic Architecture (27%)

• Recite the four beats of the agentic loop and name all seven stop_reason values and how you'd handle each. (§1.2-1.3)
• Give two concrete reasons to choose multi-agent, and the one main reason it's really about context. (§1.5-1.6)
• Explain why flat topology is an anti-pattern and what hub-and-spoke fixes. (§1.6)
• Match a scenario to the right pattern: chaining, routing, parallelization (sectioning/voting), orchestrator-workers, evaluator-optimizer. (§1.11)
• Say when you'd enforce a rule with a hook vs. a prompt, and name the lifecycle hooks. (§1.9, §1.13)

Domain 2: Tool Design & MCP (18%)

• Explain why a tool description is "a prompt," and list the fields of a structured error. (§2.1-2.2)
• Define MCP's three primitives and who controls each; contrast stdio vs. Streamable HTTP. (§2.4-2.5)
• State the project-vs-user/local scope rule for .mcp.json. (§2.6, §2.10)
• Describe poka-yoke tool design and why "all tools to all agents" fails. (§2.7-2.8)

Domain 3: Claude Code (20%)

• Order the CLAUDE.md hierarchy and say what's committed vs. personal. (§3.1)
• Explain path-scoped rules, context: fork, and allowed-tools. (§3.2, §3.4)
• Decide plan mode vs. direct execution for a given task. (§3.6)
• Write the safe CI/CD recipe (flags + guardrails). (§3.7-3.8)
• Say when to define a custom subagent and what its frontmatter controls. (§3.9)

Domain 4: Prompt Engineering & Structured Output (20%)

• Name the core techniques and why explicit criteria beat vague instructions. (§4.1)
• Show how to force schema-valid output and why schema-valid ≠ correct. (§4.2)
• Describe a bounded validation-retry loop and multi-pass review. (§4.3-4.4)
• Decide Batch API vs. synchronous, and when to use extended thinking. (§4.6-4.7)

Domain 5: Context Management & Reliability (15%)

• Explain attention dilution and why bigger windows don't fix it. (§5.1)
• Give the per-file-passes strategy for large codebases. (§5.3)
• State caching TTLs, breakpoint count, and prefix order. (§5.7)
• Contrast caching vs. batching; window vs. external memory. (§5.4, §5.8)
• Explain deterministic routing and why self-reported confidence fails. (§5.5)

Practice Questions: Domains 1 & 2

Click an option to check it, or hit Reveal answer. Explanations follow the exam's reasoning, not just the label. (Printing reveals all explanations.)

Practice Questions: Domains 3, 4 & 5

Continue drilling. Watch for the anti-pattern hidden in each distractor set.

Practice Questions: Advanced & Mixed

These cover the deeper material (workflow patterns, cache mechanics, subagents, extended thinking) and mix domains the way the real exam does.

Glossary

Every term the exam expects you to know cold, in one place.

Core & agentic

Agent: a model wrapped in a loop with tools, dynamically deciding its own steps.
Workflow: a system whose steps are predetermined in code; the model fills fixed gaps. Prefer over an agent when the path is known.
Agentic loop: send → check stop_reason → run tool → append tool_result → repeat until end_turn.
stop_reason: why the model stopped: end_turn, tool_use, max_tokens, stop_sequence, pause_turn, refusal, model_context_window_exceeded. All arrive on HTTP 200.
tool_use block: the model's structured request to call a client tool; your code executes it.
tool_result: the message you append with a tool's output (or structured error) to continue the loop.
Coordinator / orchestrator: the hub agent that decomposes tasks, delegates to subagents, and synthesizes results.
Subagent: a delegated agent running in an isolated context; returns a summary to the coordinator.
Hub-and-spoke: orchestrator-worker topology; the recommended multi-agent shape.
Flat topology: every agent messaging every agent; an anti-pattern.
Context forking: running a subagent/skill in a fresh, isolated context window so its work doesn't consume the parent's context.
Task tool: the SDK primitive for delegating to a subagent.
Information provenance: knowing which source/agent produced each claim; preserved by hub-and-spoke.

Tools & MCP

Tool: name + description + input schema the model can invoke; Claude can't see its code.
Structured error: a failure response with isError, isRetryable, errorCategory, and a message, so the agent can recover.
MCP (Model Context Protocol): open client-server standard for connecting Claude to external tools/data ("USB-C for AI").
MCP host / client / server: host app runs clients; each client connects to a server exposing capabilities.
MCP primitives: tools (executable, model-driven), resources (read-only data, app-driven), prompts (templates, user-driven).
stdio transport: local subprocess over stdin/stdout.
Streamable HTTP transport: remote server over HTTP with streaming (supersedes HTTP+SSE).
JSON-RPC 2.0: MCP's underlying message format.
.mcp.json: config declaring MCP servers; project-scoped (committed, shared) vs. user-scoped (personal).

Claude Code

CLAUDE.md: auto-loaded project memory; hierarchy: enterprise → project (committed) → project-local (git-ignored) → user, plus nested subdir files (closest wins).
.claude/rules/: rule files with YAML frontmatter (globs:) for path-scoped constraints.
Slash command: reusable prompt in .claude/commands/, invoked as /name, supports arguments.
Skill: packaged expertise (SKILL.md + optional scripts), model-invoked, progressively disclosed.
context: fork: skill frontmatter that runs it in an isolated context.
allowed-tools: frontmatter restricting a skill/command to specific tools (least privilege).
Plan mode: read-only research + proposed plan awaiting approval before edits.
Hooks: deterministic code at lifecycle points: PreToolUse (can block), PostToolUse, UserPromptSubmit, Stop, SubagentStop, PreCompact, SessionStart.
Permissions: allow/ask/deny rules gating tool actions (.claude/settings.json).
-p / --print: headless, non-interactive run for CI/CD.
--output-format json / --json-schema: machine-parseable / schema-constrained output.
--max-turns: caps loop iterations (circuit breaker).

Prompting, output & reliability

Few-shot prompting: 2-5 input→output examples to demonstrate the pattern.
Chain-of-thought: asking for step-by-step reasoning before the answer.
System prompt / role: standing persona, rules, and priorities for the conversation.
Prefill: starting the assistant turn to force format/skip preamble.
tool_choice: forcing a specific tool call to guarantee schema-valid output.
Validation-retry loop: validate output in code; on failure, feed the error back and retry (bounded), then escalate.
Multi-pass review: separate generator, critic, and reviser passes with explicit checklists.
Message Batches API: async bulk processing, ~50% cheaper, ≤24h; latency-tolerant only.
Prompt caching: reuse a stable prompt prefix (~90% cheaper reads) for repeated real-time context.
Attention dilution / context rot: degraded attention as the window fills; not fixed by bigger windows.
Compaction: summarizing older context to reclaim room (shape via PreCompact).
Deterministic routing/escalation: routing on verifiable signals (validation, thresholds, cross-checks), never self-reported confidence.
Silent failure propagation: a swallowed subagent error corrupting the final output; prevented by explicit structured errors.

External Resources & Footnotes

This book is designed to be sufficient on its own. The resources below are for deeper practice and for confirming current exam logistics; treat them as optional reinforcement, not required reading.

Official: start here

• Certification & exam guide: the official landing page and downloadable exam guide PDF (the authoritative source for current blueprint, price, and logistics): anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification
• Prep courses (free): Anthropic Academy's recommended path: Foundations Prep Courses. Key courses: AI Fluency: Framework & Foundations, Building with the Claude API, Claude Code in Action, Introduction to Model Context Protocol, Claude 101, plus the Amazon Bedrock and Google Vertex AI tracks.
• Anthropic Academy: the full self-paced course catalog: anthropic.skilljar.com
• Anthropic Cookbook & courses (GitHub): runnable notebooks and course code: github.com/anthropics/courses and anthropic-cookbook

Official documentation: by domain

• Agentic loop & stop reasons: Handling stop reasons; How tool use works.
• Building effective agents: Anthropic's foundational engineering essay on workflows vs. agents and orchestration patterns: anthropic.com/engineering/building-effective-agents; and the multi-agent research system write-up: multi-agent-research-system.
• Claude Agent SDK: subagents, hooks, permissions, the agent loop: Agent SDK docs.
• Tool design: Tool use overview and best practices for tool descriptions.
• MCP: the spec and concepts: modelcontextprotocol.io; Anthropic's Claude Code MCP guide.
• Claude Code: memory/CLAUDE.md, settings, hooks, slash commands, skills, headless mode: code.claude.com/docs.
• Prompt engineering: the overview and technique pages: Prompt engineering overview.
• Structured output & tool_use for JSON, Message Batches API, and Prompt caching: see the respective "Build with Claude" doc pages on the Claude platform.

Community study aids (verify against official sources)

• Community study-materials repository with multi-language guides and practice HTML: github.com/paullarionov/claude-certified-architect.
• Independent walkthroughs and question banks exist (Medium guides, dev.to breakdowns, third-party prep sites). Useful for extra reps, but always defer to the official exam guide where they disagree.