What Are Claude Managed Agents? Architecture, API, and Runtime Boundaries
If you search for claude managed agents, the most useful question is not only "what endpoint do I call?"
The better question is:
Which system owns the long-running agent session, and which system executes the tools?
Claude Managed Agents made that boundary visible. It treats agents as durable sessions with events, resources, environments, vaults, and deployment workflows instead of a single chat request with a few tools attached.
That changes how teams should think about agent infrastructure.
The Short Definition#
Claude Managed Agents are Anthropic's managed backend surface for running agent sessions.
The public model is built around a few objects:
| Object | What it represents |
|---|---|
| Agent | The reusable agent definition: instructions, model, tools, MCP servers, and configuration |
| Environment | The runtime package and networking shape where tool work can happen |
| Session | The durable unit of work for one agent run or conversation |
| Events | The append-only history of user input, agent output, tool calls, status, and errors |
| Files and resources | Material that can be attached to a session workspace |
| Vaults | Credential containers attached to sessions or tool access |
| Deployments | Reusable run definitions, including scheduled runs |
That object model matters because a managed agent is not just an LLM response.
A managed agent may need to:
- keep state across multiple turns
- execute shell and filesystem tools
- attach files or repositories
- pause for confirmation
- resume after a long wait
- stream events while work is happening
- recover when execution fails
- run on a schedule
- use credentials without placing them directly into agent code
Those requirements belong in a backend, not in scattered application glue.
How This Differs From A Chat API#
A chat API is usually request-response:
- send a prompt
- receive a model response
- optionally let the client run a tool
- send the result back
That is enough for many apps.
It is not enough for production coding agents, operations agents, data agents, or internal workflow agents that need filesystem state and long-running tool execution.
Managed agents move more of the lifecycle into the platform:
| Concern | Chat API with tools | Managed agents |
|---|---|---|
| Session truth | Usually application-owned | Platform-owned session object |
| Tool execution | Usually client or app-owned | Runtime environment behind the agent platform |
| Event history | Usually transcript-shaped | Append-only event stream |
| Recovery | App-specific | Part of the session lifecycle |
| Resources | App-specific upload or context logic | File/resource model attached to sessions |
| Scheduled work | External cron or workflow system | Deployment and run model |
| Credentials | App-specific secret handling | Vault and credential model |
That is why Claude Managed Agents are better understood as an agent backend category than as a single API endpoint.
The Brain And Hands Boundary#
Anthropic's managed-agents architecture discussion frames the important separation as the brain and the hands.
The brain is the managed agent loop: reasoning, session state, event stream, model calls, tool routing, and recovery behavior.
The hands are the execution environment: shell commands, file reads and writes, package installs, local tools, network calls, and generated artifacts.
This boundary is valuable because the runtime can be controlled separately from the agent loop.
For a simple hosted workflow, the provider can own both. For enterprise or platform teams, that may not be enough. They often care about:
- where files and artifacts live
- whether execution happens in a private network
- how credentials reach tools
- which outbound destinations are allowed
- whether workspaces persist across runs
- how failed or paused sessions are inspected
- how execution can be self-hosted or region-scoped
Those are runtime questions, not model questions.
What A Session Actually Needs#
The session is the durable unit of work.
In a real agent backend, a session normally needs:
- a snapshot of the agent definition
- a selected environment
- attached files or repository resources
- vault ids
- current lifecycle status
- event history
- usage and timing metadata
- links to any runtime attachments
The runtime should be replaceable. The session should not disappear because a sandbox stopped or a tool process crashed.
That is the difference between "running an agent process" and "running managed agents."
What Environments Change#
An environment describes where tool work can happen. For Claude Managed Agents, that includes the runtime package and networking configuration exposed through the public managed-agents surface.
This is the part that moves managed agents from prompt engineering into infrastructure.
Once tools can read files, run commands, and call services, the environment becomes a policy boundary:
- package managers can install dependencies
- network rules decide which systems are reachable
- files and repositories become workspace resources
- credentials have to be scoped to the right destinations
- execution must be observable and recoverable
If the environment is weakly controlled, the agent backend inherits that weakness.
What Vaults Change#
Vaults make credentials part of the managed agent model.
That matters because agents often need access to real systems: GitHub, package registries, databases, observability tools, cloud APIs, ticketing systems, or private MCP servers.
The unsafe default is to put raw secrets in the agent runtime and hope the agent does not print them, copy them, or pass them to the wrong tool.
A better pattern is:
- store credentials outside the agent source code
- attach them to sessions or deployments through vaults
- expose only the runtime shape the tool expects
- enforce network and credential policy at the boundary where traffic leaves the runtime
This is also where Sandbox0's runtime model matters. Sandbox0 can keep the sandbox process away from raw credential values by using vault-backed placeholders and egress credential injection for Sandbox0-backed runtimes.
What Deployments Change#
Sessions are useful for interactive work. Deployments are useful when the same agent run definition should be reusable.
A deployment can hold:
- the agent reference
- the environment
- initial events
- resources
- vault ids
- metadata
- an optional cron schedule
That turns a one-off agent session into recurring infrastructure.
Examples include:
- daily engineering digests
- weekly repository maintenance
- scheduled compliance scans
- recurring data refreshes
- periodic support or operations summaries
Without deployments, teams usually rebuild this with external cron jobs, queues, workflow engines, and ad-hoc session creation scripts.
Where Sandbox0 Fits#
Sandbox0 uses two related but different paths around this category.
The first path is Claude Managed Agents on Sandbox0.
In that path, Anthropic owns the Claude Managed Agents control plane. Sandbox0 acts as the self-hosted sandbox execution provider, giving Claude's managed agent loop a controlled execution environment for files, shell, workspaces, network policy, and credentials.
The second path is Sandbox0 Managed Agents.
In that path, Sandbox0 owns the managed session API and event truth. Application code uses the official Anthropic SDK shape, points the SDK at Sandbox0, and lets Sandbox0 route the session to a supported agent harness.
| Path | Control plane | Execution boundary | Best fit |
|---|---|---|---|
| Claude Managed Agents on Sandbox0 | Anthropic | Sandbox0 self-hosted sandbox provider | You want Claude's managed agent loop with Sandbox0-controlled execution |
| Sandbox0 Managed Agents | Sandbox0 | Sandbox0 sandboxes, volumes, vaults, and harnesses | You want Sandbox0 to own the managed-agents backend |
For a direct product-boundary comparison, see Claude Managed Agents Alternative. For the Sandbox0-owned product surface, start with Sandbox0 Managed Agents and the Managed Agents docs.
What To Evaluate#
When evaluating Claude Managed Agents or a compatible managed-agents backend, ask questions in this order.
1. Who owns session truth?#
If the session object and event history are owned by the provider, your application depends on that provider for resume, audit, status, and recovery semantics.
If your own backend owns session truth, you have more control over runtime placement, observability, and integration behavior, but you also own more platform responsibility.
2. Where does tool execution happen?#
Hosted execution is simpler. Self-hosted or sandbox-backed execution gives more control over data placement, network reachability, and workspace state.
The right answer depends on whether the agent needs private systems, long-lived workspaces, custom tools, or a strict execution perimeter.
3. Where do credentials live?#
Model provider credentials, service credentials, MCP credentials, and CLI credentials should not be treated as one blob.
Good managed-agents designs separate:
- SDK/API credentials
- model-provider credentials
- service credentials for tools
- credentials projected into sandbox processes
4. What happens when work pauses?#
Agents often need to wait: for a human, a tool result, a scheduled run, a retry, or a long build.
The platform should make clear what persists while the agent is idle:
- event history
- workspace files
- process state
- deployment/run records
- output artifacts
5. How much API compatibility do you need?#
Sandbox0 follows the Claude Managed Agents API shape where practical, but it is not safe to assume that every beta behavior from an upstream product has identical backend semantics everywhere.
Check the specific surface you depend on: sessions, events, deployments, files, vaults, tools, custom skills, MCP, environment behavior, and retry semantics.
Further Reading#
- Claude Managed Agents quickstart
- Anthropic: Scaling Managed Agents: Decoupling the brain from the hands
- Sandbox0: What Are Managed Agents? And How Sandbox0 Builds a Managed Agents Backend
- Sandbox0: Claude Managed Agents on Sandbox0
- Sandbox0: Claude Managed Agents Pricing and Runtime Tradeoffs
- Sandbox0: Claude Managed Agents vs Sandbox0 Managed Agents