Prep for the Claude Certified Architect – Foundations exam (CCAR-F): the agentic loop, tools and MCP, Claude Code, prompt engineering, and context management — mapped to the exam blueprint and built against the current Claude Agent SDK.
What the Claude Certified Architect – Foundations exam (CCAR-F) actually measures — the five weighted domains, the scenario format, the 720-to-pass bar — and how this series maps to the blueprint, built and verified against the current Claude Agent SDK.
Domain 1.1, the heaviest objective on the exam: the agentic loop driven by stop_reason, the full set of stop reasons, the Agent SDK's autonomous loop and its ResultMessage subtypes, and the three loop-termination anti-patterns the blueprint wants you to recognize on sight.
Domain 1.2, 1.3, and 1.6: the coordinator–subagent (hub-and-spoke) pattern, the AgentDefinition fields that configure a subagent, the context-isolation rule the exam loves to test, and how to decompose a task without leaving gaps.
Domain 1.4, 1.5, and 1.7: enforcing multi-step workflows with handoff, intercepting tool calls with Agent SDK hooks (PreToolUse/PostToolUse and their decisions), and managing session state, resumption, and forking.
Domain 2.1 and 2.2: writing tool descriptions the model selects correctly, splitting overlapping tools, and returning structured error responses — categories, retryable flags, and the empty-result-vs-failure distinction — so the agent can recover intelligently.
Domain 2.3, 2.4, and 2.5: scoping each agent's tools so selection stays reliable, the three tool_choice modes, wiring MCP servers with project vs user scope and env-var secrets, and using the built-in tools — including the Edit-fails-so-Read-then-Write fallback.
Domain 3.1 and 3.3: the CLAUDE.md configuration hierarchy (user, project, directory), why user-level config isn't shared with your team, @import and .claude/rules/ for modular organization, and glob-scoped rules that load only for the files they apply to.
Domain 3.2 and 3.5: custom slash commands versus skills (and the context: fork, allowed-tools, and argument-hint frontmatter), when to reach for each, and the iterative-refinement techniques — concrete examples, test-driven iteration, and the interview pattern — that steer Claude to the output you want.
Domain 3.4 and 3.6: when to use plan mode versus direct execution, the Explore subagent for verbose discovery, and running Claude Code non-interactively in a pipeline with -p, --output-format json, and --json-schema — plus why an independent instance reviews code better than the one that wrote it.
Domain 4.1 and 4.2: explicit categorical criteria that reduce false positives (and why 'be conservative' doesn't), how a high-false-positive category poisons trust in the accurate ones, and few-shot examples that teach the model to generalize its judgment to novel cases.
Domain 4.3 and 4.4: guaranteeing schema-compliant output with tool use and JSON schemas, the tool_choice modes that force it, why strict schemas fix syntax but not semantics, and the retry-with-error-feedback loop — plus knowing when a retry can't possibly help.
Domain 4.5 and 4.6: the Message Batches API's trade-offs (50% cheaper, up to 24 hours, no tool loop) and when it fits, and why an independent review instance and per-file/cross-file passes catch what a single self-review misses.
Domain 5.1 and 5.4: the summarization and position risks that lose critical facts, the case-facts block and trimmed tool outputs that preserve them, and managing a long codebase exploration with scratchpads, subagents, /compact, and crash-recovery manifests.
Domain 5.2 and 5.3: the right escalation triggers (and why sentiment and self-reported confidence aren't among them), asking for clarification instead of guessing, and propagating structured errors through a multi-agent system without either suppressing them or collapsing the whole workflow.
Domain 5.5 and 5.6: why an aggregate accuracy number hides per-segment failures, stratified sampling and calibrated field-level confidence for routing review, and preserving claim-source mappings, conflict annotations, and dates through multi-source synthesis.
The capstone: the exam draws four of six production scenarios, and the questions hang off them. For each scenario, the domains it pulls from, the design decisions that matter, and the anti-patterns the items will offer as traps — the whole series, applied the way the exam applies it.