Google Cloud announced Agent Compute Engine on October 22, 2026, at its AGNTCon + MCPCon event. It enters preview in the coming months, and it already runs the Gemini agent for work tasks. Google also presented Agent Substrate, an open-source runtime for Kubernetes, and a wider set of governance controls.
What was actually released
Agent Compute Engine is compute built for the shape of agent work rather than for long-lived servers. Google says every Gemini agent gets its own high-performance, secure computer to act upon: a microVM behind a hardware-isolated boundary, with its own guest kernel, root access and identity, carrying short-lived credentials. Customers will be able to run their own agents on it in preview.
The lifecycle is where the design parts ways with one container per agent. Google runs many microVMs on a single operating system template through copy-on-write memory sharing, and stops the idle ones with checkpoint and restore. When an agent finishes a tool call and enters the thinking phase of its loop, the microVM signals that it is idle, and the host moves it out of the active pool. An agent waiting on a human or an outside system can be paused and resumed from a snapshot instead of being kept warm at full cost.
Two pieces sit under that. Each microVM carries its own Hyperdisk, so a workspace and its context survive across long sessions, and the isolation runs on Titanium, Google’s infrastructure processing unit, with credentials injected at egress, outside the agent’s reach.
Agent Substrate is the second product: an open-source execution runtime on Google Kubernetes Engine that decouples agent execution from machine management. When an agent goes idle, its active memory is snapshotted, the machine returns to the pool, and the agent resumes when needed. Google says the runtime works with any agent framework or harness, and names Claude Code, OpenClaw and Hermes.
The third block is governance, and it is where most of the shipping happens. Agent Gateway routes traffic between clients, agents and tools, Agent Registry holds the approved agents, tools, MCP servers and endpoints, Agent Identity gives each agent a SPIFFE-based identifier used for access control and audit, and observability emits OpenTelemetry traces for every model call and agent hop. Those controls now reach Agent Runtime, Cloud Run, Agent Sandboxes in the Gemini platform, GKE and Agent Compute Engine, with cross-cloud enforcement points in preview soon. Token and cost governance, model routing and delegated authorization with Ping Identity, SailPoint and Saviynt are planned as previews this quarter.
What the claim rests on
The numbers Google published alongside the launch are density and latency figures, and they belong to Agent Substrate rather than to Agent Compute Engine. That distinction matters, because the headline number will be quoted against the wrong product.
| Claim | Figure published | What it covers |
|---|---|---|
| Compute density | up to 10x | Agent Substrate on GKE, against traditional compute |
| Activation rate | 500 per second | Agent Substrate, benchmark of 200,000 agents |
| Suspend and resume | under 500 ms | Same benchmark, same runtime |
| Availability | preview in the coming months | Agent Compute Engine |
| Runtimes under governance | 5 | Agent Runtime, Cloud Run, Agent Sandboxes, GKE, Agent Compute Engine |
Figures as published by Google Cloud on October 22, 2026, reproduced as the company’s own runs. The baseline behind the 10x density figure is described only as traditional compute.
Google states the 10x figure without naming the machine it compared against, and the 500 activations a second comes from what the page calls benchmark validation running 200,000 agents, with no harness, no hardware and no competing runtime published next to it. For Agent Compute Engine itself, the page gives no boot time, no per-agent concurrency limit and no price: preview in the coming months is the only date in the announcement.
Scaling the Gemini agent to planet scale requires compute that spins up rapidly and operates with extreme efficiency.
That is Gautham Thambidorai, a Google vice president and Google Fellow on Gemini, quoted on the page. It is a statement of intent from the team that built it, not a measurement.
What is not published
No price per agent-hour or per microVM, no general availability date, no service level, no regional list, and no independent test of the isolation claims. The only performance numbers on the page cover a different product, on a baseline Google does not define.
On this page
What it changes for teams paying for agents
An agent that waits is the ordinary case: waiting on a tool call, on a human approval, on a slow API of a partner. On one container per agent, that waiting time still holds its allocation, and the bill tracks the number of parallel agents rather than the work they do. Pausing an idle microVM and resuming it from a snapshot changes the shape of that cost, and it is the mechanism that makes a fleet of thousands of agents arguable on a normal budget, provided the per-hour rate lands where a buyer needs it.
The governance block matters for a different reason. Registry plus per-agent identity is what turns an agent deployment into something an auditor will accept: a list of what is allowed to run, a signature on every call, and a trace per hop. Teams already on Gemini for business get that as configuration. Teams running agents across several clouds wait for the cross-cloud enforcement points, still in preview.
Google ran Agent Compute Engine on its own Gemini agent before selling it, the same way it put the Gemini agent for work into Workspace first, which we covered when it shipped on October 8, 2026: Google Cloud launches a Gemini agent with hard spend caps. The preview will be the first time the isolation claims run against code Google does not write.
The Neural Minute take
The microVM is not the news, and it is not where the money is. Google is describing agents the way a utility describes load: an identity, a budget, a registry of what may run, a meter per token. The control plane is what lets a company sign off on a fleet, and it is being extended to Cloud Run, GKE and multicloud.
Our reservation is the one a buyer should have. A vendor benchmark of 10x density, against an unnamed baseline and with no per-agent-hour price, is not a cost argument, it is a slide. When both numbers arrive, the comparison will be between cost per thousand agent-hours on Agent Compute Engine and cost per thousand agent-hours on the containers a team runs today.
One detail for anyone running agents on their own metal: the open-source path is the one with the numbers attached. Agent Substrate sits on GKE under an open repository, so suspend and resume can be tested now.
Sources
- Introducing Agent Compute Engine and expanded agent governance, Google Cloud blog, published October 22, 2026, read on October 23, 2026: https://cloud.google.com/blog/topics/ai-infrastructure/introducing-agent-compute-engine-and-expanded-agent-governance/
- The technical deep dive linked from that page, for the microVM architecture: https://cloud.google.com/blog/topics/ai-infrastructure/agent-compute-engine-deep-dive/
- Figures quoted here, all from the announcement page: up to 10x compute density for Agent Substrate, 500 activations per second and under 500 ms suspend and resume latency in a benchmark of 200,000 agents, preview in the coming months for Agent Compute Engine, five runtimes under governance
- The quote from Gautham Thambidorai and the description of the lifecycle are taken from the announcement page as published; no independent test of those claims was published with the launch