Agentic Architecture

27%

Agentic Architecture is the largest CCA-F domain at 27%. It tests how you design Claude as an autonomous agent — agent loops, orchestrator/subagent patterns, tool selection, error recovery, and human-in-the-loop checkpoints.

Agentic Architecture is the single largest domain on the Claude Certified Architect Foundations exam — 27% of the blueprint, meaning roughly 16 of the 60 official-simulation questions come from this area. It is also the domain where Foundations candidates lose the most points, because the questions are almost never about syntax. They are about decisions: when does an agent keep looping, when does it stop, where do you put guardrails, which work belongs in the orchestrator vs. the subagents, and what do you do when a tool call fails halfway through a workflow.

If you only have time to deeply prepare for one domain, prepare for this one. The exam tests your ability to recognise architectural anti-patterns — infinite retries, missing termination signals, subagents that drift, orchestrators that try to do too much — and pick the production-grade alternative under pressure.

What the exam tests in this domain

  • ·When an agent loop should continue vs. terminate (the stop_reason contract)
  • ·Orchestrator vs. subagent responsibilities in hub-and-spoke designs
  • ·Where to insert human-in-the-loop checkpoints without bottlenecking the workflow
  • ·Error recovery: retries, fallback handlers, partial-result preservation
  • ·Memory: in-context vs. external vs. procedural, and when to use each
  • ·Tool selection strategy: parallel vs. sequential, and how to avoid drift

Key concepts

The agent loop and the stop_reason contract

Every agentic system Claude participates in runs the same fundamental loop: send a request, inspect the response, and decide whether to feed Claude tool results and loop again or terminate. The decision is driven by stop_reason, not by message content. If stop_reason is 'tool_use', Claude is asking for a tool to be invoked and the loop must continue. If stop_reason is 'end_turn', Claude has finished reasoning and the loop must terminate. Two common anti-patterns appear in exam distractors: hard-capping iterations at a fixed number (which truncates legitimate long-running work) and checking for the presence of text content (which terminates as soon as Claude narrates intent, before tool use). Both produce questions that look 'reasonable but wrong' — exactly what distractors are written for.

Orchestrator vs. subagent in hub-and-spoke

The orchestrator is the director, not the worker. Its job is to partition scope, dispatch subagents, collect results, and decide what to do next. Subagents execute focused subtasks and return summarised results — they do not communicate with each other, they do not inherit the orchestrator's full conversation history, and they do not make global scheduling decisions. Two distractor patterns to watch for: 'subagents share partial results directly' (violates hub-and-spoke and breaks observability) and 'subagents receive the full coordinator history' (leaks context, wastes tokens, and erodes the principle that each subagent has one clear job).

Tool selection: parallel, sequential, and idempotency

Parallel tool calls are appropriate when sub-tasks are independent (e.g. fetching 5 unrelated documents). Sequential is appropriate when later calls depend on earlier results (e.g. lookup → fetch → write). Two safety patterns matter for the exam: every tool should be idempotent or explicitly marked side-effecting, and every parallel batch should preserve enough metadata in the results for the orchestrator to attribute failures correctly. A common trap: 'retry the whole batch on any failure' — the right answer is almost always to retry the individual failed call, not the batch.

Human-in-the-loop checkpoints

Foundations does not expect candidates to design custom approval UIs, but it does test whether you know where to insert human approval. The rule of thumb: insert a human checkpoint before any action that is irreversible or expensive (refunds, deletions, external messages, large purchases) and before any decision the policy says must be human-owned. Do not insert one inside a tight tool-use loop — that turns minutes of work into hours and is one of the most common exam-day anti-patterns. Approval requests should bundle context: what the agent wants to do, why, and what it found.

Memory: in-context, external, procedural

In-context memory is the message history. It is rich but token-expensive and forgotten between sessions. External memory (a database, a vector store, a CLAUDE.md file) persists between turns and sessions but must be explicitly read in. Procedural memory is the rules in your system prompt — useful for stable policy but inappropriate for case-specific facts. The exam frequently asks 'where should this fact live?' and the correct answer is almost never 'just append it to the conversation' for anything that needs to survive past the current session.

Common traps and distractor patterns

Trap 1 — 'Retry forever' as resilience

An answer that says 'retry the failed step indefinitely until it succeeds' looks robust but is wrong. The correct pattern is: bounded retries on transient failures, fallback handlers for known-recoverable failures, and structured failure routed back to the orchestrator (or human) for anything else.

Trap 2 — 'Terminate the whole workflow on any failure'

The orchestrator's job is to keep the workflow alive. Terminating on first failure throws away all partial work and forces the user to restart. The correct pattern preserves successful subagent outputs, routes the failed subtask to a fallback or human, and continues.

Trap 3 — 'Subagents talk to each other'

Direct subagent-to-subagent communication breaks hub-and-spoke, makes observability impossible, and produces cascading failures. All inter-agent communication should route through the orchestrator. If a distractor says 'allow direct messaging between subagents to share results', it is the wrong answer.

Trap 4 — 'Check the assistant message text to decide whether to loop'

Some answers describe terminating the loop when the assistant response contains text content, or continuing when it doesn't. The agent loop is driven by stop_reason, not by the content of the message. Text-based termination is fragile (Claude often narrates while still requesting tools) and is one of the most common distractor patterns in this domain.

Sample questions with explanations

  1. Question 1

    In an agentic loop using the Claude Agent SDK, when should the loop continue processing?

    • A.When stop_reason is 'end_turn'
    • B.After a fixed number of 10 iterations
    • C.When stop_reason is 'tool_use'✓ Correct
    • D.When the assistant response contains text content
    Why C is correct: The agentic loop should continue when stop_reason is 'tool_use', meaning Claude is requesting a tool to be called. The loop terminates when stop_reason is 'end_turn', indicating Claude has finished its reasoning. Checking for text content or using fixed iteration caps are anti-patterns that can cause premature termination or infinite loops.

  2. Question 2

    In a hub-and-spoke multi-agent architecture, a coordinator agent is about to delegate a broad research topic to subagents. Which approach best prevents duplication and ensures complete coverage?

    • A.Always route through all subagents in sequence regardless of query complexity
    • B.Allow subagents to communicate directly with each other to share partial results
    • C.Provide each subagent with the full coordinator conversation history for context
    • D.Assign distinct subtopics or source types to each subagent and route through the coordinator for all inter-agent communication✓ Correct
    Why D is correct: The coordinator should partition scope across subagents (assigning distinct subtopics or source types) to minimize duplication, and route all communication through itself for observability and consistent error handling. Subagents should not communicate directly (violates hub-and-spoke), should not always use all subagents (wastes resources on simple queries), and do not inherit the coordinator's conversation history automatically.

  3. Question 3

    What is the primary role of an orchestrator in a multi-agent Claude system?

    • A.Execute tool calls directly without delegating
    • B.Store conversation history for all subagents
    • C.Direct other agents to use tools or undertake tasks toward a broader goal✓ Correct
    • D.Validate the JSON schema of every tool output
    Why C is correct: An orchestrator directs agents and tools to accomplish broader goals. It delegates work to subagents rather than executing everything itself, coordinates results, and manages the overall workflow. The other options describe specific implementation details, not the orchestrator's primary role.

How to study this domain

Read every question in this domain twice. The first read identifies what's being designed (a loop, a delegation, a recovery pattern). The second read identifies which option is 'correct in isolation' vs. 'correct in this scenario'. Most wrong answers on Agentic Architecture are correct-sounding statements that fail the scenario — e.g. 'add more retries' is fine in some contexts, fatal in others. Practice articulating, in one sentence, the failure mode each option would cause. If you cannot name the failure mode of an option, you do not yet understand the question well enough to answer.

Focus your study on: the stop_reason contract, hub-and-spoke responsibilities, when to insert a human checkpoint, and the difference between bounded and unbounded retries. Do at least 30–40 practice questions in this domain before sitting the simulation.

Frequently asked questions

How many questions on the CCA-F exam are from Agentic Architecture?
Agentic Architecture is 27% of the blueprint — the largest single domain. On the 60-question Official Simulation that maps to roughly 16 questions.
What's the most common mistake on Agentic Architecture questions?
Treating the agent loop as content-driven rather than stop_reason-driven. Many candidates pick distractors that terminate or continue based on the text of the assistant message instead of the structured stop_reason field — a fragile pattern that breaks under real tool use.
Do I need to memorise the Claude Agent SDK to pass this domain?
No. The exam tests architectural decisions, not SDK syntax. You should know the contract (stop_reason values, what each one means, when to loop, when to terminate) but you will not be asked to write code.
How should I handle 'retry vs. fail' questions?
Look for bounded retries on transient failures, fallback handlers for recoverable failures, and structured failure routed back to the orchestrator or a human for anything else. 'Retry forever' and 'terminate the workflow on first failure' are almost always wrong.
When is a human-in-the-loop checkpoint appropriate?
Before any irreversible or expensive action (refunds, deletions, outbound messages, large purchases) and before any decision policy explicitly assigns to a human. Avoid inserting checkpoints inside a tight tool-use loop — it bottlenecks the workflow.

Practice Agentic Architecture questions

$24.99 lifetime access. 1,000+ scenario-based questions across all 5 domains, adaptive difficulty, written explanations, 7-day refund.

Get Lifetime Access — $24.99

Or try 15 free questions first, or see 10 free sample questions.

Other CCA-F domains