No network card, not a single credential, and paused while the model thinks: that is how Google runs every Gemini agent inside Agent Compute Engine, the service it unveiled on October 22, 2026 at AGNTCon + MCPCon. It reaches preview "in the coming months", but Google has already explained how it is built, and the architecture teaches more than the announcement.
The problem: an agent is not a microservice
A useful agent needs things we would never give a web service: root, the ability to install packages, run code it just wrote, and call APIs as a user. Yet it spends most of its life waiting: on the model, on a tool, on a human approval. A shared container gives too little isolation for the first part and wastes resources on the second.
Google says Agent Compute Engine already powers Gemini as an agent for work tasks, so this is not a prototype. It is the internal building block, turned into a product.
The key decisions
| Problem | Google's decision |
|---|---|
| The agent runs arbitrary code as root | One microVM per agent with its own guest kernel, behind a hardware-isolated Cloud Hypervisor boundary |
| The host could be compromised | A stateless, immutable host: read-only root enforced by dm-verity, verified at boot by the Titan chip |
| Network exfiltration | The microVM boots without a network interface; all traffic goes over virtio-vsock to a local unprivileged proxy, then to the Agent Gateway |
| Credential theft | No API keys, OAuth tokens or metadata-server access inside; the gateway swaps the token in flight |
| Idle agents | Checkpoint and restore: an idle sandbox consumes no active host resources |
The credential design is the part I find most interesting. Google defines four identities: the user's, which only authenticates the task; a long-lived delegation stored in a central authorization service and never on the node; a short-lived, SPIFFE-based workload identity that only covers sandbox traffic and cannot call backend APIs; and the agent's own account when it acts for itself. The Agent Gateway checks the first three and inserts the real backend credential on the way out. If the agent falls for a prompt injection, there is nothing inside to steal.
Sleeping without holding the machine
The sandbox runtime is co-designed with the host executor, so the host knows when a tool call has finished and the agent is "thinking". At that point it freezes the sandbox. To make waking it cheap, base images are pre-warmed and mapped into memory with DAX and copy-on-write: every microVM on a host shares one copy of the OS, libraries and binaries, and each agent only pays for the pages it changes.
The same primitives give you cloning, forking, rewind and rollback. For evals and reinforcement learning, Google describes snapshotting an environment once and forking thousands of memory-deduplicated copies in parallel.
Agent Substrate: the open source version for GKE
Alongside the managed service, Google released Agent Substrate, a GKE runtime with the same design that runs on any Kubernetes cluster and with any harness, Claude Code included. It offers microVM or gVisor isolation, and these are its numbers:
| Agent Compute Engine | Agent Substrate | |
|---|---|---|
| Model | Managed service | Open source, on GKE or any Kubernetes |
| Isolation | microVM with Cloud Hypervisor and Titanium | microVM or gVisor |
| Status | Preview "in the coming months" | Available |
| Published performance | No boot figures | 200,000 agents, 500 activations per second, under 500 ms to suspend and resume |
| Density | "Orders of magnitude" more than conventional VMs | Up to 10x traditional compute |
What you can take away
The portable part is not the microVMs but three ideas. First, treat the agent as a hostile tenant, not a trusted service. Neither the model key nor the GitHub token needs to live inside the sandbox; an egress proxy that injects credentials only for approved destinations can already be built with Envoy or an egress gateway.
Second, an agent's cost lives in its idle time. If your platform keeps a pod alive for the whole conversation, you are paying to wait. Designing for suspend and resume, with state on disk rather than in process memory, saves more than any requests tuning.
Third, a per-agent identity, short-lived and auditable, is what makes everything else work. Without it, network policy and traceability (Google promises OpenTelemetry-compatible metrics, logs and traces for every hop) have nobody to attribute anything to.
What does not transfer
Google's defense in depth rests on its own hardware, Titanium and Titan, which you will not find in your data center or another cloud. And the managed service is missing the facts that drive adoption: pricing, regions, boot times, CPU and memory limits. Until the preview publishes them, what you can already use is Agent Substrate, and its 500 ms comes from Google's own benchmark.
Sources
- Introducing Agent Compute Engine and expanded agent governance, Google Cloud Blog, October 22, 2026.
- Inside Agent Compute Engine, Google Cloud Blog, October 22, 2026.