Architect – Foundations
It is the most predictable exam in the programme: it presents four scenarios drawn from a bank of six, and the official guide describes all six. That is why this route goes scenario by scenario rather than by syllabus — which is how the exam itself is built. The guide is the source for the syllabus and the weights; this page is the working route.
Start here: draw the boundary of the syllabus
The official guide closes with an appendix listing what is explicitly out of scope. It is the first thing to read, because it saves more time than anything else — and because a good part of what you study for the Developer does not count here.
Check the guide's appendix for the full list before planning. As a rule of thumb derived from it:
out of our technical reference, only tool_use with
JSON schemas, the tool_choice values, stop_reason, max_tokens,
system prompts and the Batch API apply here. The rest of the sections are for the Developer.
The fact sheet
| Code | CCAR-F | Items | 60 |
|---|---|---|---|
| Structure | 4 scenarios from a bank of 6 published | ||
| Time | 120 min | Pass mark | 720 / 1000 |
| Domain | Weight | Items | Task statements |
|---|---|---|---|
| 1 · Agentic Architecture & Orchestration | 27% | 16 | 7 |
| 3 · Claude Code Configuration & Workflows | 20% | 12 | 6 |
| 4 · Prompt Engineering & Structured Output | 20% | 12 | 6 |
| 2 · Tool Design & MCP Integration | 18% | 11 | 5 |
| 5 · Context Management & Reliability | 15% | 9 | 6 |
How to reason through the items
The items are production scenarios with four options that all sound reasonable. After working through the material, these are the heuristics that most often decide between two defensible options.
| If the problem is… | The answer is usually… |
|---|---|
| It skips a mandatory step with serious consequences | Programmatic enforcement, not an instruction in the prompt |
| It confuses two similar tools from the very first turn | Expanding the descriptions: formats, examples, edge cases and boundaries |
| Tool selection degrades after N turns | The context window, not the schema |
| It decides badly when to escalate | Explicit criteria with examples, not the model's self-confidence |
| Something must reach the whole team | Project scope, versioned in the repo |
| Conventions for files scattered across the repo | Path rules with globs, not one file per directory |
| Large change with several possible architectures | Plan mode before touching anything |
| Incomplete report and subagents that work fine | The coordinator's decomposition |
| A subagent fails | Structured error: type, attempt, partial results, alternatives |
| Long review with inconsistent results | Separate passes: per unit and then integration |
| Saving cost in a flow that blocks someone | Batch only for what nobody is waiting on |
What each domain tests
The guide breaks each domain into several task statements with what you need to know and what you need to be able to do. That detail is in the official document and is worth reading in full. What follows is the topic map to orient your study, and the conceptual development of each one is in the notes.
Agentic Architecture & Orchestration
27%Agentic loops and their stopping condition · coordinator and subagents, with explicit context passing and parallel spawning · enforcement and handoff in multi-step flows · hooks to intercept and normalise · fixed versus dynamic decomposition · session management, resumption and branching.
Claude Code Configuration & Workflows
20%Hierarchy and modularity of project configuration · commands and skills, with their scopes and their isolation options · conditional rules by path · when to plan before executing · iterative refinement techniques · CI integration with structured output.
Prompt Engineering & Structured Output
20%Explicit criteria to reduce false positives · few-shot for consistency and for ambiguous cases · structured output with tool use and JSON Schema, and what it guarantees and what it does not · validation, retry and feedback loops · when batch processing is appropriate · multi-pass and multi-instance review architectures.
Tool Design & MCP Integration
18%Descriptions that differentiate similar tools · structured errors with category and retryability · distributing tools by role and configuring the choice · integrating MCP servers with their scopes and credentials · choosing among the built-in read, search and edit tools.
Context Management & Reliability
15%Preserving critical information across long interactions · escalation criteria and ambiguity resolution · error propagation between agents · context in large codebase exploration · human review and confidence calibration · information provenance and uncertainty in multi-source synthesis.
The six scenarios
The exam presents four of six, and the official guide describes them in detail: read them there. What follows is what is worth having worked through for each one — the decisions you need to be able to defend and the anti-patterns that show up as distractors.
1 · Support resolution agent
Decisions to defend
- The loop is controlled by
stop_reason, not by an iteration cap. - An irreversible operation gets a human checkpoint or a programmatic prerequisite before the loop is wired up; and if the role does not need it, the tool is removed.
- The escalation tool competes with the rest: without an exclusion condition in the descriptions, it becomes the easy way out or is never used.
- Failures come back with an error flag and a category, never as an empty result.
- Long conversations require pulling the transactional facts out of the history that gets summarised.
Anti-patterns
- Auditing a dangerous capability instead of removing it.
- Relying on a prompt instruction where enforcement is needed.
- Setting a resolution target without defining what counts as resolved.
2 · Code generation with Claude Code
Decisions to defend
- Plan before executing when there are several possible architectures and many files in play.
- Project configuration is concatenated across levels: contradictory rules have to be removed, not left to see which one wins.
- Permission rules are evaluated in a fixed order and the first match decides.
- Each persistent-context mechanism solves a different problem; piling them into a single file degrades them all.
- Two corrections on the same problem mean contaminated context: clear it and start again.
Anti-patterns
- Permissive mode "for speed" against a live repository.
- Entrusting a prohibition to a note in the configuration instead of to a control.
3 · Multi-agent research system
Decisions to defend
- Subagents do not inherit context: findings travel in the prompt they are launched with.
- Parallelising means emitting several spawn calls in a single response.
- Partition the scope between subagents so work is not duplicated.
- A refinement loop where the coordinator spots gaps and re-delegates with targeted queries.
- Separate content from metadata so attribution survives every summary.
Anti-patterns
- Blaming the subagents when the failure is in how the work was divided.
- Always running the full pipeline instead of choosing based on the query.
- Using multi-agent on coupled work, where it multiplies cost with no gain.
4 · Development productivity
Decisions to defend
- Hybrid context model: preload what is stable and retrieve the rest on demand.
- Delegate to a subagent the exploration that would flood the main context.
- Choose the tool by what you are looking for: content, paths or a targeted edit, with its fallback when it fails.
- Connect servers deliberately: each one spends context even when it is not used.
- Narrow the tool catalogue by role before selection degrades.
Anti-patterns
- Loading the whole repository "so it has context".
- Spreading many tools across several servers believing it reduces confusion.
5 · Claude Code in CI/CD
Decisions to defend
- Findings are material to triage, not a verdict: you confirm what is demonstrable from the diff.
- The human gate goes where a finding turns into an action that is hard to reverse.
- False positives drop by giving the team's conventions, not by asking for "more rigour".
- Non-interactive mode with structured output to consume the result in the pipeline.
- An independent instance reviews better than the one that generated the code.
Anti-patterns
- Blocking the merge on every finding: within a week it gets approved automatically.
- Accepting claims about runtime behaviour that the reviewer had no way to measure.
6 · Structured data extraction
Decisions to defend
- The schema guarantees the shape, not the meaning: semantic validation is still yours.
- Nullable fields so the model can abstain instead of inventing.
- Escape hatches in closed categories, because fixed lists age.
- Retry with the specific error as feedback, knowing when it is pointless: if the data is not there, it will not appear.
- Per-field confidence and sampling to decide what a human reviews.
Anti-patterns
- Recomputing a total from the line items: it fabricates data that now passes validation.
- Retrying with the same prompt expecting a different result.
Four labs
The guide proposes practical preparation exercises. These are the ones I would build, aligned with them and with what weighs most in the exam. Building one teaches more than rereading the theory three times.
| # | Lab | Reinforces |
|---|---|---|
| 1 | Agent with three or four tools, two of them deliberately similar. Loop controlled by stop_reason, errors with category and retryability, and a programmatic control that blocks an operation above a threshold. | Orchestration · tools · context |
| 2 | Configure a repository for a team: project rules, conditional rules by path, an isolated skill with restricted permissions, and a shared MCP server with credentials kept outside the repo. | Claude Code · MCP |
| 3 | Extraction pipeline with nullable fields and extensible categories, a validation and retry loop with feedback, and a large batch with selective resubmission of the failures. | Structured output · context |
| 4 | Coordinator with two subagents launched in parallel, structured output separating claim, evidence, source and date, a simulated timeout to test error propagation, and conflicting sources. | Orchestration · tools · context |