Google opened Agent Compute Engine, the microVM runtime behind Gemini's agents

A team running agents in production has had to assemble its own sandbox stack, because the hyperscalers served only half the primitives and the pure-play sandbox startups were new. Google announced Agent Compute Engine on Thursday at the AGNTCon and MCPCon conferences in San Jose, naming it as the compute service that already runs Gemini as an agent for work tasks. Google Cloud customers will get it in preview later this year.

The post, co-signed by three Google VPs (Nirav Mehta, Michael Bachman and Kevin Hutchins), describes the mechanism as a hardware-isolated microVM per agent session. Google says every agent gets "its own high-performance, secure computer to act upon," paused with memory and disk intact when the agent is waiting on a model or a tool call, and resumed when the next call arrives. The design brief, in the authors' own words, was that "traditional compute primitives are excellent for standard workloads, they weren't optimized for the unique lifecycle patterns of AI agents."

What is in the box

Each agent session runs in a single-tenant microVM on Cloud Hypervisor, with its own guest kernel and root access. The host is a stateless appliance with a read-only filesystem whose hardware and firmware are cryptographically verified at boot. Google's own Titanium offload processor sits beneath that. The microVM carries no secrets in memory or on disk; its identity is a short-lived, session-scoped credential handled by a per-VM local listener. All traffic in and out routes through a proxy outside the sandbox, and when the agent needs to reach a service such as Google Drive, Google's Agent Gateway checks the user's delegation and the sandbox's identity before adding the real credential, outside the sandbox.

Persistent state uses Hyperdisk attached to the microVM. The runtime can keep multiple agents on one OS template through copy-on-write memory sharing, and it ships with the checkpoint-restore pattern that other sandbox products already use. Gal Dalal, a Google product lead quoted in the post, says the microVMs "give us the responsiveness, hardware isolation, and workload density needed to deliver interactive agent sandboxes to our users around the world."

Who already has an answer here

The sandbox-per-agent primitive is not new. AWS Bedrock AgentCore gives every agent session a microVM, now with EC2-based runtime for shared sessions up to 14 days (14 days was added in August). E2B runs each sandbox in Firecracker, the microVM technology AWS built for Lambda. Daytona started on containers and added microVMs in July. Google already ships Agent Sandbox as an open-source Kubernetes project, and Agent Substrate on Google Kubernetes Engine extends the same pattern. Nous Research is named in the post as a customer, with its CEO quoted saying Agent Substrate let it build per-agent isolation and extensible access control at the platform layer.

Agent Compute Engine's position in that list is that it is the exact runtime that already carries Google's own agents. Nirav Mehta's team says agent workloads are "one of the fastest-growing consumers of compute and storage" across Google's fleet. A team building its own agents can now sit next to Gemini on that runtime, which is a different scale-tested environment than the three pure-play sandboxes offer. Pricing was not published and the preview date is "in the coming months". A team adopting it should sign up to preview, port a single agent to it on a representative workload, and watch the per-session cost against its current sandbox before moving the rest.

Source

Google Cloud: Introducing Agent Compute Engine and expanded agent governance, by Nirav Mehta, Michael Bachman and Kevin Hutchins. Press coverage: The New Stack: Google turns the infrastructure behind Gemini's agents into a cloud service.