A Kubernetes warm pool can prewarm a container, but not a tenant
Which agent state a warm pool can create before a request, and which must wait for an atomic claim.
Plori Tech1 view
What can a Kubernetes warm pool prewarm for a stateful AI agent? This post describes Plori in July 2026, when agents ran in Kubernetes pods from a warm pool. Agents now run in Firecracker microVMs.
The short answer
- Prewarm the runtime, not the tenant. A pool can pay for image pulls, container startup, runtime initialization and blank storage before a request arrives.
- Bind the tenant at claim time. Disk attachment, identity and credentials belong behind an atomic, claim-once transition. In our July 2026 measurement, the tenant-bound step took about a second at the median.
- Fall back to the cold path when late binding fails. We cut wake latency to about 2.6 s median from wake to first streamed token.
What a pool can create before a claim
| State | Safe before a claim? |
|---|---|
| Runtime and image | Yes |
| Blank resources | Usually |
| Existing persistent state | No, not generically |
| Tenant identity and final credentials | No |
An empty volume can sit in a pool without knowing its owner. A volume that holds an agent's repository, artifacts and history carries identity.
When it applies
- After a claim, the sandbox never returns to the pool. Deleting it is cheaper than proving that every process, file, socket, cache entry and in-memory secret was scrubbed.
- If a step fails, discard the sandbox and start through the cold path. Two of our control-plane replicas once selected the same ready sandbox, which briefly caused duplicate pod claims. The fix made the sandbox accept one claimant and reject the rest.
- The design assumes a disposable runtime with durable state elsewhere. If the only valid state is an in-memory process image, snapshot restore or dedicated suspended sandboxes may fit better.
The full post has the claim sequence, the Kubernetes Agent Sandbox API and four common questions.