Google turns the infrastructure behind Gemini’s agents into a cloud service
Agent Compute Engine is Google’s purpose-built platform for running AI agents. It gives each agent a persistent, sandboxed computer rather than just a temporary process. Google Cloud users will receive access in preview later this year. The service aims to combine rapid startup with strong isolation. An agent could run shell scripts, operate a headless browser, or write code with root permissions inside its machine. Each session uses a hardware-isolated microVM. When the agent finishes a tool call, the host checkpoints that microVM, preserving its state until the next call. The system began as internal infrastructure for Gemini, Antigravity, and Google’s model-training pipelines. Google designed it for coding agents, benchmarking, evaluation loops, reinforcement learning, and sandboxed service backends. Its broader goal is a scalable and secure compute platform for Google and its cloud customers.
What is Google’s Agent Compute Engine, and what will Google Cloud users be able to do with it?
Agent Compute Engine is Google’s purpose-built platform for running AI agents. It gives each agent a persistent, sandboxed computer rather than just a temporary process. Google Cloud users will receive access in preview later this year. The service aims to combine rapid startup with strong isolation.
An agent could run shell scripts, operate a headless browser, or write code with root permissions inside its machine. Each session uses a hardware-isolated microVM. When the agent finishes a tool call, the host checkpoints that microVM, preserving its state until the next call.
The system began as internal infrastructure for Gemini, Antigravity, and Google’s model-training pipelines. Google designed it for coding agents, benchmarking, evaluation loops, reinforcement learning, and sandboxed service backends. Its broader goal is a scalable and secure compute platform for Google and its cloud customers.
What is an AI-agent sandbox, and why does Google give each agent its own hardware-isolated microVM?
An AI-agent sandbox is a separated execution environment for an autonomous agent. It lets the agent use tools, files, browsers, and code without directly sharing the host environment. Google’s design gives every session a hardware-isolated microVM, combining container-like speed with sandbox-level security.
For example, a coding agent can run shell scripts and write code with root permissions inside its own persistent machine. The microVM has no secrets in memory or on disk. Its identity is short-lived and limited to that session, while network requests pass through an external proxy.
This matters because agents can run for weeks and may process untrusted instructions. Google’s engineers say coding agents and developer assistants need complete isolation, including kernel- and root-level control. The microVM approach is intended to make escape from one session harder while keeping agents quick to start, pause, and resume.
How large and varied are the workloads this service is designed to support, from coding agents to model evaluations and reinforcement learning?
Agent Compute Engine is designed for both interactive agents and large research workloads. At the small end, an agent can write code, use shell commands, or control a headless browser. At the large end, the platform can run evaluation loops used by frontier labs, AI benchmarking, and reinforcement learning.
A concrete example is a coding agent working inside a persistent computer. It can have root permissions within that machine and continue an agent loop for weeks. The same infrastructure can also host sandboxed backends for Google’s own services. Checkpointed microVMs preserve work between tool calls.
Google says agentic workloads are among the fastest-growing consumers of compute and storage across its fleet. That makes scale and security equally important. The service began with Gemini, Antigravity, and model-training pipelines, then expanded toward Google Cloud customers needing varied, large-scale agent workloads.
What happens to an agent’s microVM while the agent is waiting for a model, user, or tool response, and why does that matter for efficiency?
Agents often spend most of their time waiting for a model, a user, or a tool. Agent Compute Engine responds by checkpointing the microVM after a tool call finishes. The paused environment keeps its state but stops consuming active host resources until work resumes.
For instance, an agent might run a shell command, then wait for a model to decide its next action. Instead of leaving a fully active machine running during that pause, the host saves the microVM’s state. When the next call arrives, the environment can continue with its existing files and memory.
This matters because large numbers of waiting agents could otherwise waste substantial compute. Google built the service for rapidly starting and stopping agent workloads at fleet scale. The checkpointing design supports long-running loops while making idle periods more efficient, which is central to operating many autonomous agents economically.
Who else provides agent sandboxes, and how do Google’s offerings compare with services from AWS, E2B, Daytona, and Kubernetes?
Google is not first to offer agent sandboxes. E2B and Daytona provide them to developers across clouds, while AWS offers AgentCore. Google already provides a managed version of the open-source Agent Sandbox through GKE and sells code-execution and computer-use sandboxes through Gemini Enterprise Agent Platform.
E2B runs each sandbox in a Firecracker microVM and can resume paused state in about a second. Daytona began with containers and added microVM sandboxes, including pause and fork capabilities. AWS AgentCore gives each session a microVM, does not charge CPU while agents wait, and supports sessions up to eight hours; EC2-based runtimes can last up to 14 days.
Agent Compute Engine differs mainly in its origin and scope. It grew from Google’s infrastructure for Gemini, Antigravity, and model training. Google presents it as a unified platform for secure, scalable workloads, including agents that may run for weeks.
What security problem is Google trying to prevent when an agent encounters malicious instructions, and how do isolation, short-lived identities, and controlled network access help?
The security problem is containment. An agent may encounter malicious instructions, and Google wants to prevent it from breaking out of its environment or accessing secrets. The article emphasizes that agents must be trusted not to escape their sandboxes, especially when they receive broad capabilities.
Each session runs in a single-tenant, memory-safe microVM. The environment stores no secrets in memory or on disk. Its identity is short-lived and session-scoped, delivered through one local listener. Traffic is encrypted in transit, while snapshots and disks are encrypted at rest.
The microVM has no standard network interface. Requests pass through an outside proxy, and Agent Gateway checks both the user’s delegation and the sandbox identity before adding a real credential outside the sandbox. These controls limit what a compromised or misdirected agent can reach, while preserving access to approved services such as Google Drive.
How do containers, virtual machines, microVMs, kernels, and virtualization differ, and why might an autonomous agent need more isolation and control than a typical container provides?
A container isolates an application and its files, usually while sharing the host operating system’s kernel. A virtual machine provides a more separate computer environment through virtualization. A microVM is a lightweight virtual machine designed to keep much of that isolation while starting and pausing quickly. Virtualization is the technology that creates and manages these separate machine environments.
This distinction matters for an agent that runs shell commands, writes code, or uses a browser. Such an agent may need root permissions and control over its own kernel-level environment. Google’s engineers say containers can be insufficient for coding agents and developer assistants that require complete isolation.
Traditional VMs offer control and flexibility but can boot, suspend, and resume too slowly for fast-changing agents. Agent Compute Engine therefore uses hardware-isolated microVMs. It seeks the speed of containers with stronger sandboxing and the control needed by autonomous workloads, while checkpointing idle sessions.
This brief was written by AI from the original reporting and checked by other models. Names, figures and quotes come from the source; read it for full context.
Read more in the JupiteX app
Pulse is free. New stories every 4 hours, each one broken into the questions that explain it.
Or read more news on the web