Managed Agents vs Self-Hosted Agent SDK: Runtime Ownership

The choice between managed agents and a self-hosted Agent SDK is fundamentally a choice about runtime ownership. With an SDK, the agent runs in a process you operate. With Managed Agents, the provider operates the server-side agent loop and Session state while your application talks to them through an API and event stream. The execution Environment is a separate choice: Anthropic documents both an Anthropic-managed cloud sandbox and a self-hosted Environment.

“Self-hosted” does not necessarily mean a server in your office. The process might run on a laptop, CI worker, Kubernetes cluster, or cloud VM. The defining fact is that your team deploys, secures, observes, scales, and recovers that process.

This article uses Anthropic's Claude Agent SDK and Claude Managed Agents as the concrete comparison because the official migration guide documents where each responsibility moves. The decision framework also applies more broadly: decide who should own each runtime responsibility before choosing a product.

The decision in one sentence

Choose a self-hosted Agent SDK when control of the agent process and lifecycle is part of your product or compliance boundary. Choose managed agents when the server-side loop and persistent Session lifecycle are undifferentiated infrastructure you would rather buy than maintain. Then choose the Environment hosting mode separately; a self-hosted Environment does not turn Managed Agents into a self-hosted Agent SDK.

That is not a universal recommendation. A managed runtime reduces one operational surface but introduces a provider contract, supported-tool model, data path, pricing model, and platform lifecycle that you must evaluate. A self-hosted runtime preserves control but makes reliability and isolation your job.

The wrong way to decide is “managed is easier” or “self-hosted is safer.” Ease and safety depend on your requirements and implementation. The useful question is: which responsibilities give your product an advantage, and which are merely work?

Runtime ownership comparison

The following table turns that question into concrete responsibilities.

Responsibility	Self-hosted Agent SDK	Managed-agent runtime
Agent loop	Runs in a process you deploy	Runs in provider infrastructure
Agent definition	Usually constructed from code/config for a run	Often persisted and versioned by the service
Session state	Your process and storage strategy must preserve it	Service stores session history and exposes events
Built-in tools	Execute in your process against its environment	Execute in the Session Environment, which can be Anthropic-managed or self-hosted
Custom tools	SDK dispatches local handlers or your loop calls them	Your client may still receive events and return results
Filesystem	Local paths and mounted volumes are directly available to your process	Files are uploaded or mounted as session resources
Permissions	Your code, runtime identity, and SDK callbacks enforce policy	Managed-agent policies govern tools; your client and selected Environment still have their own controls
Scaling and recovery	Your deployment handles workers, retries, checkpoints, and failed processes	Provider handles the server-side loop; Environment operations depend on the selected hosting mode; your client handles API and business-level recovery
Observability	You design logs, traces, metrics, and retention	Provider emits session events; you still integrate product and business telemetry
Cost	Model usage plus your compute, sandbox, storage, and operations	Model usage plus managed runtime/tools, and any self-hosted Environment costs you operate

The table exposes an important nuance: managed does not mean responsibility disappears. It changes the interface through which you exercise that responsibility.

For example, moving built-in Bash and file operations into a Session Environment removes the need to run those tools in your application process. Whether Anthropic or your team hosts that Environment changes the infrastructure boundary. A custom tool that writes to your database still requires authentication, authorization, validation, idempotency, and an auditable handler on your side.

What managed agents remove—and retain

Anthropic describes Managed Agents as replacing a hand-written agent loop with managed infrastructure. In a Messages API loop, the application repeatedly sends conversation history, reads tool_use, executes a tool, appends tool_result, and decides when the loop is finished. In Managed Agents, a Session stores history server-side, pre-built tools run in the configured Environment, and the event stream reports when the Session becomes idle.

For a Claude Agent SDK migration, the shift is similar but more specific:

ClaudeAgentOptions created per run becomes a persisted, versioned Agent definition.
query(...) or a ClaudeSDKClient process becomes Session creation plus sent and received events.
built-in tools move from the process and local filesystem into the Session Environment at /workspace, whether that Environment is Anthropic-managed or self-hosted;
cwd and add_dirs become uploaded or mounted resources;
SDK permission modes and callbacks map to per-tool permission policies and confirmation events.

The managed service therefore removes a meaningful amount of loop, Session, and lifecycle code. How much sandbox infrastructure it removes depends on whether the Environment is Anthropic-managed or self-hosted.

It does not remove every application responsibility. The official migration contract says a custom tool is declared on the Agent, but your client still handles agent.custom_tool_use and sends a user.custom_tool_result. Client-side presentation features, turn counting, and some hook behavior also move into your application rather than becoming automatic server features.

Before selecting managed agents, draw the boundary around every custom tool. If most business value and failure risk live in those tools, the application still owns the hardest controls even after the core loop moves to a provider.

When a self-hosted Agent SDK is the better fit

A process you operate is usually the stronger fit when one or more of these constraints is decisive.

The local execution environment is the product

If the agent must interact deeply with a developer's checkout, proprietary build system, local hardware, or an existing runtime identity, moving files into a remote cloud sandbox may add more translation than it removes. A self-hosted Managed Agents Environment can change that execution boundary, but the provider still operates the agent loop and Session contract. An SDK goes further by running the agent process itself next to those resources and under your deployment primitives.

You need a bespoke lifecycle

A custom orchestrator may require nonstandard checkpoints, deterministic approval stages, multiple model providers, unusual retry semantics, or a scheduling model that does not map cleanly to the managed Session API. Owning the process lets you implement that lifecycle directly.

Your deployment or data boundary requires it

Some organizations require a particular region, network topology, hardware, storage system, or audit pipeline. A managed provider or self-hosted Environment might support the requirement—but that must be proven from the current contract and architecture. If neither does, operating the entire runtime inside the approved boundary may be necessary.

As of August 31, 2026, Anthropic's Managed Agents overview labels the product beta and says stateful Sessions do not support Zero Data Retention or HIPAA BAA. Those are decision constraints, not footnotes. Recheck the current overview and your own requirements before sending regulated or retention-sensitive data through this path.

Deep runtime observability is essential

An event stream can describe what the managed service exposes. A self-hosted process can also expose scheduler decisions, memory pressure, container lifecycle, custom checkpoints, and application-specific traces at the exact level your team defines. That flexibility is valuable only if the team will build and operate the observability well.

You need portable runtime ownership

If provider portability is a first-order product requirement, keeping orchestration and state in your own service can reduce dependence on one managed Session contract. Portability still requires disciplined abstractions and tests; merely using an SDK does not create it automatically.

When managed agents are the better fit

A managed runtime becomes attractive when the operational work is substantial but not differentiating.

Tasks are long-running or asynchronous

Anthropic's platform introduction positions Managed Agents for long-running tasks and asynchronous work, while the Messages API is the path for custom loops and fine-grained control. A server-side Session can continue independently of a fragile client connection, provided your application handles events and recovery according to the API contract.

You want versioned agent configuration

Persisted Agent versions create a clear promotion and rollback unit. New Sessions can be pinned to a known model, system prompt, toolset, and policy version without coupling every change to an application deployment.

A managed cloud Environment can replace repeated platform work

If every team would otherwise build the same code-execution isolation, file handling, Session state, and loop recovery, an Anthropic-managed cloud Environment can reduce duplicated engineering. With a self-hosted Environment, your team still operates more of the sandbox infrastructure even though the service manages the Agent loop and Session. In either mode, validate networking, credentials, resource limits, data handling, and incident procedures.

A smaller operational surface matters more than maximal flexibility

Teams with a small platform function may gain more from a supported Session lifecycle than from owning every scheduler and container detail. The trade is accepting the provider's supported capabilities and release cadence.

Migration is an ownership transfer, not a package swap

Moving from an Agent SDK to Managed Agents changes where concepts live. Treat it as an architecture migration.

SDK concept	Managed Agents destination	Migration question
Per-run options	Persisted, versioned Agent	How will versions be promoted and rolled back?
SDK process/query	Session plus event stream	How will the client reconnect, deduplicate, and resume?
Local paths	Uploaded or mounted resources	Which files are authoritative, and when are they refreshed?
Built-in local tools	Configured Environment's `/workspace` tools	Who hosts the Environment, and do networking and runtime packages match the task?
Custom handler	Custom-tool event and result	How are auth, timeout, idempotency, and audit enforced?
SDK permission callback	Permission policy and confirmations	Which decisions remain server-side versus human/client-side?
Local logs	Session events plus client telemetry	Can the combined evidence answer incident questions?

Run one representative workflow end to end before moving production traffic. Verify file freshness, tool credentials, cancellation, reconnect behavior, duplicate custom-tool results, version rollback, and the terminal Session state. “The happy-path answer looked correct” is not a runtime migration test.

The Managed Agents quickstart is useful for learning Agent, Environment, Session, and Event concepts. The migration guide should remain the source of truth for responsibility changes.

Where Agent.Space fits

Agent.Space is a different product boundary from both a self-hosted Claude Agent SDK service and Anthropic's Managed Agents API.

Agent.Space brings supported Agent harnesses, model access, and a cloud Workspace together. The distinction between harness, model, Workspace, and funding source is explained in how Agent.Space works. It does not claim that its Developer API implements Anthropic's Managed Agents Sessions, Environments, or event contract.

This makes Agent.Space relevant when the real requirement is not “build our own agent runtime.” A team may instead want to use an established coding harness, keep files and sessions available in a shared Workspace, or connect a supported client to available models through the Agent.Space Developer API.

Security still depends on the chosen boundary. Before putting repository data or credentials into any route, review which process or Workspace can read them, how keys are stored, and which actions require approval. The coding Agent Workspace security guide provides a practical checklist.

If you want a mature coding harness rather than a new SDK runtime, compare the Agents available in Agent.Space. That path avoids writing an orchestration service, but it is not a claim of feature parity or official integration with Anthropic Managed Agents.

The practical takeaway

List every runtime responsibility, assign an owner, and inspect the risky exceptions. Choose an SDK when controlling the agent process and lifecycle is essential. Choose managed agents when persistent Sessions and loop reliability are infrastructure you want a provider to operate, then decide separately whether Anthropic or your team should host the Environment. If the real need is simply to use coding agents with model access and a shared place for work, evaluate that as a third path instead of forcing it into an SDK-versus-managed-runtime comparison.