The Warm Sandbox Pool: Infrastructure Economics When Every Agent Task Gets Its Own Machine
If you run coding agents at any real scale, you own a fleet of ephemeral virtual machines. You may not have signed up for that. It happened the moment you decided — correctly — that untrusted, model-generated code should never execute inside your application's trust boundary. Every task gets its own sandbox, every sandbox is a microVM or hardened container, and suddenly the platform team that thought it was building "an agent product" is operating something that looks suspiciously like a miniature AWS Lambda: pool warming, snapshot pipelines, bin-packing schedulers, and a reaper process for the environments nobody came back for.
The trap is assuming your container orchestration instincts transfer cleanly. Some do. But Kubernetes grew up scheduling long-lived, homogeneous services, and agent sandboxes are the opposite: short-lived, wildly heterogeneous, and created at rates that make a deployment rollout look leisurely. The teams that struggle are the ones that treat sandbox infrastructure as "just containers with extra steps." The interesting engineering — and almost all of the cost — lives in four problems: cold starts, filesystem state, packing density, and abandonment.
