Google Agent Compute Engine: A MicroVM for Every Gemini Agent, Claimed vs Verified

Google has announced Agent Compute Engine, a service that gives each AI agent its own hardware-isolated microVM. The Decoder reported on October 22, 2026, citing Google, that the service already powers Gemini and will open for preview in the coming months. The performance numbers attached to it (ten times more agents per server, under 500 milliseconds to suspend and resume 200,000 agents) are Google's own claims, and we could not find a published test methodology yet. This post separates what is stated, what is already shippable, and what to check before you plan around it.

Agent sandboxing has been one of the busiest areas of 2026. We have covered Google Cloud's agent sandbox guidance, Perplexity's open-source Firecracker sandbox, Cloudflare Sandbox SDK 1.0 and Tencent's CubeSandbox. Google's entry matters because it is attached to the company's own agent stack.

TL;DR: claimed vs verified

What is Agent Compute Engine?

Running an AI agent that executes code, browses or edits files means giving it somewhere to run. The safe default is an isolated environment so a bad command or a prompt-injected instruction cannot reach other tenants or your host. The usual trade-off is cost: a full virtual machine per agent is expensive, especially because agents spend much of their time idle, waiting on a model response.

Per The Decoder's summary of Google's announcement, Agent Compute Engine attacks that cost in three ways. Each agent runs in a microVM, a stripped-down virtual machine with a small footprint. When an agent idles, its VM pauses and releases the machine for others. And VMs share memory, which Google says lowers the cost of each one. The Decoder also notes that VMs are a large cost factor when providing agent systems, so efficiency is the point.

How does it relate to Agent Substrate?

The Decoder says the same work is behind the open-sourced Agent Substrate, a Kubernetes runtime. IT Brief covered Agent Substrate's availability on Google Kubernetes Engine in September 2026. According to that report:

• It targets teams moving from local agent testing to deployments with hundreds of thousands of concurrent agents.
• Kubernetes handles the machines, while a separate execution layer manages sandbox lifecycles.
• Users can choose Cloud Hypervisor microVMs or gVisor sandboxes for isolation.
• An integrated gateway manages inbound and outbound traffic and applies network controls around agent activity.
• It is tuned for GKE but available as open source for other Kubernetes environments.

So there are two layers. Agent Substrate is the open-source runtime you can run today. Agent Compute Engine is the managed service Google says is behind Gemini, with preview access still to come. The Decoder reports the density and resume figures against Substrate; we have not seen a primary Google page tying each number to a specific product, so we attribute them to Google generally.

Should you believe "10x more agents per server"?

A multiplier needs a denominator. Ten times more than what: one VM per agent on ordinary Compute Engine instances, containers, or an earlier Google design? The source does not say. The figure is plausible in direction, because pausing idle agents and sharing memory pages across near-identical VMs are the classic ways to raise density, and it is the same logic behind snapshot-and-restore sandboxes from other vendors. But a claim of this kind depends on workload. An agent that sits idle 95% of the time packs far better than one that runs tools continuously.

The 200,000-agent resume test has the same gap. Under 500 milliseconds to suspend and resume is a useful latency target for interactive agents, but we do not know whether that number is a median or a worst case, how large each agent's memory was, how many hosts were involved, or whether the resumed agents did any work. If you are sizing a deployment, ask Google for the test setup or reproduce it with your own agent mix.

For context, other vendors have published their own scale claims. We covered DeepSeek's DSec sandbox at 380,000 concurrent sandboxes and NVIDIA's Vera CPU early tests with E2B, Modal and Vercel. In each case the headline number came from the vendor, and the useful questions were about workload and baseline.

What does the governance side add?

Alongside the runtime, The Decoder says Google is expanding governance for agents running in cloud, hybrid and on-premises environments:

• Token tracking: visibility into model usage per agent, which matters when agents loop and run up bills.
• Model routing: directing agent requests to different models.
• Third-party identity providers: support for providers such as Ping Identity and SailPoint, so agents can be tied into existing identity governance.
• Reach: the controls will extend to Cloud Run, GKE and managed endpoints.

This fits a pattern. As agents act on behalf of people, companies want agent identities, spending limits and audit trails like those for human accounts. We saw similar thinking in Walmart's agent gateway with spending limits. The announcement coverage does not say which governance features are generally available versus preview, so check each before you commit.

Why microVMs rather than containers?

Containers share the host kernel, so a kernel bug can let code escape one container and reach others. A microVM runs its own guest kernel on a hypervisor, which gives a harder boundary at the price of more memory and slower starts. Projects like Firecracker and Cloud Hypervisor exist to shrink that price. gVisor takes a middle path by intercepting system calls in user space. Agent Substrate offering both Cloud Hypervisor and gVisor, per IT Brief, suggests Google expects customers to trade isolation strength against density depending on how much they trust the code the agent runs. Agents that execute model-written code on untrusted input sit at the strict end of that range.

The pause-and-resume trick is what makes the economics work. If a VM's memory can be snapshotted and shared pages deduplicated, thousands of mostly idle agents cost far less than thousands of running machines. The unanswered question is what a resumed agent loses: open sockets, running browser sessions and in-memory tool state are all awkward to snapshot, so test your own agent's behavior across a pause.

Is a microVM enough to make agents safe?

No, and the reason is worth stating plainly. Isolation answers "what can a compromised agent reach on the host?" It does not answer "what can the agent do with the access you handed it?" An agent with an email token inside a perfect sandbox can still send the wrong email. Sandboxes also have their own bugs: we covered a KVM zero-day VM escape that affected agent sandboxes. Hardware-backed isolation reduces that risk but does not erase it.

A layered approach works better: isolation for the runtime, least-privilege credentials for tools, network egress limits, and action-level monitoring. For that last layer, AgentBeam, the agent security platform from the explainx.ai team, is built to stop AI agents before they take dangerous actions.

What to do now

1. If you run agents on GKE: read the Agent Substrate repository and docs, and test it with your own tool-heavy and idle-heavy workloads. Measure density yourself.
2. If you are choosing a sandbox vendor: add Agent Compute Engine to the shortlist, but treat it as unavailable until the preview opens. Compare on cold-start, resume time, memory sharing behavior and price.
3. Ask the right questions: What is the baseline for the 10x number? What does one paused agent cost to keep? What happens to open network connections on suspend?
4. Plan governance separately: token tracking and identity integration help, but you still need an owner for agent permissions.
5. Wait for primary documentation: we could not locate a Google Cloud product page for Agent Compute Engine at the time of writing; expect specifics (regions, pricing, limits) to arrive with the preview.

What we could not confirm

We read The Decoder's report and IT Brief's Agent Substrate coverage. We did not find a Google blog post or documentation page for Agent Compute Engine itself in our searches, so details such as pricing, regions, supported languages, maximum VM size and the exact relationship to Gemini products are unknown. We will add an update section when Google's own post or the preview documentation appears.

Related reading

• Google Cloud agent sandboxes: five things about isolation
• Perplexity open-sources its Firecracker agent sandbox
• Cloudflare Sandbox SDK 1.0 for agents
• DeepSeek DSec and 380,000 concurrent sandboxes
• KVM zero-day VM escape and agent sandboxes
• Walmart agent gateway and spending limits

Details are accurate as of October 22, 2026; preview timing, pricing and feature availability may change.