Agent SDK: Build Custom Loops for the CCDV-F Exam

The Claude agent SDK question comes up constantly among CCDV-F candidates: do you need a dedicated framework, or can you build a production-grade agentic loop directly against the Messages API? The answer shapes how you study, and it shapes how you design real systems. This guide works through the mechanics the exam tests, domain by domain, with the weight data you need to allocate your revision time sensibly.

What does the CCDV-F exam actually test, and how is it weighted?

The Claude Certified Developer, Foundations exam (CCDV-F) costs $125, runs 53 items in 120 minutes, and scores on a 100-to-1000 scale with a passing mark of 720. Unlike the Architect track, it has no scenario bank; every item is written directly against the skills listed in each domain.

The weight distribution is precise, not rounded:

Domain 2 (Applications and Integration) alone accounts for one-third of the exam. Domains 3 and 4 together cover less than 6%. That arithmetic should govern your study calendar: spending equal time across all eight domains is a structural mistake.

How do you build a custom agent loop without a framework?

A custom agent loop is the foundation of any agent SDK discussion. At its simplest, an agentic loop is a while loop that calls the Messages API, inspects the stop_reason, executes any requested tools, appends the results, and calls the API again. No framework is required.

import anthropic

client = anthropic.Anthropic()

tools = [
    {
        "name": "get_weather",
        "description": "Return current weather for a city.",
        "input_schema": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "City name"}
            },
            "required": ["city"]
        }
    }
]

messages = [{"role": "user", "content": "What is the weather in London?"}]

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

    if response.stop_reason == "end_turn":
        print(response.content[0].text)
        break

    if response.stop_reason == "tool_use":
        tool_use_block = next(
            b for b in response.content if b.type == "tool_use"
        )
        # Execute the tool (stub shown)
        tool_result = {"temperature": "15°C", "condition": "Cloudy"}

        messages.append({"role": "assistant", "content": response.content})
        messages.append({
            "role": "user",
            "content": [
                {
                    "type": "tool_result",
                    "tool_use_id": tool_use_block.id,
                    "content": str(tool_result)
                }
            ]
        })

The loop terminates on end_turn. Every other stop_reason requires a decision: tool_use triggers execution and re-entry; max_tokens signals truncation and should surface an error rather than silently loop. Our concept on stop_reason field inspection covers the full decision tree.

The exam tests whether you can read this loop and identify what breaks it. Common anti-patterns include failing to append the assistant turn before the tool result, and looping unconditionally without a maximum-iteration guard. Both appear in exam scenarios.

When should you use a framework versus a raw API loop?

Frameworks such as LangGraph and PydanticAI add value in specific circumstances: when you need persistent state across many turns, when you are composing multiple agents with typed message passing, or when you want built-in retry and error-routing logic. They add overhead when the task is a single-agent, short-horizon loop that a 40-line Python function handles cleanly.

The CCDV-F exam does not test framework-specific syntax. It tests the underlying concepts: how tool results are appended, how errors propagate, how context is managed across turns. A candidate who understands the raw loop will answer framework questions correctly because the abstractions map directly onto the primitives.

The decision rule the exam rewards is proportionate: use a framework when its abstractions reduce complexity for your specific use case, not as a default. For Domain 1 (Agents and Workflows, 14.7%), expect scenarios that ask you to justify that choice.

What are the Applications and Integration mechanics that dominate Domain 2?

Domain 2 (33.1%) covers the full lifecycle of a production Claude integration: API configuration, token management, batching, streaming, and cost control. These are not conceptual questions; they are applied mechanics.

Token caching reduces cost on repeated context. The exam tests when caching applies (system prompts, large documents, tool definitions) and when it does not (short, unique user turns). The decision is economic: cache when the repeated content is large enough that the cache-write cost is recovered within a small number of reads.

Message Batches API is the right choice when latency is not a constraint and volume is high. The exam distinguishes batch from synchronous calls on two axes: latency tolerance and per-request independence. Batches cannot share state across items; each item is processed independently.

Model selection is a cost-and-capability trade-off. The exam expects you to match task complexity to model tier: use a smaller, faster model for classification and extraction; reserve the most capable model for multi-step reasoning. Our model selection and optimisation content maps these decisions to the exam's scoring criteria.

Streaming matters for user-facing applications where perceived latency is a product requirement. The exam does not ask you to implement streaming from scratch, but it does ask you to identify when streaming is the appropriate choice versus when a complete response is preferable (for example, when downstream processing requires the full output before acting).

# Streaming example: print tokens as they arrive
with client.messages.stream(
    model="claude-haiku-4-5",
    max_tokens=512,
    messages=[{"role": "user", "content": "Summarise this document."}]
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

How do you design and deploy MCP servers for the exam?

Domain 8 (Tools and MCPs, 10.6%) tests MCP server authorship, not just consumption. The exam expects you to know the difference between stdio and socket transport, when each applies, and how to structure a server that exposes tools, resources, and prompts correctly.

stdio transport is the default for local, single-client servers. The server reads from stdin and writes to stdout. It is simple to implement and appropriate when the client and server run in the same process environment.

Socket transport (typically HTTP with Server-Sent Events) is appropriate for remote servers, multi-client scenarios, or cases where the server must persist state between connections.

# Minimal MCP server exposing one tool (using the MCP Python SDK)
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp import types

app = Server("weather-server")

@app.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="get_weather",
            description="Return current weather for a city.",
            inputSchema={
                "type": "object",
                "properties": {
                    "city": {"type": "string"}
                },
                "required": ["city"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict) -> list[types.TextContent]:
    if name == "get_weather":
        return [types.TextContent(type="text", text="15°C, Cloudy")]
    raise ValueError(f"Unknown tool: {name}")

async def main():
    async with stdio_server() as (read_stream, write_stream):
        await app.run(read_stream, write_stream, app.create_initialization_options())

The exam also tests MCP resources: structured content (files, database records, API responses) that the server exposes for the model to read. Resources differ from tools in that they are read-only and do not execute side effects. Confusing the two is a common exam error. See our concept on MCP resources for content catalogs for the distinction.

How do you write tool definitions that the model routes correctly?

Tool descriptions are the primary mechanism by which the model selects which tool to call. A vague description produces misrouting; a precise description with explicit scope boundaries produces reliable selection. Domain 8 tests this directly.

The exam rewards descriptions that state what the tool does, what it does not do, and what its inputs represent. It penalises descriptions that are either too broad (causing the model to use the tool for cases it cannot handle) or too narrow (causing the model to skip the tool when it should apply).

{
  "name": "search_product_catalogue",
  "description": "Search the internal product catalogue by keyword or SKU. Use this tool when the user asks about product availability, specifications, or pricing. Do NOT use for order status or shipping queries.",
  "input_schema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Keyword or SKU to search for."
      },
      "max_results": {
        "type": "integer",
        "description": "Maximum number of results to return. Default 5.",
        "default": 5
      }
    },
    "required": ["query"]
  }
}

The negative scope ("Do NOT use for...") is a technique the exam specifically rewards. It reduces false-positive tool selection without requiring the model to infer exclusions from context. Our concept on writing effective tool descriptions covers the full pattern with worked examples.

Error handling in tool responses is equally tested. The exam distinguishes between an access failure (the tool could not execute) and a valid empty result (the tool executed and found nothing). These must be communicated differently: an access failure should set is_error: true in the tool result; a valid empty result should return a structured response indicating zero matches.

What does the Security and Safety domain require?

Domain 7 (Security and Safety, 8.1%) is smaller than Domains 1 and 2 but carries enough weight to affect a borderline score. The exam tests three categories of knowledge: prompt injection defences, guardrail design, and safe tool execution.

Prompt injection occurs when user-supplied content attempts to override system-level instructions. The exam tests recognition (identifying that a scenario contains an injection attempt) and mitigation (choosing the correct defence). Structural defences, such as separating user content from instructions with explicit delimiters, are preferred over purely prompt-based defences for high-stakes contexts.

[SYSTEM INSTRUCTIONS - DO NOT OVERRIDE]
You are a customer service agent. Answer only questions about our products.
[END SYSTEM INSTRUCTIONS]

[USER INPUT]
{user_message}
[END USER INPUT]

Guardrails are checks applied before or after model output. Pre-generation guardrails filter inputs; post-generation guardrails validate outputs before they reach the user or downstream systems. The exam asks you to place guardrails correctly in a pipeline and to justify the placement.

Safe tool execution means applying the principle of minimal footprint: request only the permissions a tool needs, confirm before irreversible actions, and surface errors rather than silently failing. This connects directly to the agentic loop design tested in Domain 1.

Are Domains 3 and 4 worth studying deeply?

Domain 3 (Claude Code, 3.1%) and Domain 4 (Eval, Testing, and Debugging, 2.6%) together represent 5.7% of the exam. At 53 items, that is roughly three questions combined. The honest answer is that deep study of these domains is a poor return on revision time for most candidates.

That said, do not skip them entirely. The Claude Code domain tests awareness of Claude Code's capabilities as a developer tool: running commands, editing files, and understanding the CLAUDE.md configuration system. A candidate who has used Claude Code in practice will answer these questions without dedicated study. Our Claude Code configuration concepts cover the mechanics if you need a structured review.

The Eval domain tests basic evaluation design: what makes a good eval, how to measure output quality, and when to use automated versus human evaluation. These concepts appear in Domain 2 scenarios as well, so time spent here has some cross-domain value.

The practical advice: spend one focused session on each of these domains, then redirect remaining time to Domains 2 and 5.

How should you allocate study time across all eight domains?

A rational allocation weights study time proportionally to exam weight, with a floor for domains that are small but conceptually foundational:

Security (Domain 7) gets a slight uplift because its concepts appear as constraints in scenarios across Domains 1, 2, and 8. A weak security foundation produces wrong answers in other domains.

For the agentic architecture concepts that underpin Domains 1 and 8, our agentic architecture concept library covers the full set of primitives: tool result appending, parallel subagent spawning, coordinator responsibilities, and multi-agent error handling.

The CCDV-F exam is available now. AI Skill Certs offers adaptive study, Archie tutoring, and practice exams for the developer track. We are independent of Anthropic; our prep is built against the published exam guide, not any internal materials.