Why Google's MicroVMs Deliver 10x Agent Density (And What It Costs You)

Google ran 200,000 agents through suspend and resume in under 500 milliseconds, and held 500 activations per second while doing it. That number is the announcement. Not the model, not a benchmark score. The scheduler.

If you run agents today, that number is your bill. Every agent you keep resident holds CPU and memory whether it is thinking or waiting, and agents wait almost all the time. Google measured it: at any moment, only a small portion of open sessions were running code. So it stopped paying for the wait, froze the idle machine, and handed the hardware to the next agent. Ten times the agent density on a single server is the claim that falls out of that.

PhantomByte has argued the runtime is the product, most directly in "Your Agent Needs a Runtime, Not Prompts" in July. Now a hyperscaler has put unit economics on the record, which makes the claim checkable.

One correction before the arithmetic, because it changes what you are actually copying. The 10x density figure and the 200,000-agent benchmark belong to Agent Substrate, Google's open-source Kubernetes runtime, which shipped on GKE on September 15, 2026 and was restated inside the October 22 Agent Compute Engine announcement. Agent Compute Engine itself, the managed service that puts every Gemini agent in its own microVM on Titanium silicon, publishes no density number, no boot time, and no price. The trade coverage merged the two. They share an architecture, not a scorecard, and the distinction matters when the 10x has to survive your workload.

WHAT A MICROVM BUYS YOU

A microVM is a lightweight virtual machine with its own guest kernel, booted in milliseconds instead of minutes, sitting behind a hardware virtualization boundary instead of sharing the host kernel the way a container does.

That boundary buys three things. Blast radius, because an agent that reaches root inside its own guest has escaped nothing. Credential boundaries, because a sandbox compromised without exposing a key is a sandbox you can put a browser in. And quiet neighbors.

What it used to cost is why per-agent isolation stayed a demo. A resident VM charges rent on a full machine, and at the duty cycle Google measured, that rent is paid mostly for nothing. Pay a full VM for every wait and the economics collapse before you reach a hundred agents.

THE THREE MECHANISMS

Mechanism one is the unit of isolation. Every Gemini agent session runs in a single-tenant microVM behind a Cloud Hypervisor boundary, with its own guest kernel and root access. The security root is not software. Google's Titanium infrastructure processing unit holds the attestation keys outside the guest, so a compromised sandbox cannot reach the keys that would let it out.

Mechanism two is the pause, and this is the part that produces density. Google co-designed the sandbox runtime with the host executor so the infrastructure knows when an agent finishes a tool call and enters the thinking phase. That is the signal to checkpoint. Guest state is snapshotted to disk and Cloud Storage, the microVM is unscheduled, and the host keeps zero active resources against it. When the next tool call arrives, the snapshot restores in under 500 milliseconds.

Mechanism three is shared memory, and it is where per-agent cost actually falls. Google builds pre-warmed snapshot images with binaries already initialized, maps them into physical memory with Direct Access, and clones them copy-on-write. Every microVM on a host points at the same physical pages for the base OS, libraries, and interpreter. Memory is allocated only for private pages an agent dirties, and reclaim returns freed pages to the pool. A hundred agents on the same Python stack stop costing a hundred copies of that stack.

THE DENSITY TRADEOFF TEST

Three questions decide whether per-agent isolation pays for your fleet. I call it the Density Tradeoff Test, and it costs an afternoon to run.

The first is duty cycle, meaning the fraction of wall clock time your agents actually execute. The arithmetic is one line. If an agent executes 10 percent of the time, then ten agents need one agent's worth of active compute on average. Pausing the idle nine frees the machine roughly 90 percent of the time, and the density ceiling becomes 1 divided by 0.1, which is 10. That is where an order of magnitude claim comes from. It is not a virtualization trick, it is a duty cycle trick with a hypervisor attached.

The second question is state weight, meaning how much memory one session holds, and how much is private rather than shared. Run it with stated assumptions, since Google does not publish the private delta. Take a warmed base image at 3 GiB and a private delta of 300 MiB per agent. Two hundred agents holding full copies at 3.3 GiB each need 660 GiB, which does not fit on a 384 GiB machine. Two hundred agents on copy-on-write need 3 GiB once plus 200 times 0.3 GiB, which is 63 GiB. That is a 10.5x cut in physical memory from the memory mechanism alone, before anyone pauses anything. Those are my numbers, not Google's, and the ratio is dominated by how much of your footprint is shared. An agent carrying a large, unique, dirty heap does not get it, and that heap grows. A long-running agent accumulates state as it works, context, tool output, caches, and the files it wrote, and most harnesses release none of it until the task ends. Google's reclaim and compression return pages only after an agent frees them, so an agent that holds everything it touches keeps every dirty page resident. Budget the private delta for the end of a long task, not for the snapshot you measured on day one, or the density estimate decays exactly on the sessions you care about most.

The third question is wake latency budget. Google resumes a sandbox in under 500 milliseconds and packs over 1,000 dormant agents per host. If your agent class tolerates that resume, pause it. If it does not, you are buying isolation without buying density, and you should book it as a security feature rather than a cost saving.

WHERE THE 10X CLAIM BREAKS

The claim is about density, not throughput. Ten times as many agents resident on a host does not mean ten times the work, because a resumed agent still has to run. Density buys session capacity. Throughput is set by model latency, tool latency, and what the agent does after it wakes.

Long-lived state is where the number really bends. An agent that wakes every few seconds pays the thaw cost on every wake, and once wakes outnumber the work, the checkpoint machinery becomes the workload. An agent holding tens of megabytes of live context pays to restore it each time, and shared memory does nothing, because private pages are private. The pattern to watch is thrash, meaning pause and resume on a session too short to amortize the snapshot.

The latency budget is the second break. Sub-500 millisecond resume is excellent for a background agent and wrong inside a request path with a 50 millisecond budget, which is why routing and affinity still dominate time to first token, the point of "Your Inference Bill Is Set by Routing, Not Weights. Session-Affinity Just Cut Time to First Token 85 Percent."

The third break is the baseline. The 10x is measured against standard container runtimes, so a fleet already tuned and oversubscribed lands under the headline.

The fourth is what Google did not publish. There is no memory-per-microVM figure, no resume distribution beyond the sub-500 millisecond ceiling, no boot time, and no price. A p50 resume under 500 milliseconds and a p99 resume under 500 milliseconds are different products, and the blog gives you one bound. Treat it as an upper bound on one workload shape, and note that the 200,000 figure is a fleet benchmark, not 200,000 agents on one host.

WHY THE IDENTITY PLUMBING MATTERS AS MUCH

Isolation without identity is a jail with the door open, and Google shipped both together.

The technical writeup is specific here. A sandbox holds no credentials and no standard network interface. All traffic crosses an isolated virtio-vsock boundary to a local proxy and then to an Agent Gateway that validates three things, the user's delegation, the workload identity, and the Titanium-attested node identity. Then it performs an in-flight token swap, inserting the real backend credential on the wire. The sandbox never sees the key it acts with.

There are four identities per workload. The user, a delegated on-behalf-of grant kept in a central authorization service rather than on the node, a short-lived SPIFFE workload identity used for sandbox traffic, and a workforce identity for an agent with its own account. A stolen workload identity cannot call a backend API directly. It identifies which sandbox sent a packet.

That is the boundary drawn in silicon instead of a prompt, the argument in "The Model Proposes. The Runtime Decides: Why Agent Safety Lives in the Execution Boundary." The release adds token tracking, model routing, governance across Cloud Run, GKE, and managed endpoints, and identity providers including Ping Identity, SailPoint, and Saviynt. Isolation gives you a hardware-enforced blast radius. Identity is what makes that radius mean something to a security reviewer.

WHAT TO DO TODAY

1. Measure your fleet's duty cycle first, logging execution time against wall clock time per agent for one week. Pausing only pays below full utilization.
2. Weigh your agent state. If sessions hold tens of megabytes of live, unique context, model the thaw cost before you adopt suspend and resume, since shared memory will not cover pages the agent dirtied.
3. Set a wake latency budget per agent class, and pause only the classes whose budget tolerates 500 milliseconds.
4. Read the Agent Substrate runtime, since it is open source, runs on any Kubernetes cluster, and lets you run a variant on hardware you already own.
5. Attach identity at the VM, not the prompt, putting workload identity through your existing identity provider so isolation and attribution ship together.
6. Re-run the density math quarterly, because hardware generations move and agent duty cycles move faster.

THE UNCOMFORTABLE QUESTION

If your agents shared a runtime yesterday and one of them misbehaved, how would you know which one it was, and what could you have done about it? If the answer is read the logs and hope, Google just showed you what your platform is missing.

The runtime is the product, and the unit of design is now a wake latency budget.