Google Built a Scheduler for Agents That Mostly Wait

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. Google describes a choice of Cloud Hypervisor microVMs or gVisor sandboxes, not one virtual-machine layer built from both. Its snapshot path uses local disk and Cloud Storage; optional Filestore volumes provide persistent shared files. Resuming execution state and reattaching a filesystem are different operations, with different failure and recovery questions.

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.

Resume is not proof of recovery

For a disposable evaluation, I would record a sequence number in process memory and a separate marker in a persistent file, then suspend and resume the sandbox. Repeat after losing the worker rather than performing a clean suspension. Record which state survives and how long it takes to recover. A successful warm resume does not establish recovery from an interrupted snapshot or a lost node.

I would also expire a dummy credential while the sandbox sleeps and verify that resumption does not restore access that has been revoked. Restoring memory can bring back an old token; authorization still has to be checked by the service receiving the request. These are proposed evaluation cases, not tests I have run on GKE.

Measure the workload you intend to run

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.

Google’s September 15 announcement, rechecked October 10, describes non-production access for GKE customers and production GA via allowlist. That makes this architecture worth studying now, but not something I would quietly make a production dependency before testing failure and recovery paths.

Source

Google Cloud: Agent Substrate available on GKE.

Correction, October 10, 2026: Cloud Hypervisor and gVisor are alternative isolation options. The earlier wording incorrectly combined them and blurred execution snapshots with persistent file storage.