Claude Certified Architect Foundations (CCA-F)

The architect's first decision: agent, prompt chain, single LLM call, or deterministic pipeline? A decision tree that decides half the Domain 1 exam questions before you read them.

The four-step loop every agent runs. stop_reason as the only termination signal that matters. The three wrong stopping mechanisms the exam tests as distractors.

The single most-tested failure mode in Domain 1: an agent that calls the same tool forever. Why iteration caps are the distractor, why structured error responses are the fix, and how this lecture is one instance of the Root Cause Bias pattern that runs through every Domain 1 question.

Wire up the Anthropic Python SDK end-to-end. Run a real agentic loop against Claude with a deliberately broken tool, watch it loop until the safety cap fires, then ship a fix and watch the loop terminate at iteration one. Same prompt, same model — 14× cheaper, clean answer to the user.

The architect's second decision — agent, fine, but ONE agent or MANY? The hub-and-spoke pattern, the four jobs of the coordinator, and the single most-tested fact in the multi-agent block: subagents do NOT inherit the coordinator's context. Sets up the Task tool deep dive in the next lecture.

How a coordinator actually spawns subagents — AgentDefinition, the Agent tool (called "Task" in the CCA-F exam guide), and the single most-forgotten configuration flag in the multi-agent block. Plus the three things every spawn prompt must contain, parallel spawning for a one-third latency win, and why coordinator prompts should specify goals instead of steps.

The Anthropic Claude Agent SDK and Agent tool in action. Three research subagents spawned in parallel from one coordinator turn — watch the parallel spawn happen live, see each subagent's isolated context produce its own JSON, then watch the coordinator aggregate everything into a side-by-side comparison. The architectural pattern the exam tests, executed end-to-end.

When a subagent returns broken output, the instinct is to give the subagents shared memory so they can coordinate. That's a textbook Root Cause Bias distractor. The actual fix lives upstream — at the coordinator. Three disciplines that get decomposition and handoff right, plus the Anthropic docs quote that makes this design rule non-negotiable.

Four named decomposition disciplines straight from the CCA-F exam guide — goals over steps, partition without overlap, dynamic selection, iterative refinement. Walked one by one with the concrete examples the exam tests. Closes the loop on the multi-agent block: L2.5 said WHY, L2.6 said HOW, L2.7 demoed it, L2.8 named the anti-pattern, L2.9 is the playbook for getting decomposition right.

A prompt that says "never refund over $500" is a request. The model usually obeys — but "usually" isn't compliance. When the failure cost is real money, real compliance, or real safety, hooks enforce; prompts ask. The deterministic-vs-probabilistic distinction, both hook types the exam tests (PreToolUse and PostToolUse), and the decision rule for which one to reach for.

When the model violates a business rule, the architect's first instinct is to rewrite the prompt — make it more emphatic, more explicit, more threatening. That instinct doesn't work, for three structural reasons. The right fix is what Lecture 13 covered — move the rule from the prompt to a hook. Closes the Root Cause Bias quartet.

Three SDK primitives — continue, resume, fork, and the one decision rule the exam tests: resume when prior context is still valid, start fresh when tool results have gone stale. Includes three code samples on GitHub you can run end-to-end.

One of the six exam scenarios, walked end-to-end. A coordinator delegates to four named subagents — web research, document analysis, synthesis, report generation — to produce a comprehensive cited report. Every Domain 1 concept from the last eight lectures applied to one real system. The four subagent names appear on the exam verbatim.

Tool descriptions are the primary mechanism the model uses for tool selection — not the system prompt, not the user input. The four elements every good description includes, the three repair techniques (rewrite, rename, split) the exam tests verbatim, and the system-prompt trap that creates unintended tool associations.

When tool routing breaks in production, the architect's first instinct is to add a classifier layer in front of the tools. The exam offers it as a wrong-answer distractor. Three reasons it doesn't fix the root cause, and what does instead. Root Cause Bias canonical pattern #1.

A tool that returns "Operation failed" is a tool the agent can't recover from. The four error categories the exam tests (transient, validation, business, permission), the structured response shape (isError, errorCategory, isRetryable, description), and the two distinctions that catch most architects — empty results aren't failures, and local recovery beats propagation. Same architectural lesson as the forever-loop fix, applied at the tool level.

Every tool you give an agent costs context window space on every single turn. Fewer tools means sharper selection — and Anthropic's docs say it plainly. This lecture covers the two-layer SDK model (tools vs allowed_tools), the rule of thumb for when to use tool search, and the architectural takeaway: scope by removing tools from the tools list, not by gating them behind permission prompts.

Six built-in tools come with every Claude Code session. The question architects fail on more than any other is which one to reach for. This lecture walks through what each tool does best, the Grep-vs-Glob distinction the exam tests directly, the Read + Write fallback for when Edit can't find a unique match, and the right way to explore a codebase you've never seen.

MCP — Model Context Protocol — replaces the wrapper code you used to write for every API the agent needed to touch. This lecture covers what MCP solves, the hub-and-spoke architecture, the three configuration scopes (local, project, user) and which one ships with your code, the .mcp.json shape with environment-variable expansion for credentials, and the trap most architects walk into the first time they ship a custom MCP tool.

Build a working MCP server with the Claude Agent SDK — one tool, one Python file, plugged into an agent that runs against a real GitHub repository. Covers the architecture (how Claude calls code on your machine), the three SDK primitives that build a server, and the scoping pattern that keeps the agent locked to your tool. Closes Domain 2.

CLAUDE.md is the persistent-instructions file Claude reads at every session start. This lecture covers the four memory levels Claude loads, the canonical hierarchy bug the exam tests most often (and the production failure mode behind it), the @import syntax for keeping files modular, and the two commands every architect should know — /init and /memory.

Slash commands and skills package repeatable workflows into one-line invocations. This lecture covers the two file forms (legacy .claude/commands/ and modern .claude/skills/<name>/SKILL.md, merged in Claude Code 2.1.3), the SKILL.md frontmatter fields the exam tests, project scope vs user scope, and three production gotchas the docs don't surface — including the description-pattern that takes auto-activation from a coin flip to 100%.

CLAUDE.md loads into context at every session start and counts against every turn. The .claude/rules/ directory is the first-party Claude Code mechanism for splitting monolithic instructions into topic files that load only when relevant — a Terraform rule that fires only on .tf files, a Python rule that fires only on .py files. This lecture covers the paths: frontmatter syntax, three production gotchas the docs don't surface (the Read-vs-Write trap, the user-scope silent ignore), and the Root Cause Bias case for switching from a rule to a PreToolUse hook when enforcement matters.

Claude Code runs in one of four permission modes — default, acceptEdits, plan, bypassPermissions. Plan Mode is the read-and-propose checkpoint architects reach for when the cost of a wrong change is high. This lecture covers the four modes, the three ways to enter Plan Mode (Shift+Tab, /plan prefix, --permission-mode flag), the ExitPlanMode approval flow, the architect's heuristic for when to plan vs when to skip, and the critical caveat most architects miss: Plan Mode is prompt-enforced, NOT a security boundary. For real enforcement, the answer is hooks or restrictive allowedTools — the Root Cause Bias call.

Multi-turn Claude Code sessions either converge on the right output or they drift into something worse than your first attempt. The difference is discipline. This lecture covers the three techniques Anthropic officially documents — examples (reference a pattern Claude can imitate), tests (write the failing test first), interviews (let Claude ask you via the AskUserQuestion tool) — plus the exam-distinctive feedback-grouping rule from Task Statement 3.5 and the TDD context-pollution gotcha that every team hits the first time. Maps 1:1 to CCA-F Task Statement 3.5.

Claude Code in CI is a different animal — no human reads the diff, no human approves the bash call, and an attacker can shape the prompt through PR titles and issue bodies. This lecture covers the CI flag inventory the exam tests (-p, --output-format json, --json-schema, --max-turns, --max-budget-usd, --bare), the locked-down permission posture (--permission-mode dontAsk plus explicit --allowedTools with the space-then-asterisk glob gotcha), the official anthropics/claude-code-action@v1 GitHub Action, and the CVSS 9.4 "Comment and Control" prompt-injection threat disclosed April 2026 with the full architectural mitigation stack. This is the primary coverage of CCA-F Scenario 5.

The Section 4 capstone demo. Watch a real Flask + Terraform project transform from "what you'd inherit" — bloated CLAUDE.md, no other config — into a properly structured Claude Code setup that uses every technique from this section. Then watch the configuration fire live in Claude Code: /memory inventory, the inline "Loaded X" notice that proves path-scoping is firing, and a directive skill activating on /review. The demo project is in the course's GitHub repo — clone, run, replay every beat on your own machine.

The architectural foundation for Section 5. Where does prompt content go — system parameter vs user message — and how do you structure both with XML tags so Claude parses your intent without ambiguity? This lecture covers the OpenAI muscle memory bug that hits architects porting GPT-4 prompts to Claude, the stability rule for system vs user placement (and why getting it wrong defeats prompt caching), the canonical XML tag names Anthropic documents, and three production gotchas the docs don't flag loudly — silent drift from mismatched tags, tag-name collisions with user content, and the caching anti-pattern that quietly inflates your bill. First lecture of Section 5 — every later lecture depends on this foundation.

Few-shot examples calibrate Claude's outputs in a way prose instructions can't. This lecture covers the three selection criteria Anthropic names explicitly (relevant, diverse, structured), the right example count (3-5 per Anthropic, 2-4 per the CCA-F exam guide — both are "a small handful"), the diversity trap that's the #1 self-inflicted few-shot wound in production, recency bias (with measurable performance gaps), and the over-prompting cliff backed by the Siemens AG empirical study. Maps directly to Task Statement 4.2.

Two distinct mechanisms get called "chain of thought" — prompt-engineering CoT (the <thinking> XML pattern) and Anthropic's API-level extended thinking (a runtime model mode). This lecture covers the architectural distinction, the current API shape for adaptive thinking on Opus/Sonnet 4.6+ (budget_tokens is deprecated; manual enabled returns 400 on Opus 4.8/4.7), the incompatibilities the exam tests (forced tool_choice and assistant prefill don't work with extended thinking), and the killer Root Cause Bias trap where extended thinking is the seductive WRONG answer when the real problem is self-review confirmation bias and the right fix is a second independent reviewer instance.

Prefill is the Claude technique you'll see in older codebases and tutorials — it's now DEPRECATED on every Claude 4.6+ model and returns a 400 error. This lecture covers what prefill was (so you can recognize the three legacy patterns in inherited code), why Anthropic moved on (the silent-malformed-output problem), and the three documented replacements in Anthropic's recommended order: plain instruction first, output_config.format with JSON Schema for guaranteed compliance, and tool_use with tool_choice for structured extraction. Plus stop_sequences as the narrow remaining output-control tool. Sets up Lecture 5.35 on tool_use end-to-end.

The two mechanisms Claude offers for guaranteed structured output — tool_use with tool_choice (the exam-canon answer for Task Statement 4.3) and output_config.format with JSON Schema (the GA-since-November-2025 alternative). This lecture covers the tool_use end-to-end pattern (the Scenario 6 foundation), the three tool_choice variants and when to use each, the architect's decision rule for picking between mechanisms, and the production failure mode that survives both: constrained decoding guarantees format adherence, NOT accuracy. The validation-retry loop in Lecture 5.36 catches the semantic gap.

Schema design principles that make extraction reliable, and the validation-retry-with-error-feedback pattern that catches the semantic errors grammar enforcement can't see. Central reframe: post-November 2025, validation-retry exists for SEMANTIC errors only — constrained decoding eliminated the syntactic retry. This lecture covers the strict-mode JSON Schema subset, four documented schema design patterns (other + detail, "unclear" enum, nullable for optional, self-correction fields), the validation-retry-with-error-feedback code pattern, the three classes of unrecoverable errors, and the production rule that error message specificity decides convergence. Maps to Task Statement 4.4.

Anthropic's Message Batches API gives you 50% off Claude inference (both input and output tokens) — but only for the workloads that can tolerate up to 24-hour completion. This lecture covers the architect's decision rule for when to batch vs when to keep synchronous, the API mechanics (create, poll, retrieve), the custom_id correlation rule (the most-cited Batches bug is indexing into an array), three production realities the docs don't surface loudly (no webhooks, per-request queue limit, 24h expiry during peak demand), and how the validation-retry pattern from the previous lecture changes at batch scale — you don't retry the batch; you build a new batch from the failed custom_id subset. Maps to Task Statement 4.5.

The Section 5 capstone demo. Watch tool_use with strict, validation-retry with tool_result + is_error=True, and the Message Batches API operate together on five real contracts. The pedagogical anchor is one specific moment: the retry loop fires on a contract with a real semantic inconsistency (stated total = $215K, line items sum to $205K), exhausts at three attempts, and surfaces the case for human review. That's the L5.36 "retries don't help when the source is inconsistent" pattern in production form. Includes batch processing demo with custom_id correlation and the unordered-results-by-default behavior. Demo repo is in the course's GitHub at github.com/command0r/CCA-F/S05/L08-Structured-Extractor-Scenario-6 — clone, run, replay every beat on your own machine.

The Section 6 foundation. Context windows on the current Claude 4.6+ generation (1M tokens GA on Opus 4.6+ and Sonnet 4.6, 200K on Haiku 4.5), token counting via the documented count_tokens API (not the "~4 chars per token" folklore), and Anthropic's three documented placement rules that produce a 30% quality improvement on long-context tasks. Plus the lost-in-the-middle problem — which Anthropic now calls "context rot" — and the Root Cause Bias trap that catches most candidates on Domain 5: symptom is "Claude won't focus on right content"; wrong fix is bigger window; right fix is restructure placement. Maps to Task Statement 5.1.

The Claude-specific feature with the sharpest pricing math in the API. This lecture covers cache_control syntax and the 4-breakpoint maximum, the 5-minute vs 1-hour duration tiers, the tools→system→messages invalidation cascade, the read/write pricing multipliers (0.1x read, 1.25x 5-min write, 2x 1-hour write), break-even math (~1.3 reads per write for 5-min, ~2.0 for 1-hour) — and the model-specific minimum cacheable token count that's both exam bait and a production trap (1,024 tokens for Sonnet 4.6, but 4,096 for Haiku 4.5 — switching to a "cheaper" model can accidentally disable caching). Plus the Root Cause Bias call: "bill too high" → wrong fix is "smaller model"; right fix is "audit cache hit rate first."

Two tightly-coupled topics — how token usage grows in multi-turn Claude conversations (with the Opus 4.5+/Sonnet 4.6+ thinking-preservation change that compounds cost on every turn), and the compaction discipline that prevents it. This lecture covers the /compact and /clear commands in Claude Code, the exam-distinctive "what survives compaction" mechanics (system prompt survives, path-scoped rules don't), the practitioner "50% fill" rule grounded in lost-in-the-middle research, the documented compaction-when-full failure (GitHub #23751), and the spec-file pattern that lets you preserve load-bearing facts across /clear. Plus the Root Cause Bias call: "bill balloons over a long session" → wrong fix is bigger model; right fix is compaction discipline.

The architectural rules for shipping Claude to production where failure is a fact of life. This lecture covers the Anthropic Python SDK's built-in retry behavior (verified defaults: max_retries=2 NOT 3, 10-minute timeout, exponential backoff 0.5s→8s with 25% jitter, retries on 408/409/429/5xx), the retryable-vs-permanent status code split (never retry 400/401/402/403/404/413/422), the 529-vs-429 distinction the exam tests (529 = global capacity, fall back to smaller model; 429 = your-org limit, respect retry-after literally), the 21K-token streaming requirement, and the service_tier="auto" default for Priority capacity. Plus the cardinal rule — don't build a custom retry loop that fights the SDK's loop.

Section 6's cost-economics chapter. This lecture pulls cost-decision threads from prompt caching (L6.40), multi-turn compaction (L6.41), reliability (L6.42), CI flags (L4.29), and the effort parameter (L5.33) into one architectural framework. Covers the cost spectrum (the documented $1,800-in-48-hour runaway vs Notion's documented 90% savings), the architect's audit order when the symptom is cost (cache hit rate first; model swap LAST), current per-model pricing (Opus $5/$25, Sonnet $3/$15, Haiku $1/$5 per MTok), the Opus 4.7+ tokenizer change that produces up to 35% more tokens for the same text (breaks cost forecasts from older measurements), and Anthropic's documented "choose a model" heuristic that recommends adaptive thinking over model swap when the constraint is cost.

The Section 6 capstone. Watch a real customer support agent — substantial system prompt, four tools, five queries — run twice. First without caching (baseline). Then with cache_control on the system prompt and the last tool. The headline numbers: cache hit rate climbs from 0% to 99.8%, total cost drops 44.6% on a 5-turn demo. Plus the architectural insight: Turn 1 with caching costs MORE than baseline Turn 1 — that's the 1.25x cache write premium from lecture 6.40. The savings come from reading the cache at 0.1x base on subsequent turns. At higher turn counts (the Notion case), savings approach 90%. Demo repo is in the course's GitHub at github.com/command0r/CCA-F/S06/L06-Optimize-Multi-Turn-Agent — clone, run, replay every beat on your own machine.

The first of the six canonical CCA-F exam scenarios. The Customer Support Resolution Agent — Agent SDK + four MCP tools (get_customer, lookup_order, process_refund, escalate_to_human) + 80% first-contact resolution target. You've already watched this exact agent run end-to-end in Lecture 6.44 — Section 6's demo capstone built on this exact shape. This lecture surfaces the exam patterns the demo embodies: the four architectural pillars (directive tool descriptions, scoped allowed_tools, escalation criteria with few-shot in the system prompt, prompt caching), the canonical Root Cause Bias trap ("tool routing unreliable → fix descriptions, not classifier layer"), and the four typical distractor patterns the exam uses. Plus the recognition signal that lets you spot Scenario 1 from a few sentences of exam prose.

The second of the six canonical CCA-F exam scenarios. Code Generation with Claude Code — slash commands, CLAUDE.md hierarchy, plan mode vs direct execution, path-scoped rules. You've already built this configuration end-to-end in Lecture 4.30 — Section 4's demo capstone with the bloated→lean CLAUDE.md refactor + path-scoped rules + skill + settings.json. This lecture surfaces the exam-answer patterns: the four architectural pillars from Section 4 (configuration hierarchy, repeatable procedures, permission posture, iterative refinement), and the Root Cause Bias trap the exam tests — rules are advisory, hooks are enforcement. When a rule MUST be followed, the answer is a PreToolUse hook, not another rule.

The third of the six canonical CCA-F exam scenarios. The Multi-Agent Research System — one coordinator plus four specialized subagents (web_search, document_analysis, synthesis, report_generation). You've already seen the Domain 1 walkthrough in Lecture 2.13; this lecture adds the cross-domain integration (Domain 4 prompting patterns for subagent isolation, Domain 5 context budgets per subagent). The architectural anchor: four pillars (coordinator decomposes, subagent specialization, context isolation, coordinator-level aggregation), and the Root Cause Bias trap (pattern #3 from CLAUDE.md §15) — subagent output wrong → wrong fix is "add shared memory between subagents"; right fix is "fix coordinator task decomposition." Subagents talk through the coordinator. Never directly to each other.

The fourth of the six canonical CCA-F exam scenarios. The Developer Productivity scenario — Claude Agent SDK with built-in tools (Read, Write, Bash, Grep, Glob) composed with MCP servers. This is the programmatic SDK angle on Claude-for-developers — distinct from Scenario 2's Claude Code CLI angle. Students confuse them on the exam; this lecture's disambiguation panel makes the distinction sharp. Architectural pillars: SDK runtime, built-in tools + MCP composition, scoped allowed_tools per agent role (least privilege), PreToolUse hooks for enforcement. Root Cause Bias trap: capability problems need capability fixes. If the agent shouldn't do it, the agent shouldn't have the capability to do it.

The shortest lecture in the course. Scenarios 5 (Claude Code for CI/CD) and 6 (Structured Data Extraction) already have dedicated deep coverage in Lectures 4.29 and 5.35-5.38 — this lecture is the recognition layer plus the three most exam-distinctive points for each. Scenario 5: --max-turns and --max-budget-usd have NO defaults, the CVSS 9.4 mitigation stack, the Bash glob gotcha. Scenario 6: tool_use is the Task Statement 4.3 exam canon, constrained decoding handles syntax not semantics, Batches results are unordered (map by custom_id).

The cohesive view of the meta-skill threaded through every section of this course. The Root Cause Bias names what every CCA-F exam question is testing: "something is broken — which architectural change fixes the root cause?" Two or three options fix the symptom; one fixes the cause. This lecture surfaces the four canonical patterns from CLAUDE.md §15 in one table (the course's cheat sheet), plus the wrong-answer signatures ("classifier layer," "shared memory," "more emphatic prompt," "larger model") and right-answer signatures ("fix descriptions," "fix coordinator decomposition," "use a hook," "scoped allowed_tools") students need to recognize on the exam under time pressure. Section 8 is consolidation, not new teaching.

The Root Cause Bias tells you what the right answer looks like. This lecture tells you how to apply it under exam conditions — 60 questions, 120 minutes, 720 to pass. We lock in the exam mechanics and their three strategic implications. We walk the two-pass strategy that banks confident answers in the first 60 minutes and returns to flagged questions with fresh eyes in the second 60 — and we name the Pass 2 trap that loses more points than it gains. Then the three-step elimination move: read the question and options before the scenario, apply wrong-answer signatures to cut four options to two, match right-answer signatures to the symptom for the final pick. Closes with final reminders for the morning of the exam and the hand-off into Section 9.

You finished the course. This is the close. Three things in six minutes: how to read your practice exam result without restarting from Section 1, the Root Cause Bias compressed into one sentence to walk into the real exam with, and the practical exam-day routine — registration link, sleep, two-pass strategy, never leave a question blank, trust the meta-skill.