The Claude Agent SDK is Anthropic's library for building agents in code, exposing the same agent loop, built-in tools, context management, subagents, hooks, and Model Context Protocol client that run inside Claude Code, so a team can embed that agent harness in its own application instead of driving it through the terminal.

How it works

The SDK packages the agent loop, the cycle of gather context, take an action, verify the result, and repeat, as something a program invokes rather than a command line a person runs. It ships the same building blocks the coding tool uses: built-in tools for reading and editing files, running commands, searching code, and fetching from the web, context management so a long task survives past a single window, subagents that run scoped work in isolated context, hooks that intercept actions at defined points, and a client for connecting to external systems over the Model Context Protocol. A program configures those pieces, sets the permissions and the instructions, hands the agent a task, and receives the structured result. Because it is the same harness that runs in Claude Code, an agent built on the SDK inherits a loop and a tool set already exercised in the coding tool, applied to a domain that need not be code at all.

Why it matters

Building a production agent that needs a tool-using loop means building a harness around the model, the context management, the tool execution, and the error handling, and that scaffolding is a large share of the work and the part most often done badly. Starting from the SDK means starting from an agent loop that already exists rather than reinventing it, which is the difference between configuring a foundation and writing one. The trade-off is dependency and fit, since an application built on the SDK inherits its model of how an agent should work, a gift when that model matches the task and a constraint when a team needs a fundamentally different control flow. It is also a higher-effort surface than the terminal tool, because reaching for the SDK means writing and maintaining code, so the reason to adopt it is needing an agent embedded in a product or a pipeline, not preferring it for interactive work the tool already does, and not a bounded task that a direct API call or a deterministic workflow handles without an open-ended loop. The SDK supplies the loop and the tools; it does not supply the judgment about what the agent should be allowed to do, which stays a design decision the builder owns.

In practice

A team wants an agent that triages incoming tickets inside their own application rather than in a terminal. Instead of writing the loop that calls the model, runs the lookups, manages the growing context, and retries on failure, they build on the SDK: they define the tools the agent may call, set its permissions and its instructions, and let the harness run the gather-act-verify loop. The agent lives inside their product, but the machinery underneath it is the same that runs the coding tool, so the team spent its effort on the triage logic instead of on rebuilding the agent runtime.

Practical considerations

The SDK was renamed from the Claude Code SDK, a signal that the same harness is meant for agents well beyond coding, so older references to the Claude Code SDK and the current Agent SDK name the same foundation. It ships in more than one language binding, so the language follows the application rather than the agent. Because it exposes the same extension points as the coding tool, the design discipline carries over: permissions can be scoped per agent and per tool rather than left at the broad default, and hooks intercept actions at defined lifecycle points to validate, block, or transform them. Those controls hold only the boundaries the builder defines, so they pair with a sandbox and least-privilege design rather than replacing it. Context management is built in but not free of judgment, since what to compact and what to carry is still a decision the builder tunes to the task. Running an agent programmatically also means owning its operation, the observability, the cost ceilings, and the failure handling that an interactive session would otherwise surface to a watching human, so the production burden moves from the model to the system built around it.

Related standards and prior art

Defined by Ready Solutions AI