Analysis
Google Built a Scheduler for Agents That Mostly Wait
Google’s Agent Substrate for GKE is built around an awkward workload: thousands of isolated processes that spend much of their time waiting for a model, a person, or another tool. Keeping every sandbox fully running wastes memory. Starting a fresh pod for every turn wastes time.
Google’s answer is to suspend idle agent environments and resume them when work arrives. The company reports resume times below 500 milliseconds, more than 500 activations per second, and roughly 1,000 dormant agents on one host. Those are Google’s measurements, not numbers I independently reproduced.
Ordinary autoscaling solves a different problem
Kubernetes is good at placing long-running services and finite jobs. An interactive agent is neither. It may execute for seconds, wait for minutes, retain a large working set, and then need to continue with low latency. Deleting the environment loses local state; leaving it running reserves resources for an idle process.
Agent Substrate adds a lifecycle between running and gone. A lightweight virtual-machine boundary built with Cloud Hypervisor and gVisor can be paused while its persistent workspace survives elsewhere. A request wakes the sandbox rather than rebuilding the world.
Density changes the failure domain
Google claims about ten times the sandbox density of a conventional deployment. That improves cost only if the control plane, storage path, and wake-up queue can absorb the concentration. A host failure may now interrupt hundreds of dormant sessions. A storage slowdown can become an activation storm. Capacity planning moves from steady CPU use toward concurrent resumes and working-set restoration.
The egress proxy is equally important. A sandbox boundary without network policy still lets an agent reach package registries, internal APIs, metadata services, or arbitrary external hosts. Central egress makes destination policy and auditing possible even when sandboxes are created quickly.
The scheduler is parking computers, not jobs
I would evaluate this less like a new Kubernetes add-on and more like a fleet of tiny, resumable workstations. Measure cold and warm activation, storage consistency, identity lifetime, egress enforcement, noisy-neighbor behavior, and recovery after a node disappears. The agent framework above it matters less than whether those operational promises hold.
Non-production access is broadly available; Google says production general availability is currently allowlisted. That makes this architecture worth studying now, but not something I would quietly make a production dependency before testing failure and recovery paths.