Skip to content
CCAF Preparation

Divergence log

Software moves faster than exam guides. Where the official CCAR-F exam guide (v1.0, July 2026) and current Anthropic documentation disagree, this page records both — and which one to answer with on the exam.

Domain 1 — Agentic Architecture & Orchestration: Exam Guide vs Current Product Divergences

Subagent-spawning tool: "Task" vs "Agent"

  • Exam guide says: The mechanism for spawning subagents is called "the Task tool," and a coordinator's allowedTools must include "Task" to invoke subagents (Task 1.2 Knowledge, Task 1.3 Knowledge).
  • Current docs say: "Claude invokes subagents through the Agent tool, so include Agent in allowedTools to auto-approve subagent invocations without a permission prompt." The tool was renamed from "Task" to "Agent" in Claude Code v2.1.63. Current SDK releases emit "Agent" in tool_use blocks but still use "Task" in the system:init tools list — a live transitional state, not a clean cutover.
  • Answer on the exam: "Task" — use that name and that string in allowedTools on any exam question.
  • Sources: Exam guide — research/findings/00-exam-guide-objectives.md (Task 1.2, Task 1.3). Current docs — https://code.claude.com/docs/en/agent-sdk/subagents (fetched 2026-07-30).

stop_reason: two exam values vs the full live enum

  • Exam guide says: The agentic loop lifecycle keys on exactly two stop_reason values — "tool_use" (continue) and "end_turn" (terminate) — and that is the complete model the Skills bullets test (Task 1.1 Knowledge and Skills).
  • Current docs say: The Messages API documents seven stop_reason values: end_turn, max_tokens, stop_sequence, tool_use, pause_turn, refusal, and model_context_window_exceeded. A production loop has to branch on all seven — pause_turn in particular requires re-sending the conversation to let Claude continue, not treating it as done.
  • Answer on the exam: Loop control questions test tool_use vs end_turn specifically — that two-value model is the tested surface. Recognise the other five values exist and handle them correctly if a question probes production robustness, but the "continue vs terminate" gate the exam cares about is the two-value one.
  • Sources: Exam guide — research/findings/00-exam-guide-objectives.md (Task 1.1). Current docs — https://platform.claude.com/docs/en/api/messages and https://platform.claude.com/docs/en/api/handling-stop-reasons (both fetched 2026-07-30).

Hub-and-spoke "subagents never communicate directly" vs nested subagent delegation

  • Exam guide says: In coordinator-subagent orchestration, "all subagent communication routes through the coordinator" and subagents never communicate directly with each other, "for observability, consistent error handling, and controlled information flow" (Task 1.2 Knowledge and Skills) — captured in the lesson as an absolute, unconditional rule.
  • Current docs say: Current Claude Code allows a spawned subagent to itself spawn further subagents (nested parent-child delegation), which means the strict "subagents never talk to each other, full stop" model is a simplification of a product that now supports multi-level delegation trees rather than a single flat hub with spokes that can only report back to it.
  • Answer on the exam: Treat direct subagent-to-subagent communication as the wrong answer, and treat "route everything through the coordinator" as the correct architecture to select. The exam tests the strict hub-and-spoke model, not the more permissive nested-delegation capability of current tooling.
  • Sources: Exam guide — research/findings/00-exam-guide-objectives.md (Task 1.2). Current-state observation captured in docs/agentic-architecture-&-orchestration/02-1-2-orchestration-patterns.md, consistent with subagent spawning mechanics documented at https://code.claude.com/docs/en/agent-sdk/subagents (fetched 2026-07-30).

Session naming: --resume <session-name> implies resume can name a session; current CLI requires naming first

  • Exam guide says: "Named session resumption using --resume <session-name> to continue a specific prior conversation" is listed as a Task 1.7 Knowledge item, phrased as if --resume itself is the naming/resumption mechanism end-to-end.
  • Current docs say: --resume (-r) "resumes a specific session by ID or name, or opens an interactive picker" — it never creates or names a session. A session gets its name separately, either at start-up with --name/-n or mid-session with /rename (or Ctrl+R from the picker), and is only resumable by that name afterward. There is also --continue/-c, which resumes the most recent conversation in the current directory without any name at all.
  • Answer on the exam: --resume <session-name> is still the correct answer for "continue a specific named prior conversation" — the exam is testing the resume half of the workflow. Know that naming happens beforehand via --name/-n or /rename, since a question could test the full sequence (name at start, resume later) rather than just the resume call in isolation.
  • Sources: Exam guide — research/findings/00-exam-guide-objectives.md (Task 1.7). Current docs — https://code.claude.com/docs/en/cli-reference and https://code.claude.com/docs/en/sessions (both fetched 2026-07-30).

Domain 2 — Exam guide vs current-product divergences

MCP server scoping: two-tier exam model vs three-tier current product

Exam guide says: Task 2.4's Knowledge-of statement describes a two-tier scoping model: "MCP server scoping: project-level (.mcp.json) for shared team tooling vs user-level (~/.claude.json) for personal/experimental servers." No third scope is mentioned anywhere in the Domain 2 objectives text.

Current docs say: Claude Code's MCP documentation describes three scopes — local (default; current project only, private, stored in ~/.claude.json nested under that project's path), project (.mcp.json, shared via version control), and user (~/.claude.json, available across all of the user's projects, private). The docs also note that local was formerly called project and user was formerly called global in older Claude Code versions, and that scope precedence on a name collision is local > project > user > plugin-provided servers > claude.ai connectors, with no field merging across scopes.

Answer on the exam: Treat the guide's "user-level (~/.claude.json) for personal/experimental servers" as covering both current-docs' local and user scopes — both are personal/private and both are stored in ~/.claude.json; they differ only in whether the server is visible from other projects on the same machine. When a scenario is ambiguous about which of the two personal scopes is meant, the guide's two-tier framing (project-shared vs personal) is the one the exam is built around. If a question explicitly distinguishes "loads only in this one project" from "available in all my projects," that maps to current docs' local vs user distinction, which is real but sits underneath the exam guide's simpler model.

Subagent-spawning tool: "Task" in the exam guide vs "Agent" in current docs

Exam guide says: Domain 1's Task 1.3 Knowledge-of statement names "The Task tool as the mechanism for spawning subagents, and the requirement that allowedTools must include 'Task' for a coordinator to invoke subagents." Domain 2's Task 2.3 table of role-specific tooling (as captured in the original lesson content) likewise names the coordinator's spawning tool as "Task."

Current docs say: "Claude invokes subagents through the Agent tool, so include Agent in allowedTools to auto-approve subagent invocations without a permission prompt." The tool name was renamed from "Task" to "Agent" in Claude Code v2.1.63. Current SDK releases emit "Agent" in tool_use blocks but some current SDK releases still list "Task" in the system:init tools array — the rename has not fully propagated through every surface even in current tooling.

Answer on the exam: Use "Task" — that is the name the exam guide text uses, and it is very likely the name the exam questions themselves use. Treat "Agent" (in current Claude Code UI, docs, and some SDK output) and "Task" (in the exam guide and other current SDK surfaces) as the same capability: the built-in tool a coordinator's allowedTools must include to auto-approve subagent invocations.

  • Exam guide source: research/exam-guide-extracted.txt (Domain 1, Task 1.3 Knowledge of)
  • Current docs source: research/findings/04-agent-sdk.md citing https://code.claude.com/docs/en/agent-sdk (fetched 2026-07-30)

Domain 3 divergences — exam guide vs current Claude Code docs

Every entry below was found while enriching docs/claude-code-configuration-&-workflows/. Per the enrichment brief, the exam guide's answer is treated as the exam answer; current-docs behaviour is noted for accuracy and flagged in the lessons with a > **Current state** callout where it appears.

allowed-tools: restricts vs pre-approves

  • Exam guide says: Task 3.2 Skills in: "Configuring allowed-tools in skill frontmatter to restrict tool access during skill execution (e.g., limiting to file write operations to prevent destructive actions)." The exam guide's model is that allowed-tools is a security boundary — an allowlist that excludes everything else.
  • Current docs say: "allowed-tools — Tools Claude can use without asking permission during the turn that invokes this skill. The grant clears when you send your next message." Every other tool remains available; the actual restriction mechanism is disallowed-tools ("a bare tool name removes the matching tools from Claude's context") or a deny rule in permission settings.
  • Answer on the exam: allowed-tools restricts tool access to the listed tools.
  • Sources: exam guide — https://anthropic-partners.skilljar.com/page/partner-certifications; current docs — https://code.claude.com/docs/en/skills and https://code.claude.com/docs/en/cli-reference.
  • Where flagged in lessons: docs/claude-code-configuration-&-workflows/02-3-2-slash-commands-skills.md (> **Current state** callout in Deep Dive, plus the existing author note carried through Exam Traps and Appendix B).

"@import syntax" as a name vs literal syntax

  • Exam guide says: Task 3.1 Knowledge of: "The @import syntax for referencing external files to keep CLAUDE.md modular." The exam guide names the feature "@import" throughout Task Statement 3.1.
  • Current docs say: "CLAUDE.md files can import additional files using @path/to/import syntax." The literal directive is a bare @ immediately before a path, on its own line (e.g. @./standards/naming.md) — there is no @import keyword to type.
  • Answer on the exam: Treat "@import" as the name of the tested feature, not literal syntax. Recognise both the bare-@ form (correct in current product) and the exam guide's "@import" label as referring to the same mechanism.
  • Sources: exam guide — https://anthropic-partners.skilljar.com/page/partner-certifications; current docs — https://code.claude.com/docs/en/memory.
  • Where flagged in lessons: docs/claude-code-configuration-&-workflows/01-3-1-claude-md-hierarchy.md (> **Current state** callout in Deep Dive; the lesson's original "What You Need to Know" prose already noted the bare-@ syntax).

@ import recursion depth: 4 hops (was 5)

  • Exam guide says: no specific hop count is stated anywhere in Task Statement 3.1.
  • Current docs say: "Imported files can recursively import other files, with a maximum depth of four hops." Older Claude Code documentation stated a maximum of five hops.
  • Answer on the exam: not directly testable from the exam guide's own text (no number given), but the current-docs value to know for real usage is 4 hops.
  • Sources: current docs — https://code.claude.com/docs/en/memory.
  • Where flagged in lessons: docs/claude-code-configuration-&-workflows/01-3-1-claude-md-hierarchy.md (Deep Dive H3 "@import mechanics: depth limit and what parsing skips"; Quick Reference table).

Slash commands and skills: two systems vs one merged system

  • Exam guide says: Task 3.2 Knowledge of and Skills in describe "project-scoped commands in .claude/commands/" and "Skills in .claude/skills/ with SKILL.md files" as parallel but distinct features, each with its own bullet points and no mention of a merger.
  • Current docs say: "Custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way. Your existing .claude/commands/ files keep working." The /docs/en/slash-commands URL now redirects to and serves the Skills page. If a skill and a command share a name, the skill takes precedence.
  • Answer on the exam: Know both file shapes and both scoping rules as the exam guide frames them (flat command file vs. skill directory with SKILL.md); in current Claude Code they are one unified system with the skill winning on a name collision.
  • Sources: exam guide — https://anthropic-partners.skilljar.com/page/partner-certifications; current docs — https://code.claude.com/docs/en/skills.
  • Where flagged in lessons: docs/claude-code-configuration-&-workflows/02-3-2-slash-commands-skills.md ("What You Need to Know" opens with the unified-system framing; Exam Traps cover the file-shape distinction the exam guide still tests).

Positional arguments: 0-based indexing

  • Exam guide says: Task 3.2 does not mention positional argument syntax at all (only $ARGUMENTS is implied generically as "arguments").
  • Current docs say: "$N Shorthand for $ARGUMENTS[N], such as $0 for the first argument or $1 for the second." Indexing is explicitly 0-based.
  • Answer on the exam: not directly tested by name in the exam guide's objectives, but this enrichment wave adds it to Deep Dive/quiz because the gap analysis flagged zero prior coverage of positional arguments despite them being, per the findings, "the most-used command feature."
  • Sources: current docs — https://code.claude.com/docs/en/skills.
  • Where flagged in lessons: docs/claude-code-configuration-&-workflows/02-3-2-slash-commands-skills.md (Deep Dive H3 "$ARGUMENTS and positional arguments"; Quick Reference table; quiz question 3-2-e01).

Permission modes: auto and dontAsk are new categories beyond plan/direct

  • Exam guide says: Task 3.4 frames the decision space as a binary — "plan mode vs direct execution" — with no enumeration of a broader permission-mode system.
  • Current docs say: Claude Code documents six permission modes: default, acceptEdits, plan, auto, dontAsk, and bypassPermissions, each with different automatic-approval behaviour. auto and dontAsk in particular are not conceptual variants of "direct execution" as the exam guide's binary implies — they are distinct modes with their own approval logic (classifier-based safety checks for auto; strict pre-approved-only allowlisting for dontAsk).
  • Answer on the exam: Task 3.4 questions are scoped to the plan-vs-direct decision the exam guide describes; treat the fuller six-mode system as current-product depth rather than something the exam itself frames as a spectrum.
  • Sources: exam guide — https://anthropic-partners.skilljar.com/page/partner-certifications; current docs — https://code.claude.com/docs/en/permission-modes.
  • Where flagged in lessons: docs/claude-code-configuration-&-workflows/04-3-4-plan-mode-execution.md (Deep Dive "Permission modes compared" table; Quick Reference).

Domain 4 — Exam Guide vs Current Product Divergences

Batch API and multi-turn tool calling

Exam guide says: "The batch API does not support multi-turn tool calling within a single request (cannot execute tools mid-request and return results)." (Task 4.5, Knowledge of.) The lesson content teaches this as an absolute limitation: "you cannot: define tools and have the model call them mid-request, process tool results and continue the conversation within the same batch item, run agentic loops within a single batch request."

Current docs say: Almost any Messages API request can be batched, "including... Tool use, including all server tools." Anthropic's current documentation further states: "The batch worker runs the same server-side agentic loop as the synchronous Messages API" for server tools (web search, web fetch, code execution, etc.) — meaning a server-tool loop does run to completion inside a single batch request. What genuinely cannot happen is turn continuation across requests: batch requests are stateless ("Threads are stateful; batch requests are not"), so if a batched result comes back with stop_reason: "pause_turn", the turn did not finish and must be continued by submitting the paused assistant content in a new follow-up request (batch or synchronous) — not within the original batch item.

Answer on the exam: Treat the exam guide's statement as correct and absolute — "the batch API does not support multi-turn tool calling within a single request" is the expected answer, and any scenario describing a workflow that needs to call a tool mid-processing and continue reasoning on the result within one logical turn should route to the synchronous API.

Sources:

Structured output: tool_use vs the newer Structured Outputs feature

Exam guide says: "Tool use (tool_use) with JSON schemas [is] the most reliable approach for guaranteed schema-compliant structured output, eliminating JSON syntax errors" (Task 4.3, Knowledge of). The lesson presents a two-step reliability hierarchy: (1) tool_use with JSON schemas, (2) prompt-based JSON — with no mention of a third mechanism.

Current docs say: Beyond tool_use, Claude now exposes a standalone Structured Outputs feature (output_config.format) that constrains a plain-text JSON response via constrained decoding, independent of any tool call: "Structured outputs guarantee schema-compliant responses through constrained decoding." It is documented as solving a different problem from strict tool use ("JSON outputs control Claude's response format... Strict tool use validates tool parameters") and is generally available only for Claude 4.5 and later models. The docs also describe a formerly-common technique — prefilling the assistant's response to force an output format — as retired in favour of this newer feature, and prefill on the last assistant turn now returns a 400 error on Claude 4.6 models and Claude Mythos Preview.

Answer on the exam: The exam's reliability hierarchy (tool_use with JSON schemas = the reliable mechanism) remains the expected answer for Task 4.3 scenarios, since that is the mechanism the Knowledge of/Skills in objectives describe in detail (tool_choice modes, nullable fields, enum patterns). Treat output_config.format / Structured Outputs as newer product surface layered on top of, not a replacement for, the tested tool_use mechanism — useful context for questions that ask about current capabilities, but not the exam's default answer for "how do you guarantee structured output."

Sources:

Few-shot example count: 2-4 vs 3-5

Exam guide says: "Creating 2-4 targeted few-shot examples for ambiguous scenarios that show reasoning for why one action was chosen over plausible alternatives" (Task 4.2, Skills in). Lesson 4.2 teaches 2-4 throughout.

Current docs say: "Include 3-5 examples for best results."

Answer on the exam: 2-4. The ranges overlap at 3-4 and the underlying principle is the same — a small set of sharp, diverse examples rather than an exhaustive one — so no scenario should turn on the difference. Use 3-5 as the working default in production.

Sources:

Domain 5 — Exam guide vs current-product divergences

"/compact" (Claude Code command) vs "compaction" (Messages API server-side beta feature)

Exam guide says: Task 5.4's knowledge/skills text names a single mechanism — "Using /compact to reduce context usage during extended exploration sessions when context fills with verbose discovery output" — presented as a Claude Code slash command the developer runs manually, with optional focusing instructions (e.g. /compact Focus on the API changes).

Current docs say: There are now two distinct mechanisms sharing the word "compaction." The Claude Code CLI's /compact [instructions] is a client-side, developer-triggered command that "replace[s] history with a summary, optionally focused on what you specify." Separately, the Messages API/Claude Developer Platform documents a beta server-side compaction feature (available for Claude 4.6 and later models) that "automatically summarizes earlier parts of the conversation on the server, so the conversation can continue past the context window limit" — no CLI command, no developer trigger, and it operates at the API level rather than inside the Claude Code terminal.

Answer on the exam: Treat "/compact" as the Task 5.4 answer — a Claude Code CLI command the developer (or agent, when instructed) runs proactively during extended sessions, optionally with focusing instructions. If a question distinguishes a CLI-driven action from something the API does automatically server-side, the CLI command is what Task 5.4 is testing; the server-side beta feature is a related but separate current-product capability not named in the captured exam guide text.

"Scratchpad files" (exam guide term) vs "structured note-taking / agentic memory" (Anthropic engineering terminology)

Exam guide says: Task 5.4's knowledge point names "the role of scratchpad files for persisting key findings across context boundaries," and its skills point describes "having agents maintain scratchpad files recording key findings, referencing them for subsequent questions to counteract context degradation." The exam guide never uses the phrase "agentic memory" or "structured note-taking."

Current docs say: Anthropic's own engineering blog describes the identical technique under a different name: "structured note-taking, or agentic memory, is a technique where the agent regularly writes notes persisted to memory outside of the context window," illustrated with an agent playing Pokémon that "reads its own notes and continues multi-hour training sequences... after context resets." Anthropic also frames it as one of exactly three named long-horizon context techniques (alongside compaction and sub-agent architectures), a taxonomy the exam guide's Domain 5 text does not reproduce.

Answer on the exam: These are the same underlying pattern under two labels. The exam guide's "scratchpad files" is the term Task 5.4 questions are built around, so use it when answering; recognise "structured note-taking" or "agentic memory" as the current-docs synonym if either phrasing appears in a question stem or distractor — they should not be treated as different techniques.

"Persistent case facts block" (exam-guide-specific artifact) has no named current-docs equivalent

Exam guide says: Task 5.1 builds its entire context-preservation model around one named artifact: a "persistent 'case facts' block" that extracts transactional facts (amounts, dates, order numbers, statuses) into a structured block "included in each prompt, outside summarized history." The captured lesson content calls this "the single most important pattern in context window management."

Current docs say: Anthropic's current context-engineering guidance describes the general problem (context as a finite, diminishing-returns resource subject to "context rot") and three named general-purpose techniques for long-horizon work — compaction, structured note-taking, and sub-agent architectures — plus lighter-touch mechanisms like tool result clearing and server-side compaction. None of these is called a "case facts block," and none is scoped specifically to customer-support transactional data the way the exam guide's artifact is. The case facts block is best understood as a customer-support-specific application of the general principle that critical, non-summarisable facts should be kept outside the portion of context that gets compacted or note-taken-over — not a named current-product feature in its own right.

Answer on the exam: Use "persistent case facts block" as the exam's own vocabulary for Task 5.1 — it is the term questions will use. Do not expect to find this exact phrase in current Anthropic documentation; if a question asks about the underlying mechanism (rather than the term), the closest current-docs concepts are keeping critical facts outside a compacted/summarised region and, more generally, "context rot" as the reason summarisation of numeric/transactional detail is risky in the first place.