Claude Agent SDK Fundamentals for the CCDV-F Developer Exam

What the Claude Agent SDK is for

Once you have decided, using the workflow versus agent decision criteria, that a task genuinely wants an agent, the next question is how you build one without reinventing the plumbing. That is what the Claude Agent SDK exists to answer, and it is exactly what the Claude Certified Developer - Foundations (CCDV-F) exam expects you to understand at this knowledge point.

The SDK provides the agentic loop, tool dispatch, and session handling for you. In other words, the machinery that sends a message to the model, notices when the model wants to call a tool, runs that tool, feeds the result back, and keeps going until the task is done, all of that is already built. What is left for you is the part that actually shapes the agent's behaviour: writing good instructions and defining useful tools. The SDK's whole value proposition is moving your effort from the harness to the parts that matter.

The three parts of an agent definition

At this knowledge point the exam wants you to know what you actually declare when you define an agent with the SDK. An agent definition has three parts, and each answers a different question about the agent.

The system prompt is the agent's instructions: who it is, what it is trying to accomplish, and how it should behave. The tools are the set of actions it may call, each with a name, a description, and an input schema so the model knows when and how to invoke it. The permissions, sometimes expressed as allowed tools, are the guardrail on which of those actions the agent is actually granted. Together they answer three questions: what should the agent do, what can it do, and what is it allowed to do. Get those three right and the SDK handles the rest of the mechanics.

The same loop a harness would run

A useful way to demystify the SDK is to realise it is not doing anything exotic. It runs the same gather-context, take-action, verify-work loop that a hand-built harness would implement. First it gathers context, assembling the instructions, the conversation so far, and any tool results. Then it takes action, letting the model either respond or request a tool call that the SDK dispatches. Then it verifies the work by feeding the tool result back so the model can check progress and decide whether to continue. That cycle repeats until the model ends the turn.

This matters because it tells you what the SDK is and is not. It is a well-built implementation of the loop you would otherwise write by hand, which is why the next knowledge point on custom agent loops and deterministic hooks is a natural continuation: when the SDK's built-in loop does not give you the control you need, you build the same loop yourself. The SDK is the convenient default, not a black box that does something a harness cannot.

What the CCDV-F exam trips candidates on

The exam tests two specific misconceptions at this knowledge point, both drawn directly from the traps in the material.

The first is assuming the SDK removes the need to design good tool descriptions and instructions. It does not. The SDK runs the loop, but the model still decides what to do based on the instructions you wrote and the tool descriptions you supplied. A vague system prompt or a tool with an unclear description produces a poor agent no matter how solid the loop underneath is. The SDK automates the mechanics, not the design.

The second is confusing the Agent SDK with the raw Messages API. The Messages API is the underlying request-response call to the model. The Agent SDK builds the agentic loop on top of that API. Treating them as the same thing, or thinking the SDK is an alternative to the API rather than a layer over it, is exactly the kind of distinction the exam uses to separate candidates who understand the stack from those who have only heard the names.

Common misreadings to avoid

How this shows up on the exam

Domain 1 questions on this knowledge point ask you to identify what the SDK provides, what belongs in an agent definition, and where the SDK sits relative to the Messages API. The reliable answer names the loop, tool dispatch, and session handling as SDK-provided, names the system prompt, tools, and permissions as the parts you define, and places the SDK on top of the Messages API.

This knowledge point sits between the decision to build an agent and the deeper construction topics. Having chosen an agent via the workflow versus agent criteria, you use the SDK to define it, and when the SDK's defaults are not enough you move to custom loops and hooks or reach for a broader agentic abstraction framework. Knowing exactly what the SDK does, and what it deliberately leaves to you, is what makes those later choices coherent.