Why Google Built a Computer for Every AI Agent

A coding agent is halfway through changing a Java service. It has checked out the repository, installed the right JDK, reproduced a failing test, and edited three files. Then it opens a pull request and waits for a developer to answer a question. The developer comes back forty minutes later and expects the agent to continue with the same files and tools.

What should happen to the machine during those forty minutes? Keeping a VM running preserves everything, but reserves capacity for work that is not using a CPU. Destroying it saves resources, but someone has to rebuild the environment and recover the work. Neither decision is very consequential for a dozen agents. It becomes an infrastructure problem when there are hundreds of thousands of open sessions and only a small fraction are executing commands at any moment.

On October 22, 2026, Google described Agent Compute Engine, the infrastructure behind execution environments for Gemini, Antigravity, and internal evaluation workloads. It gives agent sessions isolated Linux microVMs, suspends idle environments, shares immutable memory between them, preserves working files, and brokers external credentials outside the sandbox. The managed service is planned for preview, so the public technical write-up is currently more useful as architecture evidence than as a product performance guarantee.

I find the design worth studying less for the decision to use microVMs, which are well understood, and more for the consistency problems introduced when a computer can stop on one worker and resume on another. The memory and scheduling savings are attractive. Making that movement invisible to the developer is where the difficult engineering begins.

The computer runs tools. The agent lives elsewhere#Copy link

Google separates the harness from the sandbox. The harness calls the model, keeps track of the user's task, decides which tools to request, and handles approvals. The sandbox runs the shell, compiler, browser, package installer, and other programs that need a Linux environment. A repository script may be untrusted, so the sandbox should not inherit the harness's permissions just because the harness asked it to run a command.

The sandbox is a microVM with its own guest kernel, not a dedicated physical computer. Google describes using Cloud Hypervisor with its Titanium infrastructure, a verified read-only host operating system, and a restricted networking path through virtio-vsock. The guest does not get ordinary direct network access to external services. Outbound requests pass through a local proxy and an external Agent Gateway that can apply identity and policy checks.

A normal Linux container shares the host kernel. That can be a good choice for trusted batch jobs, but arbitrary code from a repository warrants a different threat model. A microVM puts a hypervisor boundary around its own guest kernel. It still does not make every action safe. Root inside the guest is not root on the host, but a root process can read whatever data the guest was allowed to see and attempt any outbound action the gateway permits.

I would not give every API-only agent a Linux computer. An agent that only calls a few typed business APIs can run behind an ordinary durable worker. A private execution environment becomes useful when the workload actually requires untrusted code, a browser, custom packages, or an interactive filesystem. The question after that is how long the environment needs to remain available, which is different from how long it needs to be running.

Four things people call a snapshot#Copy link

Before looking at suspension, it helps to name the state being preserved. A warmed base image and a checkpoint of an existing user's machine are often both called snapshots, but they have very different correctness requirements.

Google has published the use of prewarmed images, idle-session checkpointing, and durable workspace storage. It has not published a complete atomic commit protocol covering all four rows. The example below is how I would reason about the missing contract if I were designing an equivalent service. It is not a claim about Google's private implementation.

How does a running computer become an idle one?#Copy link

Google says its agent environments spend much of their time waiting for the model or for a human. For capacity planning, that is a major distinction. Imagine 100,000 open sessions with only five percent running commands at one instant. At an illustrative reservation of 512 MiB of private memory per session, keeping that reservation for every open environment represents about 48.8 TiB. Reserving it for the 5,000 active sessions represents about 2.44 TiB. These figures are hypothetical and omit warm capacity, shared pages, checkpoint storage, and headroom. Actual cloud memory reservations may be overcommitted. What matters is the large difference between the number of open sessions and the number needing active execution.

A hypervisor can notice an idle virtual CPU, but it cannot conclude that the application is safe to pause. A Gradle test may have launched a child process. A browser may have outstanding downloads. A command may have completed while its final output is still on the way to the harness. If the VM stops at the wrong instant, the guest and the orchestrator can disagree about whether work happened.

Google says it co-designed the sandbox command runtime and host executor so that the environment signals when no active commands or background tasks remain. The host can then checkpoint the idle environment, release active capacity, and restore it when more work arrives. This is application-aware quiescence. A low CPU reading alone would be a poor substitute.

In a system I was implementing, I'd make the idle transition a controlled operation. Stop accepting new commands for that execution generation, let admitted commands reach a defined outcome, and ensure the harness can recover any output that was acknowledged or still pending. Only then should the snapshot manager attempt to preserve machine state. If a new command arrives during that transition, either cancel the suspension before committing it or queue the command against the next valid owner. Otherwise a seemingly harmless race between a model response and a checkpoint could put work onto an executor that no longer owns the session.

The checkpoint race that makes this difficult#Copy link

Take sandbox-42, currently running on worker A with ownership generation 17. The last committed recovery point contains memory checkpoint cp-903, writable workspace revision ws-611, and tool-output sequence 87. A runs another command that edits three repository files. The writable workspace moves to revision 612, and the command output reaches the harness. A then writes memory checkpoint cp-904, but loses contact with the control plane before it publishes the new recovery point.

Worker B is assigned the session. It cannot simply load the newest checkpoint file it finds. The bytes for cp-904 may exist, but that checkpoint is uncommitted. Worse, restoring cp-903 while mounting a live workspace that already includes revision 612 may produce an environment that never existed. Its process memory can describe the old files while its filesystem exposes the new ones.

There are two separate requirements. First, only one worker may own the session. Worker B has to claim generation 18 atomically, and the control plane, command router, and any writable storage endpoints must reject generation 17 from then on. A lease check at the scheduler is insufficient if A can still write files or send authorized tool requests. Fencing must reach the services where conflicting writes would matter.

Second, the committed recovery point must describe a coherent set of resources. One possible design uses copy-on-write workspace revisions alongside memory and device checkpoints. The checkpoint writer quiesces the guest, establishes a stable workspace revision, persists the memory and device snapshot, and publishes a manifest with a compare-and-swap against the currently committed generation. A reader restores only the manifest's exact pair of revisions. An uncommitted cp-904 is garbage-collectable later, not a newer truth to discover by timestamp.

The record could look like this:

sandbox_id: sandbox-42
owner_generation: 18
recovery_manifest: manifest-903
  memory_checkpoint: cp-903
  workspace_revision: ws-611
  last_durable_tool_result: 87
serving_worker: worker-b

A filesystem rollback is not always available or desirable. If the workspace is a shared, independently durable volume, the platform instead needs a recovery contract that can reconcile the current files with the process checkpoint, possibly by restarting processes against the preserved workspace rather than restoring stale memory. That is a valid alternative, but it gives weaker process-continuity guarantees. fsync alone does not make arbitrary application memory and filesystem state an atomic transaction.

Now consider the command output that reached the harness after cp-903. Rolling back the guest to that checkpoint must not erase an already acknowledged command from the user's task history. A durable result log can preserve the acknowledgement and let the harness reconcile or replay the observation. An external operation, such as publishing a release, needs its own operation record and receiver-side reconciliation, since no VM snapshot can prove whether a remote API committed a request. That belongs in the harness's durable workflow, as discussed in Designing Long-Running AI Agents That Survive Failures.

This is the difference between safely moving a machine and correctly recovering an agent. Worker fencing deals with who can run the machine. A coherent recovery manifest deals with which machine state can run. The harness deals with what the outside world has already observed. I would demand failure tests at each boundary rather than accept a demo where suspend and resume work only with a healthy control plane.

Why Google's shared memory design matters#Copy link

Suspending idle sessions reduces the number of active machines. Google also has to start and restore large numbers of machines without loading identical operating system pages repeatedly. Hundreds of coding environments may use the same Linux libraries, browser binaries, and language runtimes.

Google says it prepares warmed snapshots and uses Direct Access, or DAX, together with copy-on-write mappings. Immutable base pages can be shared in host memory, while an agent that modifies one of those pages receives its own private copy. Memory reclamation and compression help return unused capacity. The design targets both startup latency and how many active environments fit on a host.

A simple example shows the attraction. If 200 active guests each needed a 1.5 GiB identical base and dirtied 128 MiB of private pages, individually holding all those base pages would occupy around 300 GiB before private deltas. A perfectly shared base plus 200 private deltas would be about 26.5 GiB. Real usage includes guest metadata, device memory, page tables, caches, and pages that cannot remain shared. This is a model of the mechanism, not an Agent Compute Engine benchmark.

The operational question is how quickly pages stop being shareable. A developer may start a Gradle daemon, compile a large project, change package caches, and create a browser profile. Those activities increase the private working set. I would measure dirty pages by workload type and image version, not judge an image only by the compressed size of its golden snapshot. Prewarming every team's custom toolchain could create many nearly identical images and destroy the sharing benefit. Stable JDKs, compilers, and browser binaries are better candidates for common warm layers than tenant-specific repositories or mutable build outputs.

There is also a cloning hazard. Forking a live snapshot can duplicate in-memory identifiers and random-number-generator state. Firecracker's entropy-for-clones guidance notes that guest-kernel mechanisms cannot automatically repair every library or application with its own cached randomness. A newly cloned agent needs fresh session identity, and any application state that assumed global uniqueness may need to be regenerated. That is a general virtualization concern, not evidence of a security defect in Google's service. A warmed snapshot is most defensible when it contains immutable code and initialized toolchains, not an authenticated user's live session.

The workspace must last longer than the machine#Copy link

The user wants the Java edits to be there tomorrow. The user probably does not need yesterday's temporary compiler process to still exist. Those expectations argue for different storage lifetimes.

Google describes disposable overlays for scratch files, shared read-only layers for binaries and common packages, and durable workspaces backed by Hyperdisk for work that users need to retain. It also describes Google Cloud Storage-backed FUSE volumes for shared data. This avoids allocating the same expensive durability to every temporary file a build tool writes, while keeping the repository and promised artifacts available between sessions.

A practical arrangement might have /opt/toolchains as a shared read-only layer, /tmp/build as scratch, and /workspace/payments as durable private state. A restore then has to decide whether it can safely resume process memory with the matching workspace revision. If the snapshot format, CPU features, guest kernel, or virtual devices are incompatible after an infrastructure upgrade, the platform may need to start a new guest against the durable workspace instead. That preserves the valuable files without pretending that arbitrary process memory is portable across every version.

Open sockets, timers, and short-lived leases also need attention after a long suspension. Firecracker's snapshot documentation warns that network connections may not survive restoration in its implementation. That does not establish a specific Google limitation. It is a reminder that saved memory is not a frozen copy of the outside world. A resumed process should be prepared to reconnect and revalidate assumptions that expired while it was idle.

What happens when a restored agent requests a document?#Copy link

Google's credential design is a good example of why the guest's identity should not be confused with the user's authority. Its write-up distinguishes a user identity, a delegated on-behalf-of grant, a workload identity for the particular sandbox, and a workforce identity for agents that have their own accounts or resources.

Suppose the developer authorizes an agent to read a Google Drive design document. The sandbox runs code that requests it. The request goes over virtio-vsock to a local mediation proxy, then reaches Agent Gateway with information identifying the attested sandbox and session. The gateway checks the relevant delegation, agent identity, node identity, policy, and requested destination before arranging a backend credential. The user refresh token and reusable backend credentials are kept outside the guest.

The precise wording matters. Google's design does place short-lived, session-scoped identity material inside the guest through a protected listener. Its documentation describes a public SPIFFE certificate and a short-lived identity token. These identify the sandbox for mediated traffic, rather than granting it reusable credentials that authenticate directly to enterprise backends. Saying the VM contains no identity material would be inaccurate.

Now suppose the user revokes Drive access while the sandbox is suspended. The guest can wake with old process memory and even an in-memory request it intended to send, but that cannot make the old delegation valid again. The gateway needs to check currently valid authority when the request is made, or enforce appropriately short-lived authorization bounded by revocation semantics. I would test this by revoking access during suspension, resuming the session, and confirming the next document request is denied. That is a design requirement for a similar system, not a disclosed Google test result.

A compromised guest can still misuse data it was legitimately allowed to read. Preventing direct credential theft is valuable, but an approved egress destination and a valid user delegation are not proof that the requested content belongs in that destination. Data-loss-prevention rules, resource-scoped permissions, action approvals, and auditability remain separate concerns. The longer security treatment belongs in Designing Containment for Production AI Agents, rather than repeating it all here.

A scheduler for agents has a different traffic pattern#Copy link

Google says its consumer agents, enterprise agents, and evaluation workloads have different demand curves. Interactive sessions need a quick answer, while offline evaluations and background research can often be deferred. A shared fleet can use otherwise idle capacity for flexible work, provided the scheduler can reclaim it when interactive demand rises.

Placement involves more than available CPU. A worker with the correct warm image and local checkpoint pages may resume a session faster than a less busy worker in another region. Workspace locality, tenant boundaries, data residency, restore bandwidth, and current health all influence the choice. Google describes a global scheduler that considers capacity, image readiness, and geographic or compliance policies, though it has not published a complete admission-control algorithm.

The difficult case is correlated demand. Suppose 10,000 suspended agents wake at once and each requires 128 MiB of unique, uncached state. That is about 1.22 TiB to read. At a hypothetical aggregate 10 GiB per second of sustained usable storage throughput, transferring those bytes alone takes at least 125 seconds. Shared warm pages, local caches, smaller deltas, and prefetching can reduce the actual transfer. The arithmetic is a lower bound for the stipulated data volume and bandwidth, not a prediction of Google's wake latency.

This is where a scheduler needs an admission policy, not only a placement algorithm. Interactive requests may get reserved warm capacity, while evaluations are checkpointed and requeued. Per-tenant activation quotas keep one customer from consuming the entire restore queue. Requests that cannot meet a user-facing deadline may need to be queued transparently or rejected instead of silently waiting. Preempting background work is helpful only when the bytes and time required to checkpoint it are less costly than the capacity it releases.

I would put p95 and p99 wake time beside active-to-open session ratio, checkpoint size, dirty-memory growth, local-image hit rate, restore failure rate, deferred-job queue age, and per-tenant fairness. High packing density is not a success if a developer spends the next minute watching a frozen terminal whenever everyone returns from lunch.

When is suspension actually cheaper?#Copy link

Suspending a sandbox incurs writes, reads, orchestration work, and perhaps a measurable delay. Keeping it warm incurs reservation or occupancy costs. The decision should be based on the distribution of idle gaps, not on one average session duration.

For a basic monetary model, let C_suspend and C_resume be the per-cycle cost of writing and restoring a snapshot, and let R_warm and R_suspended be the per-minute costs of retaining the environment in those states. Then:

break_even_idle_minutes =
    (C_suspend + C_resume) / (R_warm - R_suspended)

This only makes sense when warm retention costs more per minute than suspended retention. It also leaves out engineering cost, latency penalties, failed resumes, and spare capacity needed to meet an SLO.

For an entirely hypothetical example, suppose a warm environment costs $0.0010 per minute, a suspended one $0.0001 per minute, and one checkpoint-and-restore cycle costs $0.0054. The idle-time break-even point is six minutes. Suspending during a thirty-second model call loses roughly $0.00495 in that model. Suspending during a forty-minute human approval wait saves about $0.0306. These are made-up unit prices to show the method, not Google Cloud prices.

A production policy might therefore keep recently active sessions warm for a minimum interval, suspend after longer waits, and move very old checkpoints to colder storage. But hysteresis and warm capacity matter. If the platform suspends immediately after every tool call and wakes again two seconds later, it can turn cheap waiting into continuous snapshot I/O. I would first measure the idle-gap distribution, restore frequency, dirty-memory bytes, and burst profile, then test a suspension threshold against both cost and p99 wake time.

Which architecture would I choose for a smaller platform?#Copy link

Not every team should begin with the same execution substrate. The initial choice depends on which tools are trusted, how much state survives between calls, and whether the environment must resume interactively.

For a new product, I would begin with one region, a bounded number of warm environments, explicit workspace ownership, and mediated egress. I would not start by building a global microVM scheduler. Once the workload shows long idle gaps and high sandbox counts, I would prototype checkpointing against a measured control group of always-warm environments. A design review becomes much easier when it can compare real dirty-page distributions, time-to-first-command, restore error rates, and total cost per completed task.

Agent Substrate is useful evidence, not a managed-service benchmark#Copy link

Google announced Agent Substrate for GKE on September 15, 2026, before the October 22 Agent Compute Engine announcement. Agent Substrate is an open-source, Kubernetes-native runtime that maps logical agents, which it calls actors, onto reusable workers. It supports sandbox backends including Cloud Hypervisor microVMs and gVisor, which have different kernel-isolation and compatibility characteristics.

Google reported a 200,000-agent benchmark with 500 activations per second and suspend/resume operations below 500 milliseconds, as well as density improvements for Agent Substrate. The repository currently makes separately worded performance claims, including under 400 milliseconds and more than 1,500 activations per second. Without matching workloads, measurement definitions, and versions, those figures cannot be combined into a single performance promise. None is a verified customer SLO for the planned managed Agent Compute Engine service.

The Agent Substrate architecture document says much of its design is aspirational and not yet implemented. At the time of this article, it also describes static-allowlist ingress where per-actor ingress authorization is not yet supported. Its README identifies the project as pre-1.0 without a backward-compatibility guarantee. Those details matter more to a production adoption decision than a launch benchmark. GKE release notes describe general evaluation and non-production availability, with production support through a limited, allowlisted program. The managed Agent Compute Engine service has a different launch status and operating model.

A Kubernetes team might still study Substrate for the actor-versus-worker abstraction. I would evaluate the running implementation, its security boundaries, and its version-specific tests rather than assume that a design document or a Google benchmark describes the behavior of every deployment.

The tests I would run before increasing density#Copy link

I would suspend a sandbox while a completed command's output is being acknowledged, kill its worker after the checkpoint bytes are written but before the recovery manifest commits, and then force another worker to claim the session. The restored environment must use an authoritative memory-and-workspace pairing. The previous worker must be unable to publish a later checkpoint or write to the workspace, and the harness must retain any command result it already acknowledged.

Next I would clone a warmed image several thousand times and look for duplicated session identifiers, random state, or cached credentials. I would resume sessions after user delegation has been revoked and verify that the gateway enforces the current policy. Finally, I would run a correlated wake-up burst while lower-priority evaluations occupy the worker pool, measuring p99 wake time and fairness rather than average restore latency alone.

Those tests are more informative than showing that a microVM can start quickly. Google's published architecture demonstrates how many separate systems have to cooperate to make a private Linux environment feel persistent without keeping its CPU and memory allocated continuously. The design is compelling when the workload really has untrusted execution, durable workspaces, and long periods of waiting. It is much less compelling when a simple API worker already provides the needed isolation and state.

For an engineering team, the decision comes down to the measured lifetime of the session, the durable lifetime of the workspace, and the active lifetime of the compute it consumes. Getting those apart is useful. Making their boundaries consistent during failure is the work that determines whether the platform can be trusted.

For the orchestration side of the design, read How Coding Agents Actually Work: Inside the Agent Harness. For related distributed-systems problems involving ownership, isolation, and recovery, see the ArchCrux Interview Prep library.

Primary sources#Copy link

• Google Cloud: Inside Agent Compute Engine, October 22, 2026
• Google Cloud: Introducing Agent Compute Engine, October 22, 2026
• Google Cloud: Agent Substrate available on GKE, September 15, 2026
• GKE release notes: Agent Substrate availability
• Agent Substrate source and implementation status
• Agent Substrate architecture and documented limitations
• Firecracker: Snapshot support and restore limitations
• Firecracker: Entropy for clones
• gVisor: Architecture and security model