The CCAR-F (Claude Certified Architect – Foundations) exam is a practical, scenario-driven test of your ability to design, build, and operate agentic systems on top of Claude. It rewards the engineering judgment you only really develop by building agents and watching them fail in the ways agents fail. As with anything I want to learn properly, I set the exam as the goal — it’s a fixed target that forces depth over breadth.
This post is the study routine and the domain-by-domain breakdown I used to pass, in the hope it saves someone else the circuitous route.
The exam content is defined by the official CCAR-F Foundations exam guide (62 questions, 75 minutes, 80% pass mark, scenario-based). Read it once before anything else: the “Skills in” bullets under each domain are not a study checklist — they are effectively a list of the things you need to recognize on sight, and each one maps almost directly to a question you’ll see. The scenarios dress the same skills in different clothes, so if you can explain why a given “Skills in” bullet is the right move and what the wrong move looks like, the exam is largely a reading-comprehension test of that knowledge.
A note on how I studied
I learn best by doing, so I built throwaway agents for every domain rather than only reading. My routine for each topic was:
- Read the task statement and its “Knowledge of” / “Skills in” bullets.
- Build the smallest agent that exercises the concept — even a contrived one.
- Deliberately break it the way the exam hints at (the anti-patterns are as instructive as the patterns).
- Write a one-paragraph note on what surprised me, then move on.
The anti-patterns mattered more than I expected. Several questions are essentially “spot the anti-pattern and name the fix,” so being able to recognize them on sight is worth more than memorizing API names. For each question I found at least two answers that were not feasible, and generally I was able to determine the answer that best suited the question scenario.
Domain 1 — Agentic System Design & Orchestration
This is the heart of the exam. The single most important idea is the agentic loop lifecycle: send the conversation to Claude, inspect stop_reason, execute any requested tools when it’s "tool_use", append the results, and loop. The loop terminates only on "end_turn". The guide calls out two anti-patterns explicitly — checking for assistant text content as a stop condition, and setting an arbitrary iteration cap as the primary stop condition. Both will bite you in questions.
Subagents and the Task tool. A coordinator can only spawn subagents if its allowedTools includes "Task" — that requirement shows up repeatedly. When spawning, emit multiple Task calls in a single response for parallelism; emitting them across separate turns makes them sequential. Pass complete prior findings into the subagent’s prompt, and use structured data (content separated from metadata like source URLs, document names, page numbers) so attribution survives the handoff.
Enforcement vs. guidance. Know the difference cold. Prompt-based guidance (“always verify identity before refunding”) has a non-zero failure rate; programmatic enforcement (a prerequisite gate in the tool dispatcher that blocks process_refund until get_customer has set a verified ID) is deterministic. When the exam describes a compliance requirement — identity verification before financial operations, for example — the answer is the gate, not the system prompt. Return a structured, retryable error (prerequisite_not_met, isRetryable: true) that tells the model exactly which step to run next.
Decomposition. Fixed sequential pipelines (prompt chaining) suit predictable, repeatable work like “analyze each file, then run a cross-file integration pass.” Adaptive decomposition suits investigation — each phase’s output generates the next phase’s subtasks. The exam gives you scenarios and asks which fits; the tell is whether the subtasks can be known in advance.
Domain 2 — Tool Design & MCP Integration
The tool_choice options are small in number but heavily tested:
"auto"— Claude may reply with text and call no tool at all."any"— Claude must call a tool, but chooses which. Use it when the document type is unknown and several extraction schemas exist.{"type": "tool", "name": "..."}— forced selection; Claude must call the named tool. Use it to guarantee ordering, e.g. forcingextract_metadatabefore any enrichment.
Distribute tools narrowly across subagents — a search agent gets WebSearch, a document agent gets Read/Grep, a synthesis agent gets nothing. Over-scoping tools is a recurring wrong answer.
Domain 3 — Claude Code Configuration & Workflows
Know the CLAUDE.md hierarchy: user-level (~/.claude/CLAUDE.md, personal, not shared via version control), project-level, and directory-level. Keep it modular with @import references or split into .claude/rules/ topic files rather than a monolithic file — the exam shows a “before/after” of this split.
Custom slash commands: project-scoped in .claude/commands/ (shared) vs user-scoped in ~/.claude/commands/ (personal). Skills live in .claude/skills/ with SKILL.md frontmatter; the context: fork option runs the skill in an isolated sub-agent so its verbose output doesn’t pollute the main conversation. Personal variants go in ~/.claude/skills/ under a different name so you don’t override the shared team version.
For CI/CD: the -p / --print flag runs Claude Code non-interactively, and --output-format json with --json-schema enforces structured output in pipelines.
Domain 4 — Prompt Engineering & Structured Output
Few-shot prompting is the exam’s go-to answer when detailed instructions alone produce inconsistent output — especially for ambiguous-case handling like tool selection for ambiguous requests, or branch-level test coverage gaps. When a question says “the instructions are clear but the output is inconsistent,” the answer is few-shot examples.
Validation and retry. Distinguish semantic validation errors (values don’t sum, wrong field placement) from schema syntax errors — the latter are eliminated entirely by tool use. Design self-correction flows: extract a calculated_total alongside a stated_total to flag discrepancies, and add conflict_detected booleans for inconsistent source data.
Batch processing. The Message Batches API gives ~50% cost savings with up to a 24-hour processing window and no latency SLA — appropriate for overnight reports, weekly audits, nightly test generation; not for blocking workflows like pre-merge checks. It does not support multi-turn tool calling within a single request. Use custom_id to correlate request/response pairs.
Multi-pass review. Use a second independent Claude instance to review generated code without the generator’s reasoning context — reviewing the output, not the reasoning, avoids the generator’s blind spots propagating into the review.
Domain 5 — Context Management & Reliability
This domain is about not losing information as conversations get long.
- Extract transactional facts (amounts, dates, order numbers, statuses) into a persistent “case facts” block included in every prompt, outside the summarized history.
- Trim verbose tool outputs to only the relevant fields before they accumulate — keep return-relevant fields from order lookups, drop the rest.
- Lead aggregated inputs with a key-findings summary and use explicit section headers; this mitigates position effects where models under-attend to the middle of long inputs.
- Have subagents return structured data (key facts, citations, relevance scores) rather than verbose content and reasoning chains when downstream agents have tight context budgets.
Large-codebase exploration. Spawn subagents for specific questions (“find all test files,” “trace the refund flow”) while the main agent keeps high-level coordination. Have agents maintain scratchpad files of key findings and reference them on subsequent questions to counteract context degradation. Summarize each phase before spawning the next. Design crash recovery with structured state exports (manifests) the coordinator loads on resume. Use /compact when context fills with verbose discovery output.
Human review and confidence calibration. Aggregate accuracy (e.g. “97% overall”) can mask poor performance on specific document types or fields — always validate by segment before automating. Use stratified random sampling of high-confidence extractions to measure error rates and surface novel patterns. Have the model output field-level confidence scores, calibrate thresholds against a labelled validation set, and route low-confidence or ambiguous/contradictory extractions to human review, prioritising limited reviewer capacity.
Provenance and uncertainty. Require subagents to output structured claim-source mappings (source URLs, document names, relevant excerpts) that downstream agents preserve through synthesis, and to include publication or data-collection dates so temporal interpretation is correct.
Exam technique
- The questions are scenario-based. Read the constraint in the scenario first — it usually dictates the answer (deterministic compliance → programmatic gate; unknown document type →
tool_choice: any; inconsistent output → few-shot). - When two answers both seem plausible, pick the one that removes choice from the model or makes failure impossible, not the one that merely suggests good behavior.
- Anti-patterns are fair game as distractors. If an option describes checking for assistant text as a stop condition, or using prompt-only instructions for a compliance step, it’s wrong.
- Timebox any question you can’t resolve in a minute or two, flag it, and move on — the easy points are elsewhere.
Summary
The CCAR-F is less about recalling API specifics and more about the engineering judgment of when to add determinism, where to put context, and how to keep attribution and reliability intact as an agent system scales. The domains build on each other — the loop from Domain 1 needs the tool design of Domain 2, the configuration of Domain 3, the prompting discipline of Domain 4, and the context hygiene of Domain 5. Studying them as one connected system rather than five separate lists is what made it click for me.