The article, likely from a Google Cloud product team, addresses a core economic problem in running AI agents at scale: agents operate in bursts with long idle periods, yet static VM-based deployments (e.g., OpenClaw on microVMs) waste compute during idle time. The team tested the maximum number of OpenClaw agents that can be packed onto a single n2-standard-48 GKE node (48 vCPUs, 192 GB memory) without performance degradation or failures.

Baseline: Running each agent inside a dedicated microVM (Kata containers) hit a scaling wall at 61 agents. The guest OS overhead consumed resources that could otherwise serve agents.

Optimization 1 – GKE Agent Sandbox: Migrating from microVMs to GKE Agent Sandbox, built on the open-source gVisor (a user-space kernel that intercepts system calls), reduced sandbox overhead. This allowed 88 agents on the same node – a 44% increase in agent density and a >30% cost reduction per agent, while maintaining the security isolation needed for untrusted multi-tenant workloads. The article notes that after GKE Agent Sandbox reached GA in May, its usage grew 7× in under four weeks.

Optimization 2 – Orchestration with suspend/resume: To address agent idle time, GKE Pod snapshots can checkpoint and freeze idle agents to persistent storage, releasing CPU and memory. When a new task arrives, a controller resumes the agent from the snapshot in milliseconds. This enables oversubscription of physical compute, but the article explicitly warns that oversubscription is not one-size-fits-all. Different agent types have different latency sensitivities:
– Latency-sensitive (e.g., real-time coding assistant) require sub-second startup, handled by Agent Sandbox Warm Pools (pre-warmed, isolated sandboxes).
– Balanced (e.g., interactive background agents) tolerate a few seconds; GKE suspend and resume restores them on demand.
– Latency-tolerant (e.g., scheduled cron jobs) can queue for capacity, allowing maximum oversubscription.

Results: With performance-optimized configuration (warm pools for sub-second startup during spikes), the node ran 133 agents. With cost-optimized configuration (high oversubscription, startup under 5 seconds), the node ran 274 agents – over 3.5× the baseline density – and the article claims cost reductions of up to 75% per agent. The key takeaway is that combining GKE Agent Sandbox with suspend/resume allows packing far more agents onto fixed compute, but the tradeoff between latency and density must be tuned per workload.