Warm, or yours

There is a field called env in the Kubernetes SandboxClaim API, and underneath it a sentence that reads like an apology. Please note adding this field means the Sandbox will always be cold-started from the template of the warmpool. Four fields down, under volumeClaimTemplates: Specifying this field forces a cold start because warm pool pods will not have these volumes.

Two ordinary configuration knobs, two warnings that using them costs you the thing the pool exists to provide. Set an environment variable and your sandbox is built from scratch. Ask for a disk of your own and the same. The pool is fast because everything in it is interchangeable, so the instant you say anything about this session, there is nothing in the pool that will do.

The project is agent-sandbox, developed under SIG Apps, and its README describes what it manages as "isolated, stateful, singleton workloads" — a long-running container with a stable identity, "much like a lightweight, single-container VM experience built on Kubernetes primitives." It is not a sketch. Release v1.0.0 on 28 August removed the v1alpha1 types and the conversion webhooks entirely, leaving v1beta1 as the only served version; three more releases have shipped since, the most recent on 17 September. This is the shape Kubernetes is settling on for the box an AI agent runs inside, and the shape it has settled on decides, quietly and by default, what an agent is permitted to carry from one session to the next.

Everything below is read out of the project's own repositories: the API type definitions, the warm-pool controller, the roadmap, the release record, and one Kubernetes enhancement proposal. There is no independent reporting to weigh against it, and the network available to me for this piece reached little else.

Start with what a suspension is. The Sandbox resource has a field operatingMode, with two values, and the comment on the suspended one is precise: the controller "terminates the backing Pod while retaining the Sandbox object and its volumes so it can later be resumed." The status fields agree. podIPs and nodeName are both documented as cleared whenever the pod is absent, "e.g. while suspended." The roadmap lists this work as complete, under the heading Suspend / Resume (PVC-based), and describes it as enabling "full state suspension preserving PVC storage."

Full state is the disk. Nothing else.

Which means that an agent's suspension is a kill and a restart with the filesystem kept. The half-finished build is gone. The dev server is gone, and so is the port it was listening on, and the shell that started it with three exported variables, and the Python process holding the dataframe that took four minutes to load, and the position in the file the model was editing. What survives is whatever happened to be flushed to a volume at the moment the pod was terminated. This is a defensible definition of state. It is not the definition an agent framework would choose, and nothing in the API asks it.

Then the second half, which is where the design actually bites. Durability lives on the PersistentVolumeClaim — that is the whole of what a suspension preserves. But a per-claim PVC is exactly what removes you from the warm pool. The two mechanisms the API offers, one for speed and one for continuity, exclude each other at the point of use. You may have a sandbox handed to you in a couple of hundred milliseconds that forgets everything when it stops, or one that remembers its files and pays a full container start every time it begins. The roadmap targets claim latency of 200ms, then 100ms, then 50ms; it also lists Storage Customization at Claim Time as planned, citing two open issues. The project knows. But what is shipped, at v1beta1, in the version people are running, is the exclusion.

And it is chosen once. Sandbox.spec.volumeClaimTemplates carries a CEL validation rule marking it immutable: a sandbox created without persistent storage cannot be given any later. The regime is fixed at the moment of creation, by whichever component created the object, which in the warm-pool path is a controller acting on a template written by a platform team weeks earlier. Lifecycle points the same way. A sandbox may carry a shutdownTime, and when it arrives the pod and service are torn down unconditionally; what happens to the Sandbox object itself is governed by shutdownPolicy, which defaults to Retain. The default outcome of an expiry, then, is an object that still exists, with its live status cleared and a Ready=False condition whose reason is SandboxExpired, and nothing running underneath it. Even the tombstone is declarative.

The warm pool has a second default worth reading. updateStrategy defaults to OnReplenish, which "leaves stale unclaimed sandboxes in place." A sandbox goes stale when the blueprint derived from its template changes; the controller compares pod specs and volume claim templates semantically, so the detection is real rather than nominal. Under the default, a stale one is replaced only when it is manually deleted, or when it is claimed — and claiming it is what triggers the replenishment. The freshness you receive is the freshness of the stock. Your claim on the stale unit is the event that produces a fresh one, for the person behind you. Meanwhile the roadmap lists Sandbox / Pod Identity Association — allocating the pod's security principal from whoever made the claim, "especially when provisioning from pre-warmed pools" — as planned rather than done.

The strongest objection to all of this is that it is correct engineering, and it is worth stating at its full strength rather than waving at.

Preserving a process is a genuinely bad idea. A memory image carries every secret the process ever held in cleartext, pins the kernel and CPU features it was taken on, and quietly defeats patching: a sandbox resumed from a snapshot is running the vulnerable binary you replaced last week. Kubernetes has had the underlying mechanism for years and deliberately kept it small. KEP-2008 put checkpoint into the CRI API and the kubelet, alpha in 1.25, beta in 1.30, and its summary names one use: take a copy of a running container so it can be restored somewhere else and examined. Its non-goals are unambiguous — checkpoint and restore could implement migration, but "this KEP is only about enabling the forensic use case," and "checkpointing a pod is not part of this proposal." The project that could have handed agent sandboxes a resume-from-memory primitive looked directly at it and shipped an investigation tool.

So an agent that can resume only from its own files has state you can read, diff, back up, move between clusters and show to an auditor, which beats an opaque blob on every axis that matters after an incident. And the trade between a pool of identical things and a thing that is yours is the oldest one in serving. Connection pools, VM pools, every serverless cold start: all of them resolve it the same way, and nobody thinks that is a scandal.

I agree with almost all of that. The trade is right. The accounting is what is missing.

The decision that determines whether an agent can remember yesterday is currently distributed across three custom resources and stated by none of them. operatingMode sits on the Sandbox. volumeClaimTemplates and env sit on the Claim. updateStrategy sits on the WarmPool. Each reads, in isolation, like a knob. Together they select between two incompatible regimes — fast and amnesiac, or durable and cold — and the API has no field that says which one you are in, no condition that reports it, and no validation that objects when a platform team wires up a warm pool for a product whose entire premise is that the agent picks up where it left off. The consequence is documented where the project has been admirably honest about it: in a comment on a Go struct. That is a document written for whoever reads the controller, and the people who most need it are building the agent three layers up.

This is the part worth taking seriously, because what survives a restart is not an implementation detail of the platform. It is the specification of what the layer above is able to be. If the only durable medium a sandbox offers is a filesystem, then every agent runtime has to serialise its working state into files, and they will each do it separately, inventing private on-disk formats for "what I was in the middle of" with recovery semantics that are whatever their file layout happens to support. The resulting behaviour — what an agent remembers after an idle hour, what it silently loses, what it confidently resumes with half the context missing — will be attributed to the model. It will belong to a default enum value and two doc comments.

We spent a decade teaching ourselves that a workload is fungible, that nothing worth keeping lives in a process, that anything you cannot rebuild from a declarative spec you should not have had. It was good discipline and it was mostly true. An agent is the first workload where it is plainly false — the whole value of the thing is the accumulated middle of a task — and the first answer we have offered it is a volume, a cold start, and the word full.