Study Material
Deep dive into all five CCA-F exam domains. Expand each domain to review key concepts, common anti-patterns, exam traps, and curated study resources.
D1 · 27%D2 · 18%D3 · 20%D4 · 20%D5 · 15%
Design and implement agentic systems using Claude, including orchestration patterns, subagent management, and programmatic enforcement of agent behavior.
Key Concepts
| Concept | Detail |
|---|---|
stop_reason | The stop_reason field in Claude API responses indicates why the model stopped generating. Key values include "end_turn" (natural completion), "tool_use" (model wants to call a tool), "max_tokens" (hit the limit), and "stop_sequence" (matched a stop sequence). Agentic loops check for "end_turn" to know when to stop iterating. |
Task tool & subagent context | The Task tool spawns a subagent with its own context window and tool access. The parent agent receives only the subagent's final result, keeping the parent context clean. Subagents do NOT automatically inherit the parent's full conversation history. |
PostToolUse hooks | PostToolUse hooks run after every tool call in Claude Code, enabling programmatic enforcement such as auto-running linters, blocking dangerous commands, or logging tool usage. They operate outside the model's context and cannot be bypassed by the model. |
Parallel subagents | Multiple subagents can be launched in parallel for independent tasks (e.g., researching different topics simultaneously). Each gets its own context window. Results are gathered and synthesized by the orchestrator. |
Programmatic enforcement | Critical guardrails should be enforced programmatically (code-level checks, hooks, allowlists) rather than relying on prompt instructions alone. Prompts can be ignored or misinterpreted; code cannot. |
fork_session | fork_session creates a branch of the current conversation for exploring alternative paths without polluting the main context. Useful for speculative execution or A/B exploration in agentic workflows. |
Agentic loop pattern | The core agentic loop: send message to Claude, check stop_reason, if "tool_use" then execute the tool and send result back, repeat until "end_turn". This while-loop pattern is the foundation of all agentic systems with Claude. |
Anti-Patterns to Avoid
- Relying solely on prompt instructions for safety-critical guardrails
- Passing entire parent context to subagents instead of scoped instructions
- Not checking stop_reason in the agentic loop
- Using a single giant agent instead of decomposing into subagents
- Ignoring tool errors and continuing the loop without handling them
Exam Traps
- 1.stop_reason "tool_use" means the model wants YOU to execute the tool, not that it already executed it
- 2.Subagents do NOT inherit the parent conversation — they start fresh with only what you pass them
- 3.PostToolUse hooks are programmatic, not prompt-based — they cannot be bypassed by the model
- 4.The agentic loop continues until stop_reason is "end_turn", not "stop_sequence"
Study Resources
Design effective tool schemas, integrate with the Model Context Protocol (MCP), and apply best practices for tool descriptions, error handling, and tool count management.
Key Concepts
| Concept | Detail |
|---|---|
Tool descriptions | Tool descriptions are critical for Claude to understand when and how to use a tool. They should clearly state what the tool does, when to use it, what the parameters mean, and what it returns. Poor descriptions lead to misuse or non-use of tools. |
isError flag | When returning tool results, set isError: true to signal that the tool call failed. This tells Claude the result is an error message, not successful output. Claude will then handle the error appropriately rather than treating error text as valid data. |
Tool count sweet spot (4-5) | Research shows Claude performs best with 4-5 tools available. Too many tools (10+) degrade selection accuracy. If you need more, use subagents with scoped tool sets or a tool-router pattern. |
tool_choice modes | tool_choice controls how Claude selects tools: "auto" (model decides), "any" (must use some tool), "tool" (must use a specific named tool), and "none" (no tools). Use "tool" to force a specific tool call when you know which tool is needed. |
.mcp.json configuration | The .mcp.json file in a project root configures MCP servers for Claude Code. It specifies server commands, arguments, and environment variables. This file can be committed to version control for team-wide MCP server sharing. |
MCP resources | MCP resources are read-only data sources (files, database records, API responses) that servers expose to clients. Unlike tools (which perform actions), resources provide context. They use URI-based addressing. |
Anti-Patterns to Avoid
- Vague or missing tool descriptions
- Not using isError flag for failed tool calls
- Overloading the model with 10+ tools at once
- Using tool_choice "any" when a specific tool is needed
- Putting sensitive credentials directly in .mcp.json instead of using environment variables
Exam Traps
- 1.isError is a field on the tool RESULT, not on the tool definition
- 2.tool_choice "any" means the model MUST call some tool — it does not mean "auto"
- 3.MCP resources are READ-ONLY — they cannot modify data
- 4.The 4-5 tool sweet spot is per-agent, not per-system — subagents can each have their own tools
Study Resources
Configure and use Claude Code effectively, including CLAUDE.md files, custom commands, rules, hooks, and workflow automation with the -p flag and plan mode.
Key Concepts
| Concept | Detail |
|---|---|
CLAUDE.md hierarchy | CLAUDE.md files provide persistent instructions to Claude Code. They are loaded hierarchically: ~/.claude/CLAUDE.md (user-global), project root CLAUDE.md (project-wide), and subdirectory CLAUDE.md files (scoped to that directory). More specific files override more general ones. |
.claude/rules/ | The .claude/rules/ directory contains rule files that are conditionally applied based on glob patterns in their filenames. For example, "test-*.md" rules only apply when working with test files. This enables context-specific instructions. |
.claude/commands/ | Custom slash commands are defined as markdown files in .claude/commands/. The filename becomes the command name (e.g., deploy.md becomes /deploy). They can include $ARGUMENTS placeholder for user input. Team commands go in .claude/commands/, personal in ~/.claude/commands/. |
context:fork | The context:fork directive in Claude Code creates a new conversation branch, preserving the current context while allowing independent exploration. Useful for trying alternative approaches without losing the current state. |
-p flag (headless/pipe mode) | The -p flag runs Claude Code in non-interactive (headless) mode, reading from stdin and writing to stdout. Essential for CI/CD pipelines, scripting, and automation. Combined with --output-format json for structured output. |
Plan mode | Plan mode (Shift+Tab to toggle) makes Claude analyze and plan without making changes. Claude will outline what it would do without executing. Useful for reviewing approach before committing to changes. Can also be set via --plan flag. |
Hook configuration | Hooks are configured in .claude/settings.json under the "hooks" key. They support PreToolUse, PostToolUse, and Notification events. Each hook specifies a matcher (tool name pattern) and a command to run. Exit code 2 blocks the tool call. |
Anti-Patterns to Avoid
- Putting all instructions in a single massive CLAUDE.md instead of using hierarchy
- Not using .claude/rules/ for context-specific guidelines
- Hardcoding values in custom commands instead of using $ARGUMENTS
- Running Claude Code interactively in CI instead of using -p flag
- Skipping plan mode for large refactors and going straight to execution
Exam Traps
- 1.CLAUDE.md in subdirectories only applies when Claude is working in that directory
- 2..claude/commands/ is for team commands (committed), ~/.claude/commands/ is for personal commands
- 3.Hook exit code 2 blocks the tool call; exit code 0 allows it; exit code 1 is a hook error
- 4.-p flag output goes to stdout — use --output-format json for programmatic parsing
Study Resources
Apply advanced prompt engineering techniques and generate structured outputs using tool_use with JSON schemas, handling optional fields, batching, and understanding model limitations.
Key Concepts
| Concept | Detail |
|---|---|
Explicit criteria in prompts | Prompts should specify explicit evaluation criteria, grading rubrics, or decision frameworks. Vague instructions like "write good code" produce inconsistent results. Instead, specify exactly what "good" means: "follow SOLID principles, include error handling, add JSDoc comments." |
Few-shot examples | Providing 2-3 input/output examples in the prompt dramatically improves consistency and accuracy. Examples should cover typical cases and edge cases. Place them after instructions but before the actual input. |
tool_use + JSON schema for structured output | The most reliable way to get structured output from Claude is to define a tool with a JSON schema and use tool_choice to force Claude to call it. The tool doesn't need to do anything — you just extract the structured arguments from the tool call. |
Optional/nullable fields | In tool schemas, mark fields as optional or nullable when they might not apply. This prevents Claude from hallucinating values to fill required fields. Use JSON Schema's "required" array to control which fields are mandatory. |
Batch API | The Anthropic Batch API processes up to 10,000 requests asynchronously at 50% cost reduction. Results are available within 24 hours. Ideal for bulk classification, data extraction, or evaluation tasks that don't need real-time responses. |
Self-review limitation | Claude has a well-documented bias toward rating its own output favorably. When using Claude to evaluate Claude-generated content, use a separate evaluation prompt with explicit rubrics, or use a different model instance. Never trust self-assessment without structured criteria. |
Anti-Patterns to Avoid
- Using unstructured text output when structured data is needed
- Asking Claude to self-evaluate without explicit rubrics
- Making all schema fields required, causing hallucinated values
- Sending thousands of synchronous API calls instead of using Batch API
- Not providing examples when output format consistency matters
Exam Traps
- 1.tool_use for structured output works even if the "tool" never actually executes — you just read the arguments
- 2.Batch API has 50% cost reduction but up to 24-hour latency — not suitable for real-time
- 3.Few-shot examples go in the user message, not the system prompt (for best results)
- 4.Claude cannot reliably self-assess quality without external criteria
Study Resources
Manage context windows effectively, handle reliability challenges including summarization risks, position effects, and error propagation in production Claude deployments.
Key Concepts
| Concept | Detail |
|---|---|
Progressive summarization risk | When conversations are summarized to fit the context window, critical details can be lost. Each summarization pass loses fidelity. Important instructions, constraints, or earlier decisions may vanish. Mitigate by keeping critical info in system prompts or CLAUDE.md. |
Lost in the middle | Research shows LLMs pay more attention to information at the beginning and end of the context, with reduced attention to the middle. Place critical instructions and information at the start or end of prompts, not buried in the middle. |
Tool result bloat | Large tool results (e.g., full file contents, verbose API responses) consume context rapidly. Truncate, filter, or summarize tool results before returning them. Return only what the model needs, not everything the tool produced. |
Escalation triggers | Define clear conditions under which an agent should escalate to a human or higher-level system instead of continuing autonomously. Examples: confidence below threshold, error count exceeded, sensitive operation detected. Prevents runaway agents. |
Self-reported confidence | Ask Claude to rate its confidence (e.g., 1-5 scale) alongside answers. While not perfectly calibrated, it provides a useful signal. Low-confidence responses can trigger escalation, additional verification, or human review. |
Structured error propagation | In multi-agent systems, errors should propagate with structured metadata (error type, severity, source agent, attempted action). This enables the orchestrator to make informed decisions about retry, fallback, or escalation rather than failing silently. |
Anti-Patterns to Avoid
- Allowing unlimited context growth without summarization strategy
- Placing critical instructions only in the middle of long prompts
- Returning raw, untruncated tool results to the model
- No escalation path — agent keeps retrying indefinitely
- Treating self-reported confidence as ground truth
- Swallowing errors silently in multi-agent pipelines
Exam Traps
- 1.Progressive summarization is a RISK, not a best practice — it loses information
- 2."Lost in the middle" means put important info at start AND end, not just the start
- 3.Self-reported confidence is a SIGNAL, not a guarantee — combine with other checks
- 4.Tool result bloat affects the NEXT turn's available context, not the current response
Study Resources
Click any domain header to expand or collapse its study content.