I decided to create a comprehensive preparation guide for the Claude Certified Architect Foundation exam. First, creating this guide helps me focus on the details and prepare more thoroughly for the exam. Second, I would like to share what I have learned along the way and hopefully help others who are preparing for the exam.
The exam covers five main domains.
I think the most important thing is not simply to prepare for the exam and try to memorize things. What matters much more is understanding how these concepts actually work and why they work that way.
One of the most valuable domains is Domain 1: Agentic Architecture & Orchestration, which accounts for 27% of the exam. That means this is an area where it is worth investing significantly more time and effort.
Even if you are not planning to earn the certificate and are simply interested in agentic development, I think you can still benefit from these concepts and the knowledge behind them.
My topic summaries and explanations also include example code in Python and PHP.
Let's go through the topics of Domain 1 one by one.
1.1 Agentic Loop
The agentic loop is the foundation of an agent-based application. Instead of calling the model once and returning its response, the application repeatedly evaluates the model’s output, executes requested tools, and feeds the results back into the model.
One important detail is knowing when the loop should terminate. The application shouldn’t try to guess whether the model is “finished” by parsing its natural-language response. Instead, the API’s structured stop_reason tells us whether the model wants to use a tool or has finished its turn.
You should understand:
- Why is stop_reason == "tool_use" / "end_turn" the correct termination condition?
- Why are parsing the response text for natural-language signals or using a fixed iteration limit both considered anti-patterns?
Deep dive: Agentic Loop
1.2 Coordinator–Subagent
The coordinator-subagent pattern allows a main agent to delegate specialized tasks to dedicated subagents instead of trying to handle everything itself. The coordinator should dynamically route tasks to the relevant subagents based on what the request actually requires. Running every subagent for every request wastes resources and can add unnecessary context.
The task decomposition also needs to be broad enough to capture all relevant aspects of the request. If it is too narrow, important parts of the task may be missed.
You should understand:
- Why does the coordinator dynamically route tasks to the relevant subagents instead of always running the entire pipeline?
- What can go wrong when the coordinator's task decomposition is too narrow?
Deep dive: Coordinator–Subagent
1.3 Subagent Invocation
When a coordinator delegates work to a subagent, the invocation needs to be explicitly configured. The coordinator must have the Task tool in its own allowedTools, otherwise it cannot invoke subagents. Another important concept is that context is not automatically inherited by the subagent. The coordinator must explicitly provide the information the subagent needs, such as the task description, relevant files, or previous results. This keeps subagents isolated and makes the handoff between agents explicit and predictable.
You should understand:
- Why must the Task tool be included in the coordinator's own allowedTools?
- Why doesn't context automatically carry over to a subagent, and what does that mean in practice for the information you need to pass explicitly?
Deep dive: Configure Subagent Invocation
1.4 Enforcement & Handoff
Important workflow rules should be enforced programmatically when a deterministic guarantee is required. A prompt instruction can guide the model, but it cannot guarantee that a prerequisite will always be followed. When a task needs to be escalated to a human, the handoff should contain a structured summary with the relevant context, what has already been done, the results, and why human intervention is needed. This allows the human to continue the process without having to reconstruct the entire conversation.
You should understand:
- What is the difference between a programmatic prerequisite gate and a prompt instruction in terms of providing a deterministic guarantee?
- What information belongs in a structured handoff summary when escalating a case to a human?
Deep dive: Multi-Step Workflows
1.5 Agent SDK Hooks
Hooks allow you to intercept or process tool calls without putting the same logic into every individual tool. A PreToolUse hook runs before a tool is executed, making it useful for validation, authorization, or blocking an operation. A PostToolUse hook runs after the tool completes and can be used to normalize, validate, or process the result. Hooks are especially useful when the same rule needs to apply across multiple tools. Instead of duplicating the check inside each tool, a single hook can enforce the rule consistently.
You should understand:
- What is the difference in purpose between a PreToolUse (interception) hook and a PostToolUse (normalization) hook?
- Why is a hook a better solution than an in-tool check when a rule needs to apply across multiple tools?
Deep dive: Agent SDK Hooks
1.6 Task Decomposition
Task decomposition means breaking a complex task into smaller, manageable steps.
Prompt chaining is useful when the workflow is predictable and the number of steps is known in advance. Dynamic decomposition is better when the model needs to decide how many steps are required based on the task. A common problem is attention dilution: when too much information is handled in a single contex, the agent may lose focus on individual details. A per-file pass can help by processing each file separately with a focused context.
You should understand:
- When should you choose prompt chaining—a fixed pipeline with a predictable number of steps—over dynamic decomposition, where the model decides how many steps it needs?
- What is attention dilution, and how can a per-file pass help prevent it?
Deep dive: Task Decomposition Strategies
1.7 Session Management
A resumed session may contain stale context. If a file or other external resource has changed since the previous session, the model may not automatically recognize that information in its conversation history is outdated. In these situations, starting a fresh session with a structured summary can be more reliable than continuing a long conversation with potentially stale context.
You should understand:
- Why isn't it guaranteed that a resumed session will notice when a file it analyzed earlier has since changed?
- When is it more reliable to start a fresh session with a structured summary instead of resuming a long, potentially stale conversation history?
Deep dive: Manage Session State