I built an agent on the SDK, and then I discovered the second job hiding inside the first. Running it meant hosting the loop, standing up a sandbox for its tools, storing its state, keeping all of that up and healthy. I had set out to build an agent and ended up also running a small piece of infrastructure, spending as much energy operating the thing as improving it. That operations cost is the quiet tax on your own agent.
Managed Agents hand that tax back. Anthropic runs the loop, hosts the sandbox, and holds the state, so you define the agent and let the platform operate it. This guide is about that trade: what managed gives you, what it costs you in control, and when it is the right call versus self-hosting with the SDK.
What Managed Agents are
A Managed Agent is an agent Anthropic runs on the server side. You define what the agent is, its instructions and tools, and instead of running the loop in your own infrastructure, Anthropic runs it, hosts the sandbox its tools execute in, and keeps its state. You interact with it as a service rather than as a process you operate.
The mental split is who runs the loop. With the Agent SDK, you do: the loop executes in your code, on your servers. With Managed Agents, Anthropic does: the same kind of agentic loop, operated on their side. The agent's job is the same; the operational burden moves off your plate.
Managed vs self-hosted: who runs the loop
This is the core decision, and it is cleanly about operations, not capability. Self-hosting with the SDK gives you full control: the loop runs where you put it, tools execute in your environment, and you own every part of the pipeline. That control is real and sometimes necessary, and it comes with the work of running all of it.
Managed trades that control for freedom from the operations. You give up running the loop and hosting the sandbox, and in return you stop maintaining them. Neither is better in the abstract; the right one depends on whether control or offloading the ops matters more for your case.
- You want control over the loop and toolsAgent SDK (you host)
- You want Anthropic to run and host itManaged Agents
Stateful and server-run
Managed Agents are stateful, meaning the agent persists on the server rather than living only for the duration of one call. That persistence is something you would otherwise build and maintain, storing conversation and progress, handling resumption, and it is genuinely fiddly to get right. Having it handled is a large part of the appeal.
Because it is server-run and stateful, a managed agent behaves more like a durable service you talk to than a script you invoke. That fits GTM work that spans time, an agent that works a set of accounts over hours, picks up where it left off, and keeps its context, without you operating the machinery that makes persistence work.
Statefulness also changes how you design the agent's work. Because it persists, you can hand it a long-running responsibility, watch these fifty accounts and act when something changes, rather than only one-shot tasks. That is a different and more powerful shape than a stateless call, and it is exactly the shape a lot of GTM monitoring wants.
The hosted tool sandbox
Agents that run tools need somewhere safe to run them, especially tools that execute code or touch the outside world. Managed Agents provide a hosted sandbox for exactly this, so the tool execution environment is Anthropic's problem, not yours. You do not stand up and secure your own sandbox for the agent's tools.
This matters more than it sounds, because a sandbox is one of the more serious pieces of infrastructure to run well and safely. Getting a hosted one as part of the managed offering removes a real chunk of the security and operations work that comes with running capable, tool-using agents yourself.
TipThe hosted sandbox is often the deciding factor. If your agent runs code or capable tools, letting Anthropic host the execution environment removes real security and operations work you would otherwise own.
When managed is the right call
Reach for Managed Agents when you want the agent and not the operations. If your team is small, or your strength is the GTM logic rather than running infrastructure, or you simply do not want to maintain a loop host, a sandbox, and a state store, managed lets you ship the agent and skip all of that. It is the fastest path from a working agent to a running one.
It also fits when persistence and safe tool execution are central to what you are building, since those are exactly the pieces managed handles best. If the hard part of your agent is the operations rather than the logic, managed is turning the hard part into someone else's job.
When to keep it self-hosted
Keep the self-hosted SDK when control is the priority. If you need the loop to run in a specific environment, if tools must execute inside your own network for data reasons, or if you want to shape every part of the pipeline, self-hosting is the answer, and the operations work is the price of that control.
Data and compliance often decide this. If your requirements say certain data cannot leave your environment, or your tools must run against internal systems in a particular way, that can point you to self-hosting regardless of the convenience of managed. Let the constraints choose, not the convenience.
You can move between the two
The managed-versus-self choice is not a one-way door. A common path is to prototype fast on managed, prove the agent is valuable without sinking time into infrastructure, and only move the pieces that need control to self-hosting once the value is clear. You spend the operations effort where it is justified, after the agent has earned it, not before.
It can also go the other way: a self-hosted agent whose operations become a drag gets moved to managed to shed the burden. The point is that who runs the loop is a decision you can revisit as your constraints and your team change. Start where the friction is lowest today, and reserve the right to move when the tradeoff shifts.
Where it goes wrong
The first misstep is choosing managed for the convenience and then hitting a control requirement you did not anticipate, a tool that has to run somewhere specific, a data path that is not allowed. Check your control and data constraints before you commit, because they are the things managed trades away.
The second is not reading the cost model. A managed service that runs the loop and hosts state and a sandbox is priced differently from paying per token on your own infrastructure, so model your expected usage against how it is billed rather than assuming it maps to raw API pricing. And as with any newer offering, verify the current capabilities and limits in the docs before you build on them.
- Picking managed, then hitting a control or data-path requirement it cannot meet.
- Not modeling the cost, which differs from paying per token on your own infrastructure.
- Assuming feature parity or limits; verify current capabilities in the docs first.
- Choosing by convenience when a compliance constraint should have decided.
The GTM version
For a lean GTM team, Managed Agents are often the difference between an agent that ships and one that stays a prototype, because the operations, not the logic, are what usually stall a small team. The research agent, the SDR assistant, the account-monitoring agent, you define the behavior and let Anthropic run it, and you spend your time on the GTM logic instead of on keeping a loop host alive.
The rule I would give myself back then: if the hard part of your agent is running it, not designing it, look hard at managed. Weigh control and data first, then let convenience win where it can. Is the thing slowing your agent down the logic, or the infrastructure around it?
How to set it up
Design the agent: instructions and tools
Define what the agent is and what it can do, its instructions and its tools, the same as any agent. This part does not change; only who runs it does.
Check your control and data constraints
Before choosing managed, confirm your requirements allow it: can tools run in a hosted sandbox, can the relevant data flow through a managed service. If a constraint says no, self-host with the SDK instead.
TipLet compliance and data-residency requirements make this call, not convenience. Managed trades control for offloaded operations, so decide with the constraints in front of you.
Create and run it as a managed service
Define the agent as a Managed Agent so Anthropic runs the loop, hosts the sandbox, and keeps its state. Check the docs for the current API shape, then interact with it as a persistent service rather than a script you operate.
Model the cost against your usage
The managed pricing differs from raw per-token billing, so estimate your expected usage against how it is charged before you scale. Do the arithmetic up front the way you would for any job you plan to run at volume.
Frequently asked questions
What are Managed Agents?
Agents that Anthropic runs on the server side: it operates the agentic loop, hosts the tool sandbox, and keeps the agent's state, so you define the agent without running that infrastructure yourself.
How do Managed Agents differ from the Agent SDK?
The difference is who runs the loop. With the SDK you host and run it yourself for full control; with Managed Agents Anthropic runs it, so you trade control for freedom from the operations.
What does stateful mean here?
The agent persists on the server across calls rather than existing only for one request, so it can work over time and resume, without you building and maintaining the state storage.
What is the hosted tool sandbox?
A safe execution environment Anthropic provides for the agent's tools, especially ones that run code or touch the outside world, so you do not have to stand up and secure your own.
When should I choose managed over self-hosting?
When you want the agent and not the operational burden: a small team, a focus on GTM logic over infrastructure, or a need for persistence and safe tool execution you would rather not build.
When should I self-host with the SDK instead?
When control is the priority: the loop must run in a specific environment, tools must execute inside your network, or data constraints require it. Let compliance decide, not convenience.
How is the cost different?
A managed service that runs the loop and hosts state and a sandbox is priced differently from paying per token on your own infrastructure. Model your expected usage against how it is billed before scaling.
Are Managed Agents a good fit for a lean GTM team?
Often yes, because for a small team the operations, not the logic, are what stall an agent. Managed lets you define the behavior and ship it while Anthropic runs it, provided your data and control constraints allow it.
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.