Managed Agents Are Serverless for AI Agents

The clearest way to understand managed agents is this:

Managed agents are serverless for AI agents.

Serverless did not make servers disappear. It moved the repetitive, operational work of provisioning, scaling, isolating, logging, and recovering servers behind a platform boundary. Developers still wrote application logic, but they stopped owning the full lifecycle of the machine that ran it.

Managed agents are doing the same thing for agent infrastructure.

Agent developers should not have to rebuild the same control plane every time they want to ship a production agent. They should not have to hand-roll sandbox lifecycle management, durable session storage, tool-call event logs, runtime recovery, trace views, credential boundaries, and agent harness hosting before they can work on the business problem.

That infrastructure is becoming a platform layer.

The Agent Demo Is Not the Agent Product#

Most agent demos start simply:

• call a model
• let it choose a tool
• run the tool
• stream the answer

That can work well for a prototype. But production agents quickly accumulate infrastructure requirements that have little to do with the agent's domain logic.

The system needs to answer questions like:

• Where does code execute safely?
• Where does session state live?
• How do users resume work later?
• What happens if the runtime crashes?
• How are tool calls recorded?
• How do operators inspect failures?
• Where do credentials live?
• How are long-running sessions billed?
• How do different agent SDKs and runtimes fit behind one product surface?

These are not edge cases. They are the normal shape of serious agent products.

That is why managed agents are becoming an infrastructure category rather than just a vendor feature.

Anthropic made the managed-agents model visible with agents, environments, sessions, events, resources, and Console observability. AWS Bedrock AgentCore uses similar category language around a serverless runtime, memory, identity, gateway, code execution, browser use, and observability. The broader direction is clear: agents need a managed runtime layer, not just another SDK.

What Serverless Means for Agents#

The serverless analogy is useful because it is specific.

In serverless application development, the developer brings business logic and configuration. The platform owns most of the operational substrate:

• placement
• isolation
• scaling
• lifecycle
• logs and traces
• recovery
• metering

For AI agents, the analogous platform responsibilities are:

• sandbox execution
• durable sessions
• append-only event history
• session observability
• agent harness lifecycle
• workspace persistence
• credential and policy boundaries
• runtime metering

The developer still owns the product. They define the agent's purpose, tools, permissions, workflows, and user experience. But they should not have to run a bespoke agent control plane for every product.

That is the core promise: let agent developers build the agent, while the platform handles the repeated operational work around it.

The Infrastructure Managed Agents Should Own#

Managed agents are not just a hosted chat endpoint with tools.

A useful managed-agents backend owns several hard infrastructure problems at once.

Sandbox Execution#

Agents often need to run untrusted or semi-trusted work:

• shell commands
• package installs
• tests
• code edits
• data transforms
• browser automation
• local MCP servers
• project-specific tools

That work needs an execution boundary. It needs filesystem isolation, network policy, resource limits, lifecycle control, and a way to preserve useful state without keeping compute alive forever.

In Sandbox0, that boundary is the sandbox. Managed Agents uses Sandbox0 infrastructure so agent developers do not need to decide how to claim, warm, pause, resume, and clean up execution environments for every session.

Durable Sessions#

An agent session is not the same thing as a process.

The session is the durable object. The runtime is an attachment.

A managed-agents platform should keep session truth outside the runtime:

• messages
• status
• tool calls
• tool results
• pending actions
• usage
• attached resources
• runtime bindings

That separation is what makes recovery possible. If an agent process or sandbox attachment fails, the session should remain inspectable and resumable.

Observability#

Production agents need more than a transcript.

When an agent fails, a developer needs to see:

• which user event started the run
• when the session entered running, idle, or terminated states
• which model spans happened
• what tool calls were requested
• which tool results returned errors
• whether the session is waiting for confirmation or custom tool output
• where time and token usage went

That is why session observability needs to be a first-class part of managed agents.

The raw event log remains the source of truth, but users need derived views: trace timelines, span waterfalls, tool-call grouping, artifact previews, and raw payload drill-downs when necessary.

This is one of the main ways managed agents becomes serverless-like. Developers get operational visibility without having to build the trace model, persistence, and UI from scratch.

Agent Harnesses#

Agent infrastructure also has to run the actual agent loop.

That loop might come from different harnesses:

• a Claude Agent SDK style runtime
• a Codex app-server style runtime
• an OpenAI Agents SDK runtime
• a custom in-house harness

These harnesses have different assumptions about process lifetime, local state, working directories, tool execution, and sandbox placement.

The managed-agents platform should absorb that difference behind a stable session model.

Internally, Sandbox0 calls these agent harnesses. Externally, the important idea is simpler: the user sees one managed-agents surface, while the platform can route sessions to the right harness implementation.

What Agent Developers Should Own#

The managed layer should not hide the product work.

Agent developers still need to decide:

• what task the agent performs
• what tools are available
• which actions require approval
• what data the agent can access
• how the product handles partial progress
• what final output means
• how humans review, interrupt, or continue work

Those are product decisions. They are where the agent becomes useful.

The platform should take away the repetitive runtime work, not the domain design.

That is the same division that made serverless useful for application developers. Serverless did not write the business logic. It changed how much infrastructure had to be owned before business logic could run in production.

Why Session Running Time Is the Right Billing Boundary#

Managed agents also change the cost model.

If every team has to run its own always-on agent workers, then users pay for idle infrastructure. They pay for warm processes, unused sandboxes, background queues, and duplicated control planes before any session does useful work.

A managed-agents platform can expose a cleaner boundary:

pay for the session while it is running.

That does not mean every harness has the same internal cost profile. Some runtimes live inside the sandbox. Some use the sandbox only as a tool. Some keep more local process state than others.

But the product model should stay simple:

• the user starts or resumes a managed session
• the platform runs the appropriate harness and sandbox attachments
• observability records what happened
• billing follows the session running window

This is another reason the serverless analogy fits. The developer should not have to pre-provision an agent runtime fleet for every possible user session. The platform should make runtime capacity available when the session needs it.

Sandbox0 Managed Agents#

Sandbox0 Managed Agents is built around this view of the category.

The goal is to provide a managed-agents backend where the repeated infrastructure work is owned by the platform:

• sandbox execution
• persistent workspaces
• durable session truth
• append-only events
• session observability
• resources and vaults
• agent harness lifecycle
• runtime policy boundaries

For the product surface and API details, see the Sandbox0 Managed Agents overview and Managed Agents docs.

Today, Sandbox0 Managed Agents supports three harness families behind the managed-agents API:

Internally, these are agent harnesses. That name is useful for implementation, but customers should not have to care about the internal routing logic. They should care that the session model, persistence, observability, and billing boundary stay consistent.

This lets Sandbox0 support different runtime shapes without turning each one into a separate product.

There is also a related but different path: Claude Managed Agents on Sandbox0. In Sandbox0 Managed Agents, Sandbox0 owns the managed session API and event truth. In Claude Managed Agents on Sandbox0, Anthropic owns the Claude Managed Agents control plane while Sandbox0 acts as the self-hosted sandbox execution provider.

Managed Agents vs. Agent SDKs#

Agent SDKs are still important.

They define how developers express tools, instructions, model calls, and agent behavior. But an SDK is not the whole production system.

An SDK usually does not give you, by itself:

• a durable session API
• sandbox lifecycle management
• persistent workspace storage
• event history
• trace views
• runtime recovery
• multi-tenant credential boundaries
• session runtime billing

Managed agents sit one layer above the SDK.

They are the backend that makes an agent SDK operational in a product.

That is why the future is not "agent SDK or managed agents." The future is agent SDKs running inside managed agent infrastructure.

The Category Is Becoming Clearer#

The first wave of AI agent tooling focused on the agent loop.

The next wave is about the backend:

• where agents run
• how sessions persist
• how tool execution is isolated
• how failures are diagnosed
• how cost is controlled
• how different harnesses fit behind one API

That is exactly the role serverless played for application code. It moved common runtime operations into a platform so developers could ship faster without giving up production-grade behavior.

Managed agents are moving agent operations into a platform boundary.

For agent developers, that should be a relief.

They should spend their time on the agent's business function: what it does, who it helps, what tools it can use, and how users interact with it.

The sandbox, session plane, observability system, harness lifecycle, and runtime metering should be infrastructure.

That is what managed agents are becoming.

And that is why managed agents are best understood as serverless for AI agents.