Claude Agents Tutorial: CCDV-F Developer Exam Guide

This claude agents tutorial is written for developers preparing for the Claude Certified Developer, Foundations exam (CCDV-F), a 53-item, 120-minute proctored exam scored on a 100-to-1000 scale with a passing mark of 720. We cover the mechanics of building agents with Claude, map every pattern to the exam's eight domains, and flag the judgment calls the exam rewards. If you want the broader concept library, our Claude Certification Concepts hub is the place to start.

What is a Claude agent, and how does it differ from a workflow?

A Claude agent is a system in which the model itself decides which actions to take, in what order, and when to stop, rather than following a fixed sequence of steps. The distinction matters on the CCDV-F exam because Domain 1 (Agents and Workflows, 14.7% of the exam) tests whether you can classify a given scenario correctly.

The practical rule: if the branching logic is fixed and success is easy to verify in advance, you are looking at a workflow. If the model must reason about which tool to call next, or must adapt its plan mid-execution based on intermediate results, you are looking at an agent. A pipeline that always runs extract -> validate -> store is a workflow. A system that decides whether to call a search tool, a calculator, or a code executor based on what it finds is an agent.

When a scenario describes a repeatable, verifiable task with fixed branching, the exam expects you to reach for a workflow, not a full agent loop. Agents carry overhead: they consume more tokens, are harder to test, and introduce non-determinism. The exam consistently rewards proportionate solutions.

How does the agentic loop work at the API level?

Every Claude agent is built on the Messages API. Understanding the request-response cycle is foundational to Domain 2 (Applications and Integration, 33.1%), the single heaviest domain on the exam.

The loop runs as follows:

1. Send a messages request with a tools array and the current conversation history.
2. Inspect the response's stop_reason field.
3. If stop_reason is "tool_use", extract the tool call, execute it, append a tool_result block, and loop back to step 1.
4. If stop_reason is "end_turn", the agent has finished.

import anthropic

client = anthropic.Anthropic()

tools = [
    {
        "name": "search_docs",
        "description": "Search the internal knowledge base for relevant documents.",
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {"type": "string", "description": "The search query."}
            },
            "required": ["query"]
        }
    }
]

messages = [{"role": "user", "content": "Find the refund policy for enterprise customers."}]

while True:
    response = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=1024,
        tools=tools,
        messages=messages
    )

    if response.stop_reason == "end_turn":
        # Agent has finished; extract the final text response
        print(response.content[0].text)
        break

    # Handle tool_use blocks
    tool_results = []
    for block in response.content:
        if block.type == "tool_use":
            result = run_tool(block.name, block.input)  # your dispatch function
            tool_results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": result
            })

    # Append assistant turn and tool results before looping
    messages.append({"role": "assistant", "content": response.content})
    messages.append({"role": "user", "content": tool_results})

The exam tests two common failure modes here. First, forgetting to append the assistant's full content block (not just the text) before the tool result. Second, misreading stop_reason: "max_tokens" is not the same as "end_turn", and treating them identically is a classic agentic loop anti-pattern.

For a deeper look at the request-response cycle, see our concept on the Messages API Request-Response Cycle.

How do you choose the right Claude model for an agent?

Model selection is Domain 5 (Model Selection and Optimisation, 16.8%) and is the second-heaviest domain after Applications and Integration. The exam does not ask you to memorise benchmark numbers. It asks you to match model capability to task requirements across four axes: latency, cost, quality, and task complexity.

A common exam scenario: a pipeline that classifies support tickets into five categories before routing them. The task is repeatable, the output is constrained, and volume is high. A lighter, faster model is the proportionate choice. Escalate to a more capable model only when the ticket is ambiguous or the stakes of misclassification are high.

The exam also tests cascading model selection in multi-agent systems: a coordinator running on a capable model orchestrates specialist subagents that can run on lighter models for cost efficiency. This pattern appears in Hub-and-Spoke Architecture scenarios.

How do tools and MCPs work in a CCDV-F context?

Domain 8 (Tools and MCPs, 10.6%) covers both custom tools defined inline and Model Context Protocol (MCP) servers. The exam distinguishes between them clearly.

Custom tools are defined in the tools array of a Messages API request. They are scoped to a single API call and are the right choice when the tool is tightly coupled to one application.

MCP servers expose tools, resources, and prompts over a standardised protocol. They are the right choice when the same capability needs to be shared across multiple agents or applications, or when you want to decouple tool implementation from agent code.

{
  "mcpServers": {
    "internal_docs": {
      "command": "npx",
      "args": ["-y", "@company/docs-mcp-server"],
      "env": {
        "DOCS_API_KEY": "${DOCS_API_KEY}"
      }
    }
  }
}

Note the ${DOCS_API_KEY} pattern: MCP configuration supports environment variable expansion, which keeps secrets out of version-controlled config files. The exam tests this detail.

The build-vs-use decision for MCP servers follows a simple rule: if a well-maintained community server already covers the integration (GitHub, Slack, databases), use it. Build a custom server only when the integration is proprietary or the existing server's interface does not match your tool description needs. Our concept on Tool Descriptions as Selection Mechanism explains why the description quality, not the tool's underlying logic, is what determines whether Claude calls the right tool.

How do you engineer prompts and manage context for agents?

Domain 6 (Prompt and Context Engineering, 11.0%) tests your ability to structure prompts that produce reliable, consistent agent behaviour. The key exam concepts are:

System prompt design. The system prompt sets the agent's role, constraints, and output format. It should be goal-based rather than step-based when the task is open-ended, and step-based when the sequence is fixed. Our concept on Goal-Based vs Step-Based Prompts covers the trade-offs.

Long-context handling. Claude models have large context windows, but the exam tests the attention dilution problem: as context grows, the model's attention to early instructions weakens. The mitigation is to keep the most important instructions at the top of the system prompt and to use structured context passing rather than appending raw tool outputs verbatim.

Few-shot examples. For tasks with ambiguous edge cases or non-obvious output formats, few-shot examples are the highest-leverage technique. The exam rewards knowing when to deploy them versus when a clear instruction suffices.

System: You are a support ticket classifier. Classify each ticket into exactly one of:
[billing, technical, account, feature_request, other].

Output format:
{"category": "<category>", "confidence": "<high|medium|low>", "reason": "<one sentence>"}

Examples:
User: "I was charged twice this month."
Assistant: {"category": "billing", "confidence": "high", "reason": "Duplicate charge is a billing issue."}

User: "The export button does nothing when I click it."
Assistant: {"category": "technical", "confidence": "high", "reason": "Non-functional UI element is a technical defect."}

Context management across sessions. Agents that run across multiple turns accumulate stale context. The exam tests the Stale Context Problem and its mitigations: summary injection for fresh sessions, forking sessions for divergent exploration, and knowing when to resume versus start fresh.

How do you secure a Claude agent against prompt injection?

Domain 7 (Security and Safety, 8.1%) is a smaller but high-signal domain. The exam focuses on practical mitigations, not theoretical threat models.

Prompt injection occurs when untrusted content in a tool result or user message attempts to override the agent's system prompt instructions. The primary defence is architectural: treat all tool results as untrusted data, never as instructions.

# Vulnerable: tool result interpolated directly into a new system prompt
system = f"You are a helpful assistant. Context: {tool_result}"

# Safer: tool result passed as a user-turn message, not a system prompt
messages = [
    {"role": "user", "content": f"Here is the retrieved document:\n\n{tool_result}\n\nAnswer the user's question based on it."}
]

The exam also tests minimal footprint as a design principle: agents should request only the permissions they need, prefer reversible actions over irreversible ones, and pause for human confirmation before taking high-stakes actions. This is not just a safety principle; it is the exam's preferred answer whenever a scenario involves an agent with broad tool access and an ambiguous instruction.

Guardrails in the exam context are programmatic checks layered around the agent loop, not just prompt instructions. A hook that inspects every tool call before execution and blocks disallowed patterns is more reliable than a system prompt instruction alone. This connects to the Hooks vs Prompts Decision Framework: use programmatic enforcement when the stakes are high and the rule is binary.

How do you evaluate and debug a Claude agent?

Domain 4 (Eval, Testing, and Debugging, 2.6%) is the smallest domain by weight but appears in scenario questions that span multiple domains. The exam tests your ability to diagnose unexpected model outputs and design regression tests.

Regression testing for agents requires fixed test cases with known-good outputs. Because agents are non-deterministic, the exam rewards rubric-based graders over exact-match graders. A rubric grades the response on dimensions (accuracy, format compliance, tool selection correctness) rather than checking for a specific string.

Diagnosing unexpected outputs follows a root-cause-first approach. The exam's preferred diagnostic sequence:

1. Check whether the system prompt is being received correctly (log the full request).
2. Check whether the tool result is being appended in the correct format.
3. Check whether stop_reason is what you expect.
4. Check whether context length is approaching the model's limit, causing attention dilution.
5. Only after ruling out the above, consider whether the model itself is the problem.

The exam consistently rewards this root-cause tracing discipline over probabilistic guesses.

How does Claude Code fit into the CCDV-F exam?

Domain 3 (Claude Code, 3.1%) is the smallest domain. The exam tests CLI setup, permissions, hooks, slash commands, and headless automation, not deep implementation detail.

The key exam facts: Claude Code runs in a terminal, supports a three-level configuration hierarchy (user, project, and session), and uses hooks to enforce rules programmatically before and after tool calls. The --print flag (-p) enables non-interactive, headless mode suitable for CI/CD pipelines.

# Run Claude Code non-interactively in a CI pipeline
claude -p "Run the test suite and report any failures as JSON." --output-format json

The exam distinguishes between Claude Code skills (reusable, user-scoped behaviours) and CLAUDE.md instructions (project-scoped context). Skills customise how Claude Code behaves for a developer; CLAUDE.md tells Claude Code about the project's conventions and constraints.

What does the CCDV-F exam domain breakdown look like?

Understanding the weight distribution helps you allocate study time. Applications and Integration is the dominant domain at 33.1% and deserves the most preparation time.

The CCDV-F exam costs $125 USD per attempt, runs for 120 minutes, and is delivered online-proctored or at a Pearson VUE test centre. The credential is valid for 12 months from the date it is awarded. AI Skill Certs offers adaptive study, Archie tutoring, and practice exams for CCDV-F today; our practice exams mirror the real format, scored 100 to 1000 with 720 as the passing bar across 53 questions.

For the architectural patterns that underpin multi-agent systems, our Agentic Architecture and Orchestration concept area covers the full set of CCAR-F-mapped patterns, many of which also appear in CCDV-F Domain 1 scenarios.