Google opens the agent service behind Gemini to customers — for now, a preview with no date
Google launched Agent Compute Engine on October 22, 2026 at AGNTCon + MCPCon — a compute service built specifically for AI agents, one that already powers Gemini, but which customers will have to wait "in the coming months" to try. Behind the announcement lies a technical insight: agentic workloads break the traditional primitives the cloud is built on. This article explains the mechanisms — per-agent microVMs, copy-on-write memory sharing, and checkpoint/restore during the agent's "thinking phase" — and draws a sharp line between documented architecture and Google's own, independently unverified performance numbers.
The news: a compute service for agent fleets
At the AGNTCon + MCPCon conference on October 22, 2026, Google Cloud launched Agent Compute Engine, described in the company's own blog post as a "purpose-built compute service" that already powers Gemini as an agent for work tasks, and which will be available in preview "in the coming months" with "hardware-isolated runtime sandbox security" (Google Cloud blog, source 54387a98).
It is worth emphasizing what kind of news this is: a service that internally already carries Gemini's agent operation is being opened to external customers, but with no date, pricing, or regions. Readers considering the service for their own operations should therefore treat this as an announcement window, not an availability story.
Alongside the compute service, Google announced expanded governance controls for agents, including token tracking, model routing, and support for third-party identity providers such as Ping Identity and SailPoint, with reach extending to Cloud Run, GKE, and managed endpoints (The Decoder, source 2d829ed6). Google also writes that it is expanding Gemini for business' agent governance features "to support agents where they operate" (source 54387a98).
The problem: the agentic loop breaks VM primitives
The interesting part of the launch is not the launch itself, but the rationale. In a technical "deep dive" written by Google's distinguished engineers Ramanathan Venkatapathy and Rohit Jnagal, the company explains why agentic workloads do not fit the existing options (Google Cloud blog, source 558235af).
The first option, the classic virtual machine, is technically secure but too slow for the usage pattern. "Each VM boots and configures a full machine, so starting, suspending, and resuming one takes seconds to minutes," the two engineers write. An agent that performs many short tool calls with model thinking in between — what Google calls a loop with high "churn" — will then spend more time managing hardware than doing the actual work.
The second option, containers, has fast startup but shares the host kernel with other containers. For coding agents and developer assistants that run arbitrary code, shell commands, and browser actions, that isolation is insufficient where full isolation is required. Neither coding agents nor developer assistants can therefore safely use container environments in such scenarios, according to the deep dive blog post.
The architecture: brain and hands, separated
Google's solution builds on a distinction that mirrors how agent frameworks actually work. "Both teams split each agent into two parts. The harness, or 'brain,' calls the model and decides what to do next. The sandbox, or 'hands,' runs the code, shell commands, and browser that the model requests," Venkatapathy and Jnagal write (source 558235af).
Agent Compute Engine gives each agent its own hardware-isolated microVM — that is, a lightweight virtual machine with its own kernel-space isolation, not a container — but with container-level startup speed. Google's wording is that the service gives "each AI agent its own hardware-isolated microVM with container speed and zero credentials held inside the sandbox" (source 558235af). The last point is central to security: even if an agent is compromised from the inside, it should not have access to credentials in its own environment. Google's deep dive also indicates that this builds on the company's Titanium silicon/IPU foundation, though the details in the supplied documentation are limited.
Two mechanisms make the whole thing affordable at scale. The first is memory sharing: according to the launch blog post, Agent Compute Engine uses "copy-on-write memory sharing to run multiple agents on a single operating system template" — that is, many microVMs share the same base memory and write only their own changes to separate memory (source 54387a98). The second is checkpointing: "When an agent finishes a tool call and enters the 'thinking phase' of the agentic loop, the microVM signals it is idle, and the host moves it from an active to an inactive state," the same source states. In practice, this means that while the model thinks, the agent's machine is frozen via a fast checkpoint and can be restored instantly when it needs to act again.
It is an elegant move: the most characteristic feature of agentic workloads — long pauses of thinking between short bursts of action — is used as the signal for when hardware can be released.
Scale and governance: Agent Substrate and the controls around it
Under the hood, according to The Decoder, lies "Agent Substrate," a Kubernetes runtime that Google has open-sourced. The performance figures cited are clearly Google's own: the company says the solution can fit "ten times as many agents on a single server," and that suspend and resume took "under 500 milliseconds" in a test with 200,000 agents, according to The Decoder's coverage of Google's claims (source 2d829ed6). None of these figures have been independently verified.
On the governance side, Google is expanding token tracking, model routing, and support for identity providers such as Ping Identity and SailPoint, affecting Cloud Run, GKE, and managed endpoints (source 2d829ed6). The combination is meaningful: if agent fleets are to operate with their own machines and no credentials in the sandbox, the organizations on the outside need tools to see what the agents are actually consuming (tokens), where they are routed (which models), and who stands behind their identity.
What we don't know
There are significant gaps. First: the performance figures — 10x density and sub-500 ms suspend/resume — are exclusively Google's own, relayed through The Decoder, which cites "Source: Google." There is no independent benchmarking in the available documentation, and the two Google blogs cannot be counted as independent confirmation of each other; both are the company's own voice.
Second: the description of Agent Substrate as open source is based on The Decoder's wording. There is no first-hand Google documentation of the actual release in the supplied material — no information about a repository, license, or which code is actually available. For organizations considering building on the runtime, this is a concrete and followable deficiency.
Third: the preview window is undefined. "In the coming months" without dates, pricing, or regions means that any planning now rests on an announcement, not on an available product.
What remains is a clear architectural proposal: separate the agent's brain from its hands, give the hands their own hardware-isolated microVMs, exploit the thinking phase as a checkpoint pause, and keep the credentials away from the sandbox. Whether this holds up as convincingly in practice, we will only know when the preview window opens and someone outside Google has measured the numbers themselves.