The instinct most teams have when they see Claude Code is to ask Anthropic to build the same thing for their vertical. Claude Code for legal contracts. Claude Code for financial close. Claude Code for clinical trial protocols. The instinct is right — the architectural pattern absolutely generalizes — but the request is misdirected. The interesting answer is that you don't have to ask. The Claude Agent SDK exists so you can build it yourself.

For most of the last two years, building a serious agent meant standing up an orchestration layer, a tool-use loop, a permission model, a session manager, a context compactor, and a dozen other primitives that were neither novel nor differentiating. Each team rebuilt the same architecture, found the same edge cases, and ended up with something that looked vaguely like Claude Code with worse ergonomics. The SDK closes that gap by exposing the same primitives Anthropic uses to build Claude Code itself.

This is the kind of platform shift that's easy to miss while it's happening. The toolkit doesn't look dramatic. The effects on what gets built in the next twelve months are.

What the SDK Actually Gives You

The SDK is best understood as the agent-runtime layer that powers Claude Code, factored out and made available to anyone building their own agent on top of Claude.

Session and context management. The SDK handles the loop of sending messages to Claude, managing tool calls, keeping track of state across turns, and compacting context when it grows past the window. These are the boring problems that consume most of the engineering hours in a from-scratch agent. The SDK handles them with the same logic Claude Code uses, including the auto-compaction behavior that lets a session run for hours without losing the thread.

Tool definition and execution. Tools are plain functions — defined once, registered with the runtime, and invoked by the model as needed. The SDK manages the schema, the validation, the error handling, and the conversation back to the model when a tool call fails. You write the tool; the SDK makes it callable in a way the model can reason about.

Permission and policy. The same permission system that lets Claude Code prompt before sensitive actions is available through the SDK. You can register policies that auto-approve certain tools, require confirmation for others, or block specific patterns entirely. For a vertical agent, this is where domain rules live — the legal agent's policy that contract templates can't be modified without a senior review, the finance agent's policy that journal entries to closed periods need explicit approval.

Hooks and lifecycle events. Everything the Claude Code hook system can do is available to SDK consumers. Pre-tool, post-tool, on-stop, on-notification — the same hooks, the same JSON-over-stdin protocol. A vertical agent can plug enforcement, side effects, and observability into the same places.

Subagent orchestration. The SDK supports defining and spawning subagents — specialized agents with their own tool sets and prompts that the main agent can delegate to. A legal agent can spawn a contract-clause-analysis subagent without the main agent having to load every clause-analysis tool itself. This is the same primitive that makes Claude Code's Plan and Explore agents work.

Why Vertical Agents Beat Horizontal Ones

For a stretch in 2024, the dominant narrative was that one giant horizontal agent — usable for anything — would eventually outcompete every vertical agent on every task. That narrative has aged poorly. The reality has been the opposite: the agents that perform best in any given domain are the ones that have been deeply specialized for it.

Tools are domain knowledge encoded as actions. The legal agent has tools for clause extraction, redline generation, term-sheet comparison, and statute lookup. The finance agent has tools for journal entries, ledger reconciliation, variance analysis, and consolidation. These tool sets aren't interchangeable, and they shouldn't be in the same agent. An agent with too many tools spends its context budget reasoning about which tool to use; an agent with the right tools spends it doing the work.

System prompts encode domain expectations. The legal agent assumes you're working with contracts and statutes. The finance agent assumes you're working with accounts and periods. These assumptions let the agent skip the framing every prompt would otherwise need and get to the work. A horizontal agent has to be told the context every time; a vertical agent already knows.

Policies encode domain risk. What's a critical operation in a finance agent (any write to closed-period ledger) is a routine operation in a marketing-copy agent (a draft revision). Bolting the strictest policy onto every operation slows the wrong agent down; not bolting any policy on lets the wrong agent fail catastrophically. The SDK lets you define risk surfaces per agent, which is the only way this scales.

Where the SDK Lands First

A few domains are obvious early movers because the leverage is clear and the surface is bounded.

Engineering-adjacent work. DevOps agents that manage infrastructure changes, SRE agents that triage incidents, security agents that respond to alerts. These domains already have the toolchain and the audit infrastructure. The SDK lets a team build a domain-shaped agent in weeks instead of standing up a full agent platform.

Knowledge work with structured artifacts. Legal (contracts, briefs), accounting (entries, reports), regulatory (filings, attestations), clinical (protocols, study reports). These domains have well-defined artifacts, well-defined edits, and well-defined approval chains. The SDK's permission and hook layers map cleanly onto these chains.

Operational workflows. Customer-success agents that manage account renewals end-to-end, ops agents that handle vendor onboarding, support agents that resolve tickets across multiple systems. These are domains where the value of an agent is in the integration surface — and the SDK lets the integration logic live as registered tools rather than as a fragile orchestration layer.

Internal tooling at enterprise scale. Most large organizations have dozens of bespoke internal tools that automate parts of a workflow. The SDK makes it tractable to wrap these tools as agent actions and put a Claude-powered agent at the front, replacing the click-through interfaces that have aged badly.

How to Build an Agent on the SDK Without Reinventing the Loop

Teams that succeed with the SDK tend to share a pattern. Teams that fail tend to make the same handful of mistakes.

Start with the tool inventory, not the prompt. The agent's capability is bounded by the tools it has. Map the workflow you want the agent to handle, identify every action that needs to happen, and define those as tools first. The prompt that orchestrates them comes after — and is much smaller than teams expect when the tools are right.

Treat the system prompt as a small, edited document, not a sprawling spec. The agents that work best have a sharp, opinionated prompt that defines the role and the constraints, not a thousand-line behavior document. Use tools and hooks for the behaviors that aren't prompt-shaped. The system prompt is for framing; the runtime is for everything else.

Use the permission layer as your primary safety surface. Every destructive or expensive tool should run through the permission model. The model is allowed to call it; the user (or an automated policy) gates the actual execution. This is the cheapest insurance the SDK gives you, and the easiest to skip until something goes wrong.

Lean on subagents for specialization, not for everything. Subagents are valuable when a task has a sharply different tool set, prompt, or context need. They're not free — each subagent has its own context, its own startup cost, its own opportunity for misbehavior. Use them when the specialization pays for the overhead.

Wire the audit log on day one. A post-tool-call hook that writes every action to a structured log is the difference between an agent you can debug and an agent you can only watch. The cost is small; the value compounds every time something surprising happens.

The Strategic Picture

A year from now, the question will not be "is there a Claude for our vertical?" The question will be "did our team build one before our competitor did?" The SDK is the leverage point that turns this from a multi-year platform investment into a multi-month application investment. The teams that take the SDK seriously over the next two quarters will end up with vertical agents that are deeply integrated into their actual workflows — and that integration is the moat, not the model.

The teams that wait for someone else to ship a vertical Claude for them will keep waiting. The SDK isn't a hint that Anthropic is going to build for every domain; it's the explicit signal that the domain work is yours to do. The model is the commodity. The agent — the tools, the policies, the hooks, the workflows it knows how to handle — is the product.

The Claude Agent SDK doesn't change what a great agent looks like. It changes who can build one. For the last two years, that list was effectively "Anthropic and a few foundation-model labs." It's now everyone with a clear domain and a few engineers willing to learn the runtime. That shift is bigger than any individual model release, and the teams that internalize it first will be the ones whose vertical agents define the next phase of agentic software.