CCAR-F curriculum

27 lessons across the five domains in the published Architect (Foundations) blueprint. Each carries worked examples, the exam traps for that topic, and a quick check. Domains below are ordered by weight, heaviest first — Agentic Architecture & Orchestration alone is over a quarter of the paper.

Domain weights for Agentic Architecture & Orchestration (27%), Claude Code Configuration & Workflows (20%), and Tool Design & MCP Integration (18%) are drawn from the published blueprint. Prompt Engineering & Structured Output (19%) and Context Management & Reliability (16%) are our best estimate for the remaining share pending confirmation against the current exam guide — see the changelog.

Agentic Architecture & Orchestration

27% of exam · 16 questions · 7 lessons
  1. 1.1 Agentic loops and termination conditions

    An agent loop with no hard stop is a cost incident waiting for a bad day. Design the termination condition before you design the loop.

  2. 1.2 Multi-agent orchestration patterns

    Manager/subagent, parallel fan-out, and sequential pipeline solve different shapes of problem. Picking by habit instead of by task shape is the exam's favorite trap.

  3. 1.3 Subagent invocation and context passing

    A subagent that inherits the whole parent transcript isn't isolated, it's just expensive. Pass structured handoff data, not a history dump.

  4. 1.4 Workflow enforcement and handoff design

    A handoff that isn't validated is a silent data-loss bug waiting for the one run where a field is missing. Enforce the boundary, don't trust it.

  5. 1.5 Agent SDK hooks and lifecycle

    A prompt instruction not to call a dangerous tool is advisory. An SDK-level hook that blocks it categorically is architecture. Put enforcement in code.

  6. 1.6 Task decomposition strategies

    Too fine and you pay orchestration overhead for nothing. Too coarse and one failure costs the whole run. Decompose by volatility, not by habit.

  7. 1.7 Session state and resumption

    Conversation history isn't durable state. If a resumed step can double-fire a side effect, the architecture is missing an idempotency boundary, not a retry.

Claude Code Configuration & Workflows

20% of exam · 12 questions · 6 lessons
  1. 3.1 CLAUDE.md and project configuration

    CLAUDE.md is versioned project memory, not a system prompt substitute. Layer it broad-to-specific and keep it about the repo, not the request.

  2. 3.2 Custom skills and SKILL.md design

    A skill earns its place by being invoked more than once with the same shape. Keep its output short — its report is the thing that stays in context, not its work.

  3. 3.3 Subagent context isolation with context: fork

    A repeatedly-invoked skill that reports its full findings into the main session will eventually crowd them back out. context: fork isolates the work and returns only the summary.

  4. 3.4 Session compaction and context management

    Compaction buys room by summarizing the past. It's the right tool for a session that's simply run long, and the wrong tool for one that's crowded by one noisy source.

  5. 3.5 Hooks and workflow automation

    Claude Code hooks enforce policy deterministically, in settings.json, outside the model's judgment — a different layer from an Agent SDK's own lifecycle hooks.

  6. 3.6 Team configuration and permission management

    Permission settings resolve by precedence across enterprise, project, and user scope. Design the safe default at the top and let narrower scopes only tighten it.

Prompt Engineering & Structured Output

19% of exam · 11 questions · 5 lessons
  1. 4.1 System prompt design for agentic systems

    The system prompt is standing instruction, not a junk drawer — per-turn data and duplicated tool descriptions belong elsewhere, or the cache never engages.

  2. 4.2 Structured output and schema enforcement

    Tool-use forces a schema the model can't wander outside of; prompted JSON is a request the model can decline to honor exactly.

  3. 4.3 Prompt techniques for reliability

    Chain-of-thought and few-shot examples earn their keep on genuinely hard tasks — standardize what generalizes, and stop copy-pasting what was really a fix for one prompt.

  4. 4.4 Multi-turn prompt strategies

    An instruction stated once at turn 1 competes with everything that comes after it — design for turn 40, not just the happy-path first message.

  5. 4.5 Output validation and parsing patterns

    Well-formatted isn't the same as correct, and complete isn't the same as parseable — validate stop_reason, schema, and business rules as three separate checks.

Tool Design & MCP Integration

18% of exam · 11 questions · 5 lessons
  1. 2.1 Tool schema design principles

    A tool is a contract you write for a reader that can't ask you what you meant. Name and describe it for the moment of selection, not the moment of implementation.

  2. 2.2 Error handling and structured tool results

    A tool that swallows its own exception hands the agent nothing to recover with. Return the failure as data, and let the model decide what to do next.

  3. 2.3 MCP server architecture and transport

    stdio and HTTP aren't interchangeable transports with different syntax — they encode different assumptions about who runs the server and who else can reach it.

  4. 2.4 MCP client integration patterns

    Adding a second MCP server multiplies your integration surface, not just your tool count — naming collisions and a slow server both become the architecture's problem.

  5. 2.5 External service integration and auth

    Credentials belong on the tool-execution side of the boundary, never in the context the model reads — the model should request an action, not hold the key that performs it.

Context Management & Reliability

16% of exam · 10 questions · 4 lessons
  1. 5.1 Context window budgeting

    A context window is a budget, not a limit you hit and then panic about. Reserve headroom before the session starts, and degrade before you fail.

  2. 5.2 Prompt caching strategy for architects

    Caching one call is a placement problem. Caching a system is a strategy problem: which layers cache, which TTL fits the traffic, and how caching survives your own pruning.

  3. 5.3 Reliability patterns: retries, idempotency, timeouts

    A retry without idempotency doesn't fix a failure — it doubles a side effect. Timeouts have to match the call shape, not a single global number.

  4. 5.4 Observability and evaluation for agentic systems

    You can't fix what you can't see, and manual spot-checks don't scale past a demo. Log the loop, not just the output, and eval before users find the regression.