Ask Kubernetes to run a million web servers and it barely blinks: that's a Deployment, and the whole point is that the servers are interchangeable. Ask it to run a million AI agents — each holding its own session state, its own files, its own half-finished task, each one you'll need to reach by name, freeze, thaw, and eventually throw away — and you discover Kubernetes has no word for what you want.

That gap is what the kubernetes-sigs Agent Sandbox project is filling, and the gap is more interesting than the fill.

Two workload models, neither of them "an agent"#

Kubernetes ships with two mental models for running things, and an agent session falls between them.

A Deployment manages fungible replicas. The design assumes any pod can serve any request, so the pods are deliberately anonymous and interchangeable — that anonymity is the feature that makes rolling updates and autoscaling clean. An agent that has been three tool-calls deep into debugging your repo for twenty minutes is the opposite of anonymous. You cannot route its next message to "any replica."

A StatefulSet manages an ordered, numbered set — pod-0, pod-1, pod-2 — each with a stable identity and its own storage. Closer, but it's built around a fixed cardinality you scale as a unit, like a database cluster. Model a million independent, one-off agent sandboxes as StatefulSets and you're hand-coordinating, in the README's word, a "cumbersome" pile of StatefulSets, Services, and PersistentVolumeClaims — one bespoke bundle per sandbox.

The shape an agent actually needs is stranger than either: a singleton, repeated at population scale. Each sandbox is a herd of one — uniquely addressable, individually disposable, never interchangeable — and there are a million of them. Kubernetes had cattle (Deployments) and it had a small numbered herd (StatefulSets). It did not have a million pets.

The Sandbox CRD#

The Sandbox custom resource names that shape directly. A Sandbox is "a single, stateful pod with a stable identity" — a stable hostname and network identity, persistent storage that survives restarts, and first-class lifecycle operations: scheduled deletion, and crucially pause and resume. An idle agent session can be frozen instead of billed, then resumed exactly where it was. That's a semantic no combination of Deployment and HPA gives you, because Deployments assume a running replica is either present or replaced, never suspended and identical.

Isolation is the other half. Agents run arbitrary generated code, so a container namespace isn't a real boundary — a point worth belaboring, because your container is not a sandbox. The project is built so platform vendors can plug in stronger runtimes like gVisor or Kata Containers, putting a genuine wall between the sandbox and the host — the same microVM-versus-gVisor-versus-Kata tradeoff, now expressed as a Kubernetes resource instead of a bespoke control plane like the ones behind E2B, Modal, and Daytona.

The warm pool is the real trick#

Here's the operational problem the CRD alone doesn't solve. Cold-starting a sandbox — schedule the pod, pull the image, boot it, wrap it in gVisor or Kata — takes seconds. An agent that hits a tool call needing a fresh execution environment, or a user who just opened a new session, needs one in milliseconds. Seconds-to-milliseconds is three orders of magnitude, and no amount of faster booting closes it.

So you stop booting on the critical path. SandboxWarmPool keeps a pool of pre-warmed, already-running sandboxes standing by; SandboxClaim binds one to a request on demand, "abstracting away the details of the underlying Sandbox configuration"; SandboxTemplate stamps them out consistently.

Provisioning happens ahead of time and in bulk; allocation happens instantly and one at a time. The warm pool is a buffer that converts a seconds-long boot into a milliseconds-long handoff.

If that decoupling sounds familiar, it's the same instinct as pre-warming inference capacity when autoscaling LLM serving on Kubernetes: you can't schedule your way out of a cold start, so you pay the latency in advance, off the request path, and keep a ready inventory.

What the primitive is really saying#

It would be easy to file this as one more CRD. But the Sandbox resource is an argument about what the unit of scale has become. For fifteen years, cloud orchestration optimized for replication — make the individual node disposable and anonymous so you can have as many identical ones as you like. Agent workloads invert the premise. The individual node is now the point: it has a name, a memory, a lifecycle you manage one at a time, and it must be cheap to have a million distinct ones.

Kubernetes is, slowly, growing a vocabulary for that. "Sandbox" is the first word.