This domain is about 27% of the exam, roughly 16 of its 60 questions.

Every point below comes from Anthropic's official documentation; each section lists its sources.

Think first How should an agentic loop decide whether to run another tool or stop and answer?

Why it matters: Questions show agent loop code or behavior and ask what decides the next iteration, or why the loop stops at the wrong time.

An agentic loop lets Claude choose its next tool from what it has learned so far. Your code runs the tools, feeds the results back, and reads stop_reason to decide whether to go around again.

Check stop_reason, run the tool, send its result back. Each pass adds the tool results to the conversation history. Claude then reasons about its next action with the new information in view.

Continue on tool_use; stop on end_turn. On tool_use, run the requested tool and return its result. On end_turn, Claude finished naturally, so present the response.

What each stop_reason tells the loop to do

Never end the loop by reading Claude's wording. Parsing natural language for a finished signal is an anti-pattern. So is treating assistant text as proof of completion. An arbitrary iteration cap should not be the main way the loop stops.

Exam trap A response that contains text is not a sign the task is complete. Base the loop on stop_reason: continue on "tool_use" and stop on "end_turn".

Answer every tool_use block in one user message. That message holds only tool_result blocks, and the request keeps the same tools array. Match each result to its call with tool_use_id.

Exam trap Do not add a text block right after tool results. It teaches Claude to expect user input after every tool use, so it ends its turn.

Claude chooses each next tool from the current context. A preset decision tree fixes the tool order in advance. An agentic loop lets each result shape the next step. Where an order is critical business logic, enforce it in code instead.

Every turn and tool result stays in the context window. Tool definitions and piled-up results use up space. A long agent with many tools or turns can run out of context before it finishes.

With thinking on, return thinking blocks complete and unchanged. A tool-use loop counts as one assistant turn, so change the thinking setting only between turns. Interleaved thinking lets Claude reason about each tool result before its next action.

• Keep looping while stop_reason is tool_use; stop when it is end_turn.
• Append each tool result to the conversation so Claude can reason about the next step.
• Do not stop on text content, parsed phrases or an iteration cap as the main signal.
• In an agentic loop, Claude picks the next tool; a decision tree fixes it in advance.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Stop reasons and fallback - Claude Platform Docs · Handle tool calls - Claude Platform Docs · Context windows - Claude Platform Docs · Manage tool context - Claude Platform Docs · Thinking in tool and multi-turn workflows - Claude Platform Docs

Think first What does the coordinator own in a hub-and-spoke multi-agent system, and what must it give each subagent?

Why it matters: Questions describe a research system with a coordinator and subagents, and ask how it should delegate, route and refine work.

One coordinator sits at the hub: it splits the task, picks subagents, routes every message and combines the results. Subagents start with isolated context, so everything they need must arrive in their prompt.

All subagent communication flows through the coordinator. Subagents report back to the conversation that spawned them rather than messaging each other. Routing everything through the coordinator gives you observability, consistent error handling and controlled information flow.

Exam trap Letting workers message each other directly is the agent team model, not hub-and-spoke. It gives up the coordinator's control of information flow.

A subagent does not inherit the coordinator's history. Unless it is a fork, a subagent receives only its own system prompt and the prompt string it is given. Put the file paths, errors, decisions and prior findings it needs into that prompt. Only its final message comes back to the coordinator.

Exam trap A synthesis subagent does not inherit earlier search results from its parent. Pass the complete findings of prior agents directly in its prompt.

Select subagents by what the query needs. A coordinator should analyze each query and invoke only the subagents it requires, not always the full pipeline. Its prompts should state research goals and quality criteria rather than step-by-step procedures, so subagents can adapt.

Give each subagent a distinct slice of the work. Assign distinct subtopics or source types to each subagent to minimize duplication. Independent subagents can then run in parallel, launched as several Task calls in one response.

Exam trap A very narrow split is not automatically thorough. Overly narrow decomposition leaves parts of a broad research topic uncovered.

Check synthesis for gaps, then re-delegate. The coordinator reviews the synthesis output for gaps. It sends targeted queries back to the search and analysis subagents, then re-invokes synthesis, until coverage is sufficient. Synthesis can also annotate which findings are well supported and where sources were missing.

Subagents send structured errors up to the coordinator. A subagent should recover from transient failures locally and escalate only what it cannot fix, with partial results and what it tried. A generic status like "search unavailable" hides that context. After a timeout, the coordinator can continue with partial results and note the gaps.

• The coordinator decomposes the task, delegates, aggregates results and decides which subagents to invoke.
• Route all subagent communication through the coordinator for observability and consistent error handling.
• Partition scope by subtopic or source type, but not so narrowly that coverage suffers.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Subagents in the SDK - Claude Code Docs · Run agents in parallel - Claude Code Docs

Think first What does a subagent know when it starts, and how do you make sure it gets what it needs?

Why it matters: Questions show a coordinator whose subagents fail, run slowly or lose context, and ask which setting or prompt change fixes it.

A subagent starts with a fresh context and knows only what its prompt tells it. The coordinator must be allowed to spawn it, must pass it every finding it needs, and should launch independent subagents together.

The coordinator's allowedTools must include "Task". Without it, the coordinator cannot invoke any subagent. In the stream, the same tool shows as Agent in tool_use blocks and as Task in the system:init tools list.

A subagent does not inherit the parent's conversation. Unless it is a fork, its context window starts without the parent conversation. Subagents also share no memory between invocations. The prompt string is the only thing the parent passes in.

Exam trap Do not assume a subagent already knows what the coordinator learned. Put the findings, file paths and decisions it needs directly in its prompt.

Give the synthesis subagent the full results of earlier agents. Include web search results and document analysis outputs in its prompt. Structure each finding so content stays separate from metadata, keeping attribution intact.

Fields of a structured finding passed between agents

Emit several Task calls in one coordinator response. Independent subagents then run at the same time. The work finishes in the time of the slowest subagent, not the sum of all of them.

Exam trap Spawning one subagent per turn makes the work sequential. For parallel runs, put all the Task calls in a single response.

description and prompt are required in AgentDefinition. The description tells Claude when to use the agent, so keep it clear and specific. The prompt is its system prompt. Restrict tools to the agent's role; if you omit the field, it inherits every available tool.

Tell subagents the research goal and the quality bar. Step-by-step procedures leave a subagent no room to adapt to what it finds. Goals and quality criteria let it choose its own path.

fork_session branches from a shared analysis baseline. Each branch explores a different direction from the same starting point. For example, compare two testing strategies or two refactoring approaches after one codebase analysis.

• A coordinator needs "Task" in allowedTools to spawn subagents.
• Subagents inherit no parent context, so pass every needed finding in the prompt.
• Emit multiple Task calls in one response to run subagents in parallel.
• Use fork_session to explore divergent approaches from one shared baseline.

Sources: Subagents in the SDK - Claude Code Docs · Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Parallel tool use - Claude Platform Docs

Think first When is a prompt instruction enough to keep an agent's steps in order, and when must code enforce the order?

Why it matters: Questions describe an agent that skips or misorders a step, or hands off badly, and ask for the most reliable fix.

Code gives a deterministic guarantee; prompts stay probabilistic. A firmer system prompt or extra few-shot examples still rely on the model choosing to comply. When an error has financial consequences, that is not enough.

Ways to keep a required tool order

Exam trap Limiting which tools a request can see does not fix a skipped step. It changes tool availability, while the problem is tool ordering.

Block refund tools until get_customer returns a verified ID. In one support scenario, the agent skipped verification in 12% of cases and looked up orders by name alone. That occasionally led to misidentified accounts and incorrect refunds. A programmatic prerequisite gives a deterministic guarantee that prompt-based fixes cannot.

A hook can stop a tool call that breaks a rule. For example, it can block an operation above a set amount and route it to an escalation workflow. A PostToolUse hook works on the other side, reshaping tool results before the model reads them.

For dependent calls, a sequential run that stops at the first failure is valid. Execution order is your choice. Independent read-only calls are usually safe to run in parallel. If you stop early, return is_error: true for any call you did not run. If you run in parallel and a call fails because its prerequisite was not done yet, return the error and Claude reissues it next turn.

Break the request into separate items, then work on each. The agent handles each concern, and then it synthesizes the results into one unified response.

Escalate when asked, at a policy gap, or when progress stalls. A customer asking for a human is a clear trigger. So is a policy exception or gap, not merely a complex case. An agent that cannot make meaningful progress should also hand off.

Exam trap Complexity alone is not an escalation trigger. Policy exceptions or gaps are, along with a request for a human and a lack of progress.

The human agent cannot see the conversation transcript. So the handoff must stand on its own. Include the customer ID, the root cause, the refund amount and the recommended action.

Exam trap Do not assume the human can read the chat. Human agents receiving the escalation lack access to the conversation transcript, so compile a structured summary for them.

• Use code, not prompts, when a step order must hold every time, such as verifying identity before refunds.
• Stronger prompts and few-shot examples still depend on probabilistic compliance by the model.
• A routing classifier controls which tools are available, not the order they run in.
• An escalation summary carries customer ID, root cause, refund amount and recommended action.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Parallel tool use - Claude Platform Docs

Think first When should a business rule live in an Agent SDK hook instead of in the system prompt?

Why it matters: Questions describe an agent that breaks a rule or gets messy tool data, and ask which hook pattern fixes it.

Hooks are your code, run when the SDK fires an event such as a tool call about to start or a result coming back. Code gives deterministic guarantees, while prompt instructions only make compliance likely.

Hooks give deterministic guarantees; prompts do not. Stronger system prompt wording and few-shot examples still depend on the model choosing to comply. When a mistake costs money, such as a refund before identity checks, that non-zero failure rate is too high. Hooks and prerequisite gates enforce the rule in code instead.

Exam trap Few-shot examples that always call the verification tool first do not guarantee the order. They still rely on probabilistic compliance, so pick a hook.

A PreToolUse hook can stop a call and redirect it. The hook checks the call against the rule, such as a refund above a threshold amount. If the call breaks it, set permissionDecision to deny and route the case to a human escalation workflow. permissionDecisionReason tells the model why, and systemMessage tells the user. Hooks can also demand human approval for sensitive actions like database writes.

A PostToolUse hook can fix data before the model reads it. Different MCP tools may return Unix timestamps, ISO 8601 dates or numeric status codes. A PostToolUse hook can convert them all into one format first, so the agent reasons over consistent data.

PostToolUse output fields compared

Exam trap additionalContext does not change the tool's output; it only appends to it. To replace messy data, set updatedToolOutput.

Matchers match tool names, never arguments. A regex such as ^mcp__ fires the hook for every MCP tool, because their names start with mcp__. To act only on certain file paths or values, read tool_input inside the hook and decide there.

Exam trap A matcher cannot filter on a file path or an amount. The hook must inspect tool_input itself.

The most restrictive decision wins. Matching hooks run in parallel. Deny beats defer, defer beats ask, and ask beats allow, so one deny blocks the call. If a PreToolUse callback times out, Claude Code discards its output and blocks the call too.

Exam trap A PreToolUse hook that times out does not let the call through. Claude Code cancels the hook and blocks the tool call.

Async hook output cannot block or change anything. By the time an async hook returns, the agent has already moved on. Use async hooks only for logging, metrics or notifications, never for a compliance check.

Exam trap An async hook cannot enforce a refund limit, because its output cannot block the operation.

• Use a hook, not prompt wording, when a business rule must hold every time.
• PreToolUse hooks intercept outgoing calls; PostToolUse hooks transform results before the model sees them.
• Set permissionDecision to deny to stop a call, and give the model a reason.
• One deny from any matching hook blocks the tool call.

Sources: Intercept and control agent behavior with hooks - Claude Code Docs · Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Modifying system prompts - Claude Code Docs

Think first When should a workflow follow a fixed chain of steps, and when should its plan grow from what each step finds?

Why it matters: Questions describe a review or investigation task and ask which decomposition pattern fits it best.

Predictable work splits into a fixed chain of steps you set in advance. Open-ended work needs a plan that adds subtasks as each step reveals something new. Picking between the two is the core skill here.

Chain prompts for predictable reviews; decompose dynamically for investigations. A predictable review with known aspects can run as a chain of sequential API calls. An adaptive investigation plan instead generates subtasks from what each step discovers.

Prompt chaining and dynamic decomposition compared

Exam trap Dynamic decomposition is not always the better choice. For a predictable multi-aspect review, a fixed prompt chain is the expected answer.

Chaining helps when you must inspect or control each stage. With adaptive thinking and subagent orchestration, Claude handles most multistep reasoning internally. Explicit chaining still earns its place when you need to log, evaluate or branch between calls. The common shape is self-correction: draft, review against criteria, then refine.

Review each file alone, then run a separate cross-file pass. Per-file passes catch local issues. The integration pass follows data flow between files. One workflow shape runs a reviewer per file, then hands every finding to one agent that ranks and deduplicates them.

Exam trap Putting every file into one big review pass does not make it more thorough. It dilutes attention and can produce contradictory findings.

Adaptive plans create subtasks from what each step uncovers. This suits investigation, where you cannot list the work in advance. A coordinator should also pick only the subagents a query needs, rather than always running the full pipeline.

Exam trap A coordinator that splits a broad research topic too narrowly does not gain focus. It leaves parts of the topic uncovered.

Map the structure, find high-impact areas, then plan by priority. Take adding comprehensive tests to a legacy codebase. Survey the code first, starting with broad questions and then narrowing. The Claude Code testing recipe likewise finds untested code before it generates test scaffolding. Let the plan change as you discover dependencies.

Plan mode proposes a plan and edits nothing until you approve. Claude writes that plan to a file. A long session compacts its context, but Claude Code puts the plan file back each time, so the plan is not lost. You can then switch to direct execution for the implementation.

Use subagents for parallel, isolated or independent workstreams. Keep sequential steps that share context in the main thread. The Explore subagent can absorb verbose discovery, so the main context window does not run out during a multi-phase task.

Exam trap Subagents are not the default for every step. For sequential work that must keep context across steps, work directly instead of delegating.

A workflow script fits when a task outgrows one agent's context. It also fits when the same step must run across many items. The script itself keeps the loop, branches and partial results, so Claude's context holds only the final answer. One shape searches in rounds and stops when a round finds nothing new.

• Prompt chaining fits predictable multi-aspect reviews; dynamic decomposition fits open-ended investigations.
• Split a large review into per-file passes plus a separate cross-file integration pass.
• For open-ended work, map the structure and high-impact areas before building a plan that adapts.
• Explicit chaining still pays off when you must inspect intermediate outputs or enforce a pipeline.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Prompting best practices - Claude Platform Docs · Orchestrate subagents at scale with dynamic workflows - Claude Code Docs · Common workflows - Claude Code Docs · Set up Claude Code in a monorepo or large codebase - Claude Code Docs

Think first When should you resume a past session, fork it, or start fresh with a summary?

Why it matters: Questions describe returning to earlier analysis and ask whether to resume, fork or start a new session.

Resuming keeps prior analysis, which helps only while it is still valid. Forking copies the history into an independent branch for a different approach. When old tool results are stale, a fresh session with a structured summary is more reliable.

Name a session, then resume it by that name. Name it at startup with claude -n or later with /rename. Resuming by name reopens it under the same session ID and appends to the conversation, so you can continue a named investigation across work sessions.

Example: Starts a named session, then later resumes that same session by its name.

claude -n my_session
claude --resume my_session

Exam trap An unnamed session's default display name is not a resume handle. Name the session if you plan to resume it.

Name the files you modified since the last analysis. Resuming lets the agent reuse its analysis without rereading files. If code changed in the meantime, tell it which previously analyzed files changed. That allows targeted re-analysis instead of a full re-exploration.

Exam trap A branch switch changes the files, not the history. Claude sees the new branch's files, but the conversation history stays the same. When you resume after code changes, tell the agent which analyzed files changed.

Resume when prior context is mostly valid; start fresh when it is stale. Stale tool results mislead a resumed session, so a fresh start from a structured summary is the safer choice. Pass the analysis output, decisions and file diffs you need into the fresh session's prompt.

Resuming and starting fresh compared

Fork to branch from a shared analysis baseline. A fork starts with a copy of the history and gets its own session ID, while the original stays unchanged. Use forks to compare two testing strategies or refactoring approaches from one codebase analysis. You can also fork with /branch.

Example: Resumes a named session as a new, independent fork with its own session ID.

claude --resume my_session --fork-session

Exam trap Forking does not isolate files. Edits by a forked agent are real and visible to every session in the same directory.

Fork before you work in parallel. Resuming the same session in two terminals without forking interleaves both into one transcript. Forks give you two independent sessions that resume separately. Remember that a session keeps the conversation, not the filesystem.

• Resume a named session with claude --resume when the earlier context is still mostly valid.
• Tell a resumed session which files changed so it re-analyzes only those.
• Start fresh with a structured summary when prior tool results are stale.
• Fork to compare approaches from one baseline; each fork has its own session ID.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Work with sessions - Claude Code Docs · Manage sessions - Claude Code Docs · How Claude Code works - Claude Code Docs