Agent Compute Engine deep dive

1. User identity: The authenticated identity of the user who initiated the request or owns the agent workflow. This is only used to authenticate the request for the overall task and not for any agentic operation.

2. Delegated Agent on-behalf-of Identity: A cryptographically scoped grant proving that the user has authorized the agent harness to perform specific work on their behalf. These long-lived grants live exclusively in our central authorization service — never on the compute node.

3. Agent Workload Identity: When a microVM spins up, the platform assigns it a short-lived, cryptographically attested agentic identity based on the open SPIFFE standard. This is the only identity used for sandbox traffic. This identity is not usable to call a backend API directly, if it is exfiltrated off the machine. Its sole purpose is to cryptographically identify which specific sandbox originated an outbound packet.

4. Agent Workforce Identity: Agents can act as your assistant with their own identity, own account and resources.

We exclusively use the Agent Workload Identity (ID-3) on the host and translate it to other identities off-node after verifying the host, user, sandbox, session, and related policies. This ensures that every request is fully governed and auditable to the initiating agent.

When code inside a sandbox makes an outbound request, the node’s local proxy intercepts it, binds the node and Titanium-backed attestation, and forwards it to the off-node Agent Gateway. The gateway validates the full triad — user delegation, agent identity, and node identity — then evaluates fine-grained egress and data-loss-prevention policies, and performs an in-flight token swap, inserting the required backend credential on the wire as the request leaves the gateway.

The downstream backend sees a clean, standard, cryptographically verifiable identity with full auditability showing that an agent acted on behalf of a specific user. Meanwhile, the untrusted sandbox never sees any credentials.

Most agents are waiting, most of the time

When we measured typical agent sessions, we found that agents spend most of their lives waiting. They wait for the model to return the next step, and they wait for the user to reply. At any moment, only a small portion of open sessions were running code.

That number changed how we thought about cost. If we reserved CPU and memory for every open session, we would pay significantly more for the work agents actually did. We needed an idle agent to cost close to nothing, and we needed it to wake up before the user noticed.

Application-aware idle detection

In a traditional VM service, the hypervisor has no idea whether the guest OS is doing useful work or just spinning in an idle loop waiting for the next prompt.

Because we co-designed our sandbox command runtime with the host executor, the infrastructure has native application awareness. The moment an agent finishes executing a tool call and enters the “thinking” phase of the agentic loop, the sandbox signals that no active commands or background tasks are in flight.

The host immediately transitions that sandbox from active to idle via a fast checkpoint-and-restore model. The state of the idle agent is preserved, ready to wake up quickly on the next tool call, while consuming zero active resources on the host. This lets a single physical node host orders of magnitude more living agent microVMs than conventional VMs. We couple this with features integral to agents like cloning, snapshot/forking, rewind and rollback that allow the harnesses to use the system efficiently without resource duplication.

Fast snapshotted images with deduplicated memory

Idle agents are half of the problem. The other half is what active agents have in common. On a single host, hundreds of agents run the same base image, the same Python runtime, and the same browser. Each VM keeps its own copy of those bytes in memory.

In Agent Compute Engine, we ensure that every static page — in filesystem or memory — has only one copy across the host and everything that a workload needs is preloaded into memory and fully warmed. We achieve this by building pre-warmed snapshot images with fully initialized binaries. On hosts, the snapshot is mapped directly into physical memory using Direct Access (DAX) and Copy-on-Write (CoW) memory clones. Because DAX bypasses duplicate guest page caches, every microVM on the host shares the exact same physical RAM pages for the base OS, libraries, and binaries. Physical memory is allocated only for the small delta of private pages that each agent actually modifies, and active memory reclaim and compression continuously return freed pages back to the host pool.

“Autonomous coding agents need real computers — complete with root privileges, custom compilers, test runners, and persistent git workspaces — and they need to branch into parallel experiments in the blink of an eye. Agent Compute Engine gives Antigravity the instant snapshot-and-fork primitives and rapid resume speeds that make long-horizon software engineering feel effortless.” – Clement Farabet, VP, Google DeepMind

Persistence: The agent should remember what it did yesterday

On Monday, a Gemini user asks their agent to analyze a spreadsheet. The agent installs two Python libraries, writes a script, and saves a chart. On Tuesday, the user asks a follow-up question. If the agent has to reinstall the libraries and rewrite the script, the user waits, and the agent may reach a different answer.

So every Gemini agent needs a disk that lasts. At Gemini’s scale, providing agents with a standard disk would have caused us to quickly run out of storage capacity, while most of those disks actually sat idle and nearly empty. Hosts would also run out of disk attachment slots long before they ran out of CPU.

We looked at what agents actually write. It consists of three kinds of data, and each kind needs different storage:

1. Ephemeral scratch data: OS-level logs, temporary build artifacts, and container-layer churn are captured in fast, disposable overlays.

2. Read-only and shared volumes: Base images, language toolchains, and shared package caches are mounted read-only across sandboxes. That way, all agents installing common libraries share a single copy rather than having to re-download and re-store identical files. Teams and multi-agent workflows can also mount shared volumes via high-speed FUSE on Google Cloud Storage (with credentials managed outside the sandbox on the host) to collaborate on massive datasets without copying data.

3. Persistent user workspaces: Only the user’s working state and saved artifacts are persisted as a durable state. 

We serve each of these, unless otherwise specified, via Hyperdisk, which is is fully encrypted, both at rest and in transit

Tight Workspace and Google Cloud integration

Most Gemini for business customers have asked us for the same thing: Let agents use our data without having to move it, whether it’s in Google Workspace, in a database inside a private Virtual Private Cloud (VPC) network, or behind internal Model Context Protocol (MCP) servers.

Nor do customers not want to copy sensitive data to another vendor, or to open a firewall port for an agent. The good news is that we already had the pieces to avoid both scenarios, because the identity and gateway design from the previous sections applies to company networks too. An administrator decides what an agent can reach, and Agent Compute Engine enforces that decision outside the sandbox, through:

• Policy-driven VPC and Workspace reachability: Through the Agent Gateway and on-demand private network attachments (built on Private Service Connect and VPC Service Controls), an administrator defines declarative policies for what an agent is allowed to reach. It can be a specific set of internal VPC endpoints, approved Workspace APIs, or an allowlist of external domains. All assets are protected by default.

• Unified identity and auditability: When an enterprise agent accesses a Workspace document or a private Google Cloud resource, Agent Gateway verifies the user’s OBO delegation and the sandbox’s attested identity before swapping in the enterprise-scoped credential. Every action respects Cloud IAM and VPC Service Controls perimeters, with end-to-end audit logs and without a single enterprise credential ever entering the sandbox.

Running it everywhere, all the time

Using microVMs’ ability to pack more agents onto each machine helped, but demand for agentic resources kept growing faster than our supply of hardware. So we looked at when agents run.

When we plotted sandbox demand from Gemini and our evaluation teams, the curves did not peak together. Gemini agents peaked during mornings and evenings. Gemini for business usage peaked during business hours in each time zone. Evaluation and RL runs had no peak; they ran whenever capacity was free. And much of a Gemini agent’s work, such as daily digests or background research, did not need to start the moment a user asked.

That pattern lets us serve more agents in Agent Compute Engine on the same capacity footprint. We run all three on one pool of hardware and let time-flexible work fill the gaps. Three mechanisms make this work.

1. Fully global, policy-aware scheduling

Our global scheduling frontdoor continuously monitors capacity headroom, health, and image readiness across regions around the world. When a new session is requested, the scheduler steers it to the optimal available capacity pool while strictly enforcing the product’s geographic boundaries, enterprise compliance rules, and consumer data location requirements.

2. Time flexibility in deferred and scheduled workloads

A key insight from operating Google’s agentic fleet is that a large fraction of agentic compute is not real-time human-in-the-loop interaction. Think of recurring daily digests, deep background research tasks, asynchronous code migrations, overnight test sweeps, and massive RL evaluation runs. We can use global scheduling to steer or schedule the workloads based on quality and priority required by the products. This helps to schedule workloads into off-peak troughs, filling the natural valleys between interactive daytime peaks and dramatically cutting the peak hardware footprint required to serve the business.

3. A unified, fungible hardware pool

Instead of carving up isolated, static hardware silos for every product team, we run a unified, multi-tenant fleet over a portable, low-dependency overlay. The same underlying pool of bare-metal and virtualized hardware nodes dynamically absorbs the uncorrelated peaks and troughs of consumer chat traffic, enterprise business hours across time zones, and continuous training and evaluation jobs. When interactive demand surges, low-priority batch evals gracefully yield physical slots; when interactive traffic ebbs, RL and evaluation pipelines soak up the spare cycles.

Putting it all together

Building for Gemini, Gemini for business, and internal Google teams made us solve three key problems: 

1. The model will make mistakes; when it does, the sandbox shouldn’t hold anything that an attacker can use against it. 

2. Agents spend most of their time waiting. An idle agent should cost almost nothing and wake up faster than a person notices. 

3. An agent becomes more useful the more it remembers. Its workspace should survive between turns, between days, and between versions of the operating system. 

And of course, we had to solve it in a uniquely Google way at planet scale.