Dora NodaEvery platform team running AI agents on Kubernetes has written the same three objects, over and over, once per agent: a StatefulSet of size 1, a headless Service, and a PersistentVolumeClaim. It works for the first agent. By the fiftieth, it is an operational nightmare — that is the Kubernetes maintainers' own phrase, not mine. In March 2026, SIG Apps shipped the replacement: the Agent Sandbox project, a declarative Sandbox CRD that collapses that whole hand-rolled stack into one resource:
apiVersion: agents.x-k8s.io/v1beta1
kind: Sandbox
metadata:
name: my-sandbox
spec:
podTemplate:
spec:
containers:
- name: my-container
image: <IMAGE>One object in, and the controller hands you what the three-object stack used to provide: a single stateful pod with a stable hostname (my-sandbox), persistent storage that survives restarts, and lifecycle controls — pause, resume, scheduled deletion — that the raw primitives never had. That before/after is the whole pitch. The rest of this post is about whether you should believe it: why agents break every existing workload model, how the four CRDs fit together, what the isolation choice actually costs, what a claim-per-session pattern buys a deploy-from-chat platform's own MCP server, and — honestly — which parts are ready to adopt and which are still too new to build production infrastructure on.
Why agents break every workload model Kubernetes has
Kubernetes is excellent at two shapes, as Deborah Emeni's Northflank deep-dive puts it: stateless replicated apps managed by Deployments, and stable numbered sets of stateful pods managed by StatefulSets. Agent runtimes fit neither. Walk through the mismatch concretely, because each broken assumption maps to one feature of the new API:
- Singleton, not replicated. An agent runtime is one isolated environment per user session or task — not a pool behind a Service. A Deployment's whole job (N identical replicas, rolling updates) is machinery you don't want; you want exactly one of this thing, with
replicaslimited to 0 or 1. - Stateful with a stable identity. Agents hold context across tool calls, keep a scratchpad for notes and code execution, and sometimes need to talk to each other. That means a dedicated hostname and network address per sandbox, plus storage that survives a restart — the headless-Service-plus-PVC half of the hand-rolled stack.
- Idle-mostly, with absurd duration variance. Agents sit idle and then spring into action; a task can take 50 milliseconds or run for weeks. Neither the churn-and-discard Job model nor the always-on Deployment model prices that correctly — you want pause-when-idle and resume-without-losing-state.
- Untrusted code. An agent writes and executes code you did not review. Standard container namespacing shares the host kernel across every container on the node, so a kernel-level exploit in one tenant's agent can reach the host and every neighbor. Agents need isolation stronger than namespaces — a sandbox runtime, not just a cgroup.
"Mapping these unique agentic workloads to traditional Kubernetes primitives requires a new abstraction," wrote maintainers Janet Kuo and Justin Santa Barbara in the March 2026 announcement. The industry context makes the timing obvious: 40% of enterprise applications are expected to run embedded task-specific agents by the end of 2026, per incident.io's Ben Wheatley. As startup advisor Pradipta Banerjee observed, "the architectural model of consuming AI is shifting from stateless inference to stateful execution environments interacting with external tools" — and that shift, he notes, "is fundamentally changing the security posture required to operate these systems."
The four CRDs and the claim flow
Agent Sandbox is a standard controller-plus-CRD project: you apply a Sandbox (or one of its extension resources), and the controller manages the underlying Pod, storage, and networking. There are four resources, each with one job:
| CRD | Job |
|---|---|
Sandbox | The core: one stateful, singleton pod with stable identity, persistent storage, and lifecycle controls (pause, resume, scheduled deletion). |
SandboxTemplate | A reusable template codifying the runtime configuration — pod template, volume claim templates, network policy — so teams stop duplicating Sandbox definitions. |
SandboxClaim | The user-facing request: "give me an execution environment from this template," without exposing provisioning details. Frameworks like LangChain or ADK claim sandboxes instead of managing Sandboxes directly. |
SandboxWarmPool | A pool of pre-warmed sandbox pods, so a claim resolves in sub-second time instead of waiting on a cold pod start. |
The request path is the part worth internalizing, because it is the shape your own orchestrator will call: "Users or orchestration services can simply issue a SandboxClaim against a SandboxTemplate, and the controller immediately hands over a pre-warmed, fully isolated environment to the agent." Template authors (cluster admins) define what a sandbox is allowed to be; claimants (users, CI jobs, agent frameworks, your MCP server) just ask for one and watch the Ready condition. The project also ships a Python client and examples covering policy templates, OpenClaw, Python and VS Code environments, a Chrome browser sandbox, and a LangChain-based coding agent — enough to go from kubectl apply to a working agent runtime in an afternoon.
gVisor vs Kata: the isolation choice, honestly priced
The controller delegates low-level isolation to what it calls Sandbox Runtimes, selected per workload through the standard runtimeClassName field — the design is deliberately backend-agnostic. Today that means two options, and the tradeoff between them is the most operationally significant decision in the whole project:
- gVisor intercepts syscalls in userspace via its
runscruntime, shrinking the kernel attack surface without a full VM per workload. Lower overhead, faster startup, and kernel plus network isolation adequate for multi-tenant untrusted code execution. - Kata Containers runs each pod inside a lightweight virtual machine with its own dedicated kernel. Stronger isolation — a kernel exploit is contained to that workload's VM — at the cost of higher startup latency from external VM creation.
That latency cost is precisely why SandboxWarmPool exists: pre-warming trades idle compute cost for reduced provisioning latency, and the tradeoff bites hardest on the Kata path. The maintainers are blunt about the baseline — starting a new pod takes about a second, which they admit is too long for an agent that needs to spring into action. So the honest pricing is: gVisor for the latency-sensitive default, Kata where the threat model justifies paying for warm idle capacity, and warm pools sized against however bursty your agent invocations actually are. Note what the project pointedly does not do: it gives you the isolation primitive and the declarative API, not the surrounding production infrastructure. You install it onto a cluster you already operate — provisioning, autoscaling, multi-tenancy policy, and bin-packing remain your job (or your infrastructure provider's).
What one durable session per claim buys a deploy-from-chat MCP server
Here is where the upstream primitive meets a concrete platform architecture. A deploy-from-chat PaaS has an MCP server standing between the agent and the infrastructure: the agent calls tools, the tools do things. The awkward case is the tool call that kicks off work outliving the request — a rollout that takes minutes, a build that streams logs, a migration that must survive the agent going idle and coming back. Request-scoped processes handle this badly: either the tool call blocks until the work finishes (tying up the session), or the platform hand-rolls some detached-execution mechanism with its own state store, log plumbing, and orphan cleanup.
Model it as one SandboxClaim per agent session instead, and the shape inverts. The MCP server's rollout tool doesn't execute the rollout — it claims a sandbox from a hardened template, drops the rollout job into that sandbox's persistent workspace, and returns the sandbox identity to the agent. The session is now a first-class scheduled object: it has a stable hostname the agent can reconnect to, storage that survives the agent disconnecting, pause/resume lifecycle for the idle gaps, and scheduled deletion as built-in orphan cleanup.
The controller, not your MCP server, owns the lifecycle bookkeeping — your server just watches the Ready condition and streams state back through tool responses. This is also the seam where the project's youth matters most, so be precise about what to adopt versus what to watch. The Sandbox core — declarative singleton, stable identity, persistent workspace, pause/resume — is the load-bearing idea, already at v1beta1, and directly replaces the StatefulSet-per-agent pattern most teams hand-rolled. The extension surface (SandboxClaim ergonomics, warm-pool autoscaling behavior, the proposed E2B-compatible HTTP gateway that would let existing E2B SDK users migrate without rewriting clients) is where the 0.x weekly-release churn lives. Adopt the core as the session primitive; treat the claim ergonomics and pool sizing as configuration you will revisit every few releases.
Build-vs-buy, with 2026 prices on the table
No honest treatment of this project skips the hosted alternatives, because for many teams they are the right answer. The field as of August 2026, per the community comparisons: E2B is the most mature hosted sandbox API with a free tier; Daytona went SaaS-only in June 2026, which takes it off the self-hosted shortlist entirely; Google's GKE Agent Sandbox (now under the Agent Substrate branding, claiming 10x density over standard container runtimes) is the natural choice if you already live on GKE; and kubernetes-sigs agent-sandbox is the answer to "any conformant cluster, including the Hetzner bare metal you own."
The decision splits on two questions. First, data gravity: if agent sessions touch customer code and secrets that must stay on your machines, a CRD you install with kubectl apply beats any hosted API regardless of feature parity. Second, operational appetite: the upstream project gives you the primitive, not the platform — cluster operations, pool sizing, and tenant policy are yours.
If you have no interest in operating that, a managed sandbox provider or BYOC deployment buys back your time; Northflank, for context, prices the raw compute at $0.01667/vCPU-hour and $0.00833/GB-hour and has run this workload class since 2021, which tells you what the managed premium is competing against. What the upstream project changes even for buy-side teams is the exit option: a vendor-neutral, CNCF-governed API with an E2B-compatibility proposal on the table means the migration path off any hosted sandbox gets cheaper every release. That alone is worth tracking the changelog.
The new abstraction, earned
A year ago, "run my agent somewhere safe" meant either a hosted sandbox API or a pile of hand-assembled primitives you owned forever. Kubernetes now has a native answer — a declarative, singleton, stateful workload with stable identity, pluggable strong isolation, and a claim-based allocation model that matches how orchestrators actually request agent environments. It is young, the extensions are still churning, and nobody should pretend a v1beta1 CRD on 0.x releases is boring infrastructure yet. But the core abstraction has already earned its place: it names the thing every agent platform was building by hand, and it puts that thing under community governance instead of inside each vendor's moat. If you operate agents on clusters you own, install it in staging, claim a sandbox per session, and let the warm pool teach you what your agents' idle-to-burst ratio really costs. The StatefulSet-of-1 era had a good run. It is over.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
