What Are Managed Agents? And How Sandbox0 Builds a Managed Agents Backend

Managed agents is one of those terms that suddenly starts showing up everywhere and still means different things depending on who is talking.

Some people use it to mean “an agent API that Anthropic hosts for you.” Some use it to mean “a long-running coding agent.” Others use it to mean “an agent runtime with tools and persistent sessions.”

The useful definition is narrower.

Managed agents are not just a chat endpoint with tools bolted on. They are a backend model for running agent sessions with durable state, event history, tool execution, runtime orchestration, and recovery semantics behind a stable API.

That distinction matters because once you understand the backend, you stop treating managed agents as a vendor-specific feature and start seeing them as a new platform category.

That is the framing we use at Sandbox0. Claude Managed Agents made the category visible. Sandbox0 is building a managed agents backend around persistent sandboxes, durable session truth, and controlled execution boundaries.

For the current Sandbox0 product surface, see the Sandbox0 Managed Agents overview and Managed Agents docs. For a Claude-specific explainer, read What Are Claude Managed Agents?. For the newer self-hosted sandbox provider angle, see Claude Managed Agents on Sandbox0. For a direct evaluation page, see Claude Managed Agents Alternative.

What Managed Agents Actually Are#

At a high level, managed agents expose a few core objects:

• an agent definition
• an environment where the agent can run
• a session that holds the running conversation and execution lifecycle
• an event stream that records what happened

That sounds simple, but it is much more than a normal LLM request-response interface.

In a normal chat API, the server receives a request, generates an answer, and returns a response.

In a managed agents system, the server may need to:

• keep the session alive across many user turns
• execute tools inside a runtime environment
• pause for user confirmation
• wait for custom tool results
• resume after interruption
• keep track of usage and status
• recover after runtime failure without losing session history

That is why managed agents are better understood as a sessioned agent backend than as a single model call.

Why Claude Managed Agents Matter#

Claude Managed Agents matter because they made this model legible in public.

Anthropic's Managed Agents docs describe a resource model built around agents, environments, sessions, and session events. Their engineering post, Scaling Managed Agents: Decoupling the brain from the hands, also makes a more important architectural point: the long-lived session truth should not be confused with the sandbox that executes commands.

That is the key idea.

The session is the durable object. The runtime is replaceable.

Once you accept that separation, the architecture becomes much easier to reason about:

• the agent session is the truth
• the execution environment is an attachment
• tool calls are events in the session lifecycle
• recovery should preserve the session even if the runtime has to be replaced

You do not have to copy Anthropic's private implementation details to build a compatible system. But you do have to respect that external contract and those lifecycle semantics.

The Backend Behind Managed Agents#

If you strip away the UI and vendor branding, a managed agents backend usually needs five things.

1. Session Truth#

You need a durable session record that survives process crashes and runtime replacement.

That usually includes:

• session metadata
• resolved agent configuration
• attached resources
• usage and timing stats
• current status
• pending required actions

Without that, you do not really have managed agents. You have a long-running process with a fragile memory.

2. Append-Only Event History#

Managed agents need an append-only event log, not just a final transcript.

That event history should cover:

• user messages
• agent messages
• tool use requests
• tool results
• interrupts
• requires-action states
• status transitions
• errors

This is what makes replay, pagination, streaming, auditing, and resume semantics possible.

3. Runtime Orchestration#

A managed agents backend needs to decide when to:

• provision a runtime
• wake a suspended session
• start a run
• interrupt a run
• resume after confirmation
• retry or reschedule after failure

This orchestration layer is the difference between “a tool runner” and “a managed agent platform.”

4. Sandbox Execution#

The backend also needs a place to actually do work.

That usually means:

• file access
• command execution
• package installation
• workspace state
• network policy
• mounted resources

This execution layer can be ephemeral or persistent, but for real agent workloads, persistence becomes important quickly.

5. Credential Boundaries#

This is one of the easiest parts to get wrong.

Naive systems inject every credential directly into the agent runtime and hope the agent behaves. That is a weak model for enterprise agents, especially when the runtime can execute arbitrary code.

A better model is:

• keep session truth outside the runtime
• keep sensitive credentials outside the runtime when possible
• only expose controlled outbound access paths

What Usually Breaks in Naive Managed Agent Implementations#

Many first attempts at managed agents look workable in a demo and then break under real usage.

The common failures are predictable.

Mistake 1: Treating One Container as the Whole System#

If the entire session truth lives inside one long-running container, then every crash becomes a session integrity problem.

That is not a managed agents backend. That is a sticky process.

Mistake 2: Keeping State Only in Memory#

If pending actions, tool confirmations, or event ordering live only in memory, then interruption and recovery become unreliable.

Mistake 3: Using Ephemeral Workspaces for Stateful Agent Work#

Ephemeral runtimes are fine for one-shot tasks. They are not a strong default for coding agents, research agents, or any workflow where the agent needs to come back to the same files and state.

Mistake 4: Dumping Raw Secrets Into the Runtime#

If the agent is untrusted enough to need a sandbox, it is usually also untrusted enough that you should not casually drop high-value credentials into its environment.

Mistake 5: Focusing Only on Tool Loops#

Tool use is just one part of the system.

Managed agents also need:

• resource models
• event semantics
• wait and resume behavior
• status transitions
• recovery logic

Where Sandbox0 Fits#

Sandbox0 is not trying to recreate Anthropic's private stack line for line.

The goal is different and simpler:

Build a managed agents backend that is compatible with the public managed agents model while using Sandbox0's own execution, persistence, and policy primitives underneath.

That means a few design choices matter more than superficial similarity.

Durable Sessions Outside the Runtime#

In Sandbox0's design, session truth belongs in the control plane, not in a sandbox process.

That includes:

• session metadata
• event log
• runtime binding
• pending action state
• usage aggregation

This is the right place to put durable truth because the sandbox should be replaceable.

Sandbox0 as the Execution Substrate#

The runtime still needs somewhere to execute commands, manage files, and host agent-side components. That is where Sandbox0 fits well.

Sandbox0 already provides core primitives that map naturally onto managed agents:

• isolated sandboxes
• persistent volumes
• snapshot and restore workflows
• warm pools for fast startup
• network policy controls
• egress auth and credential injection paths

Those are not cosmetic features. They are exactly the infrastructure concerns that show up when you move from “tool demo” to “managed agent backend.”

A Vendor Adapter Layer Instead of a Vendor Lock-In Layer#

A managed agents platform should not hardcode its whole identity to one runtime implementation.

Our current direction is:

• keep the public managed agents contract at the gateway
• keep session truth in a dedicated control plane
• use Sandbox0 sandboxes as the execution substrate
• attach a vendor-specific runtime adapter where needed

That is the right boundary because the external contract should stay stable even if the internal runtime strategy evolves.

How Sandbox0 Builds a Managed Agents Backend#

The architecture we are building is easier to understand if you split it into four layers.

Managed-Agent Gateway#

This is the public API layer.

It exposes the managed agents contract:

• files
• skills
• environments
• agents
• vaults and credentials
• sessions
• session resources
• session events

This layer should be compatible and boring. Its job is not to invent new semantics. Its job is to expose the contract cleanly.

Session Plane#

This is the system core.

It owns:

• session truth
• append-only event history
• pending actions
• status transitions
• run lifecycle
• usage aggregation
• runtime bindings

If you are evaluating managed agents infrastructure, this is the most important layer to inspect.

Runtime and Wrapper Layer#

This layer turns a sandbox into an agent runtime attachment.

It is responsible for:

• provisioning a sandbox
• mounting workspace and harness-state storage
• syncing session resources
• starting the runtime wrapper
• relaying runtime events back into the session plane

Sandbox0 Execution Layer#

This is the actual execution substrate.

It gives the runtime:

• a working directory
• mounted files and repositories
• network controls
• persistent state
• controlled outbound access

That is what lets a managed agents backend behave like a real runtime system instead of a sequence of disconnected tool calls.

Claude Managed Agents and Sandbox0 Managed Agents#

The simplest comparison is this:

The important point is not “ours is the same.”

The important point is that managed agents should become a category with multiple implementations, not a feature that only exists inside one hosted product.

Why Runtime Ownership Matters Here#

Managed agents sit right at the boundary between:

• model APIs
• runtime infrastructure
• storage
• security policy
• credentials
• deployment topology

That boundary is too important to stay conceptually opaque forever.

Runtime ownership matters in three ways.

It Makes the Category Clearer#

When the backend is described in terms of durable sessions, event streams, runtime attachments, and credential boundaries, teams can see what managed agents actually require.

That improves the whole ecosystem because people stop collapsing the problem into “just call a model with tools.”

It Gives Infrastructure Teams a Real Starting Point#

Plenty of teams want managed agents semantics, but also want:

• private deployment
• custom runtime boundaries
• persistence
• policy control

A backend with explicit runtime boundaries is much more useful to those teams than a conceptual diagram.

It Encourages Better Architecture#

When the implementation boundaries are explicit, weak ownership lines are easier to spot.

That pushes the system toward cleaner separation between:

• durable session truth
• runtime orchestration
• execution substrate
• credential control

FAQ#

What are managed agents?#

Managed agents are agent systems exposed as durable sessions with runtime orchestration, event history, tool execution, and recovery semantics behind an API. They are more than a single LLM call or a stateless chat endpoint.

How are managed agents different from agent SDKs?#

An agent SDK usually gives you a runtime library or process model for building agents. Managed agents add a hosted or platform-level backend around sessions, environments, events, lifecycle management, and resume semantics.

What is a managed agents backend?#

A managed agents backend is the control plane and execution system behind the API. It typically includes session storage, append-only events, runtime orchestration, tool execution, resource handling, and recovery logic.

Can managed agents be self-hosted?#

Yes. A managed agents backend can run in a platform-owned environment as long as it preserves the key resource and lifecycle semantics: agents, environments, sessions, events, runtime orchestration, and recovery.

Why is persistence important for managed agents?#

Persistence matters because real agent work is rarely one-shot. Coding agents, research agents, and tool-heavy workflows often need durable workspaces, resumable sessions, and recoverable runtime state.

Final Takeaway#

Managed agents are best understood as a new infrastructure category.

Claude Managed Agents helped define the category in public. The next step is making the backend model more portable across execution substrates.

That is why Sandbox0 is building a managed agents backend around durable sessions, sandbox execution, and explicit credential boundaries.

If you want adjacent context on the execution side, read Claude Code SDK Deployment Modes: Ephemeral, Long-Running, and Hybrid and Persistent Storage for AI Agent Sandboxes. If you are comparing product boundaries, read Claude Managed Agents vs Sandbox0 Managed Agents and Claude Managed Agents Alternative.