Google describes Agent Compute Engine (ACE) as infrastructure that runs each agent session in a persistent, hardware-isolated microVM, with one component directing the work and another executing it. The design aims to combine virtual-machine-style isolation with container-like speed and density. Google’s October 22, 2026, engineering deep dive says a Google Cloud preview was targeted for the coming months.
For an AI or cloud team, the central idea is a firm boundary between the agent’s decisions and the code or tools that carry them out. Google says ACE was developed for internal workloads including Gemini, Antigravity, and evaluation and reinforcement-learning pipelines.
The harness directs work; the sandbox runs it
The harness is the component outside the execution environment that calls the model, chooses actions, and sends commands. The sandbox is the isolated environment that runs the requested code, commands, and browser operations, then returns their output. Google describes a dedicated microVM for each agentic session.
This division separates orchestration from execution. The harness can decide what the agent should try; the sandbox provides the environment in which those actions run. Google’s design is intended to give that environment operating-system control while isolating each session at the hardware level.
How identity and credentials stay outside the sandbox
Google says ACE keeps persistent user credentials, API keys, OAuth refresh tokens, and service-account keys out of the sandbox guest. Instead, sandbox traffic uses a short-lived Agent Workload Identity, based on SPIFFE, to identify the workload.
An external Agent Gateway checks the user’s delegation, the agent and node identities, and egress policy before brokering a backend credential to its destination. Google also says sandbox traffic travels through mediated paths rather than a standard virtual network interface or direct VPC access. The gateway therefore sits between code running in a microVM and the services it needs to reach.
What happens when an agent waits
When an agent finishes a tool call and waits for its next step, Google says the runtime signals that it is idle. The host then checkpoints the session, preserves its state for later resumption, and releases active host resources. Google describes idle sessions as using zero active host resources; that is the company’s account of the design, not a measured cost or resume-time result.
ACE also uses memory sharing to reduce duplication across microVMs on a host, according to Google. Direct Access (DAX) and copy-on-write clones allow sessions to share unchanged pages from warmed images, runtimes, libraries, and binaries. A modified page remains private to the session that changed it.
Google divides agent data into three categories:
| Data category | Role | Storage model |
| Ephemeral scratch data | Temporary data for an agent’s work | Scratch overlay |
| Read-only or shared data | Images, toolchains, and package caches used across sessions | Shared, read-only volumes |
| Persistent user workspace | Durable workspace data | Persistent storage |
Google says Hyperdisk serves these categories unless otherwise specified, and that the storage is encrypted at rest and in transit. The categories distinguish disposable working data from shared resources and workspaces intended to persist.
One shared pool serves different agent workloads
Google describes ACE as a shared hardware pool with policy-aware scheduling. Time-flexible evaluation and research jobs can use periods of lower demand and yield capacity to interactive workloads.
The company identifies four workload classes: interactive consumer and enterprise agents; persistent software-engineering workspaces; evaluation and reinforcement learning; and sandbox backends for Google services. Google says existing compute systems were not designed for the scale of hundreds of millions of agents. That figure describes the challenge motivating ACE, not a measured capacity of the platform.
ACE and Agent Substrate use different deployment models
The New Stack describes ACE as a managed Google Cloud service and Agent Substrate as an open-source runtime for GKE and Kubernetes, built on Agent Sandbox. In that account, Agent Substrate supports microVM or gVisor isolation. The practical distinction is where the runtime sits: ACE is presented as a service Google operates, while Agent Substrate is a Kubernetes-oriented runtime for teams working with that environment.
Google’s stated preview target
On October 22, 2026, Google said a Google Cloud preview of ACE was targeted for the coming months. That was the timing in the company’s announcement.
