Claude Code changed how I do GTM work, and pretty quickly I wanted it to be something my team and my systems could call, not a terminal I personally sat in. I wanted its engine, the loop that plans, calls tools, reads results, and keeps going, available inside a service, running against our stack, on a schedule. That is exactly what the Agent SDK is: Claude Code without the terminal.
This guide is about building your own agent on that engine. What the SDK hands you for free, how it differs from wiring tool use by hand, and when it is the right choice over raw API calls or just using Claude Code. If you have ever thought I wish I could bottle what Claude Code does, this is the bottle.
What the Agent SDK is
The Agent SDK is the same engine that powers Claude Code, packaged so you can build with it in your own code. Claude Code is an application built on that engine; the SDK is the engine itself, exposed. So everything you value in Claude Code, the way it loops, calls tools, manages its context, spins up subagents, is available to you as building blocks rather than a finished product.
That distinction, the engine versus the app, is the whole point. Claude Code is fantastic when you are the one driving. The SDK is for when you want an agent that runs without you: embedded in a service, triggered by your systems, doing GTM work as part of a pipeline. Same capabilities, no human in the seat.
The loop and context management you get for free
The reason to use the SDK instead of wiring tool use yourself is everything it handles that you would otherwise build. The agentic loop, send, run the tool, return the result, repeat until done, with sensible stopping. Context management, so a long-running agent compacts its history instead of overflowing. Subagents, so a big job fans out to clean-context workers. These are solved problems inside the SDK and fiddly ones outside it.
You can build all of this on raw tool use, and for a simple case you might. But the moment an agent runs long enough to fill its context, or needs to fan work out, you are reimplementing what the SDK already does well. The SDK is where you stop rebuilding plumbing and start building your actual agent.
SDK vs raw tool use
Raw tool use, from the tool-use guide, gives you the mechanism: Claude requests a call, you run it, you return the result. That is enough for a short, controlled loop you manage yourself. The SDK gives you the whole system around that mechanism: the loop controller, the stopping logic, the context handling, the subagent orchestration.
The way to think about it: raw tool use is the primitive, the SDK is the framework. Use the primitive when the interaction is small and you want full manual control. Use the framework when you want a durable agent and would rather not maintain the loop, the compaction, and the fan-out yourself. Most real GTM agents want the framework.
A rough rule for the crossover: if your loop fits in a screen of code and runs a handful of turns, raw tool use is fine. Once you are adding summarization to keep it from overflowing, or a scheduler, or fan-out, you have started rebuilding the SDK, and switching to it is less code, not more. The SDK earns its place the moment the agent stops being a toy.
Defining tools and subagents
Building an agent on the SDK is mostly defining what it can do. You give it tools, the same read and write functions from tool use, your CRM lookup, your enrichment call, your Slack notifier, and the SDK handles when to call them. You can also define subagent types, specialists with their own instructions and tools, so a research worker and a drafting worker behave differently.
This is where your agent gets its shape. The tools decide what it can touch, and the subagents decide how it divides labor. A GTM research agent might have read tools for the CRM and the web, an enrichment tool, and a researcher subagent it fans accounts out to. You describe the pieces; the SDK runs the coordination.
TipGive the agent only the tools its job needs, and gate the write tools, exactly as with raw tool use. The SDK runs the loop, but the read-first, approve-writes discipline is still yours to enforce.
Context management, handled
A real agent runs long, and a long run fills the context window, the same problem that turns a single overloaded session to mush. The SDK manages this for you: it compacts the history as the agent works, keeping the thread coherent without you writing the summarization logic. This is one of the hardest parts to get right by hand, and one of the biggest reasons to use the SDK.
Combined with subagents, this is how an SDK agent stays sharp over a big job. The main loop compacts as it goes, and heavy sub-tasks fan out to fresh contexts, so the agent can research fifty accounts or work a long pipeline without degrading. You get the scaling behavior of Claude Code because it is the same engine underneath.
Cost and observability for a running agent
An autonomous agent spends money while you are not watching, so two things matter more than they do for a single call: cost control and observability. Cost, because a loop that runs long or fans out wide multiplies token use, so cap the turns, use a cheaper model for the routine steps, and reserve the strong one for the hard reasoning. The same cheap-workers, expensive-judge split from subagents applies here.
Observability, because when an unattended agent does something odd, you need to see why. Log each turn, which tool it called, what came back, what it decided, so a bad run is a trail you can read instead of a mystery. An agent you cannot inspect is an agent you cannot trust with real GTM data, and the logging is cheap next to the cost of a silent wrong run.
When to use the SDK vs Claude Code vs the raw API
Three tools, three jobs. Use Claude Code when you are the one driving, hands-on work at your desk or from your phone. Use the raw API with tool use when the interaction is a short, controlled loop you want to manage yourself. Use the Agent SDK when you want a durable agent that runs without you, embedded in a service, and you would rather not rebuild the loop and context handling.
The honest signal you have outgrown the simpler options: you are using Claude Code for something you wish ran on a schedule without you, or you are writing more and more loop-and-context scaffolding around raw tool use. Both point at the SDK. It is the middle ground between sitting in Claude Code and building an agent framework from scratch.
- Claude Code: you are driving, hands-on, at a keyboard or from your phone.
- Raw API + tool use: a short, controlled loop you want to manage by hand.
- Agent SDK: a durable, embedded agent that runs without you, loop and context handled.
Where it goes wrong
The first mistake is rebuilding what the SDK gives you, writing your own compaction and loop control on raw tool use because you did not realize the SDK already solved it. If you find yourself deep in context-management code, stop and check whether the SDK does it for you. It probably does.
The others are the agent classics: an unbounded loop that runs up a bill, and write tools trusted too soon. The SDK runs the loop, but it does not decide your budget or your guardrails, so cap the iterations, gate the writes, and watch the cost on early runs. An autonomous agent is exactly the thing you want a fence around before you let it run unattended.
- Reimplementing the loop, compaction, or fan-out the SDK already provides.
- Unbounded loops with no iteration cap, running up cost on a confused agent.
- Granting write tools before you have watched the agent behave on reads.
- Reaching for the SDK for a one-off call, where the raw API is simpler.
The GTM version
The agent I wanted from the start is an SDK agent: a research service my systems can call, that takes an account, pulls the CRM history, enriches the missing contacts, checks the web for recent signals, and returns a grounded brief and a fit score. It runs on a schedule over the whole target list, fans out to a researcher subagent per account, and compacts as it goes, all handled by the engine.
That is Claude Code's power, bottled and embedded, doing GTM work as part of the pipeline instead of a thing I drive by hand. The terminal was the demo; the SDK is the product. What is the Claude Code workflow you wish just ran, on its own, as a service?
How to set it up
Install the SDK
Add the Agent SDK to your project. It gives you the loop, tool handling, and context management as building blocks.
Define the agent's tools
Give it the read and write functions its job needs, the same tool definitions as raw tool use. Keep writes gated:
Run the agent loop
Hand the SDK a goal and the tools, and it runs the loop, calling tools and managing context, until the job is done:
TipSet a turn cap from the first run. The SDK runs the loop, but bounding it is how you keep a confused agent from running up a bill.
Fan out and schedule it
Add a researcher subagent so the agent can fan a whole list out to clean contexts, then run it on a schedule over your target accounts. Now it is a service, not a session.
Frequently asked questions
What is the Claude Agent SDK?
It is Claude Code's engine, the agentic loop, tool handling, subagents, and context management, exposed for you to build on in your own code. It lets you create a durable agent without rebuilding the plumbing.
How is it different from raw tool use?
Raw tool use gives you the mechanism: Claude requests a call, you run it, you return the result. The SDK gives you the whole system around it, the loop controller, stopping logic, context compaction, and subagents.
When should I use the SDK instead of Claude Code?
When you want an agent that runs without you, embedded in a service or on a schedule, rather than a tool you drive by hand. Claude Code is for hands-on work; the SDK is for autonomous, embedded agents.
Does the SDK handle context for long-running agents?
Yes. It compacts the history as the agent works, so a long run does not overflow the context window. That is one of the hardest parts to build by hand and a main reason to use the SDK.
Can I use subagents with the SDK?
Yes. You can define subagent types with their own instructions and tools, so a big job fans out to clean-context workers, the same scaling pattern Claude Code uses.
How do I keep an SDK agent safe?
The same way as any agent: cap the loop's iterations, give it only the tools it needs, gate the write tools, and watch cost on early runs. The SDK runs the loop but does not set your guardrails.
Is it a lot of code to get started?
No. You define your tools and a goal, and the SDK runs the loop. The heavy lifting, the loop and context management, is what the SDK provides, so your code is mostly the tools and the wiring.
What is a good first GTM agent to build?
A research service: give it an account, and it pulls CRM history, enriches contacts, checks the web, and returns a scored, grounded brief. Run it on a schedule over your target list with a researcher subagent.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.