Google Agent Compute Engine: What Google's Agent Push Means for Builders

Google Agent Compute Engine is Google's answer to a question the whole industry hit this year: what does compute look like when the workload is not a web request but an autonomous agent? Announced on October 22, 2026 at AGNTCon + MCPCon, Agent Compute Engine (ACE) is a purpose-built compute service that already powers Gemini's agent sessions, and it will open to customers in preview in the coming months. Alongside it, Google released Agent Substrate, an open-source agent runtime for Kubernetes, and expanded its agent governance layer to cover agents across clouds and on local devices. Google Cloud blog: Introducing Agent Compute Engine

The timing is hard to miss. One day earlier, NVIDIA launched the OpenShell Reference Architecture with the same core claim: agent safety is an infrastructure property, not a prompt engineering problem. Two of the largest infrastructure vendors made essentially the same bet within 48 hours. This post breaks down what Google actually announced and what the design teaches any team running agents, wherever they run. Codesprint: NVIDIA OpenShell

What Google announced

The headline service is Agent Compute Engine, which gives every agent its own high-performance, secure computer. Google built it to handle Gemini's own agentic workloads: agents that write and execute code, run tools, drive browsers, and orchestrate enterprise workflows at planet scale. The pitch is that traditional compute primitives were not optimized for the highly iterative lifecycle of agents, which start, pause, and resume constantly. Google Cloud blog: Introducing Agent Compute Engine

Three technical choices define the service. First, speed with efficiency: microVMs boot rapidly, and copy-on-write memory sharing lets many agents run on a single OS template. When an agent finishes a tool call and enters the thinking phase of its loop, the host checkpoints the microVM and moves it to an idle state, then restores it from a snapshot when needed. Second, hardware-rooted isolation: each microVM runs behind a Cloud Hypervisor boundary with its own guest kernel and root access, backed by Titanium, Google's offload infrastructure processing unit. Third, persistence: every microVM gets its own Hyperdisk, so an agent's workspace and context survive across sessions. Google Cloud blog: Introducing Agent Compute Engine

The deep dive from Google's distinguished engineers adds the design philosophy. Their rule: assume an attacker controls everything inside the sandbox, and make sure they find nothing there to use. The concrete example is a prompt injection attack, an email telling an inbox-managing agent to find API keys and send them out. Google's answer is that there are no keys to find. Google Cloud blog: Agent Compute Engine deep dive

The zero-secrets sandbox

The security architecture is the most instructive part for anyone building agent infrastructure. Each microVM holds zero persistent secrets: no user credentials, OAuth refresh tokens, or service account keys in memory or on disk, and no access to the cloud metadata server. A compromised guest with full root access still finds nothing to steal. Google Cloud blog: Agent Compute Engine deep dive

Networking is equally constrained. MicroVMs boot without a standard network interface, default gateway, or direct VPC access. All traffic crosses a point-to-point virtio-vsock boundary to an unprivileged local mediation proxy, then to an external gateway that validates request scopes and enforces policy-driven outbound brokering. Storage attachments are hardware-mediated by the Titanium IPU using instance-bound cryptographic grants, and snapshots and volumes are encrypted at rest. The host itself is a stateless, immutable appliance with a read-only root filesystem and cryptographically verified boot. Google Cloud blog: Agent Compute Engine deep dive

The harness that decides what the agent does runs completely outside the sandbox, so untrusted guest environments only ever execute explicit dispatched commands, and every tool call maps to a deterministic audit trail. This is the same separation NVIDIA drew between OpenShell's Supervisor and its Sandbox. Codesprint: NVIDIA OpenShell

Four identities, and the agent never holds the important one

Google's governance answer to "who is asking" splits identity into four parts. The user identity authenticates the human who initiated the work. A delegated on-behalf-of grant, held only in Google's central authorization service, proves the user authorized the harness to act. An agent workload identity, a short-lived SPIFFE certificate issued per microVM, marks which sandbox originated a packet but is useless for calling backend APIs if stolen. And an agent workforce identity lets an agent act as an assistant with its own account and resources. Google Cloud blog: Agent Compute Engine deep dive

The flow matters more than the labels. When sandbox code makes an outbound request, the local proxy binds the node attestation and forwards the request to the off-node Agent Gateway. The gateway validates the user delegation, agent identity, and node identity together, evaluates egress and data-loss-prevention policies, and only then swaps the real backend credential onto the wire as the request leaves. The downstream service sees a clean, auditable identity showing an agent acted for a specific user; the sandbox never sees the credential. Google Cloud blog: Agent Compute Engine deep dive

The economics: most agents are waiting

Google's fleet measurement is the most quotable finding in the deep dive: agents spend most of their lives waiting, for the model to return the next step or for the user to reply. Reserving CPU and memory for every open session would mean paying for far more than the work agents do, so idle agents had to cost close to nothing and wake before the user notices. Google Cloud blog: Agent Compute Engine deep dive

Because the sandbox runtime and host executor are co-designed, the infrastructure knows when an agent is working versus waiting, and checkpoints idle sessions to consume zero active resources. Active agents get a second optimization: pre-warmed snapshot images mapped into physical memory with Direct Access and copy-on-write clones, so every microVM on a host shares the same physical RAM pages for the base OS, libraries, and binaries, and only the pages an agent actually modifies cost memory. Demand curves helped too: Gemini agents peak mornings and evenings, business agents peak during work hours, and evaluation runs fill the valleys, so one hardware pool serves all three. Google Cloud blog: Agent Compute Engine deep dive

This idle-awareness is a cost lesson any team can apply before touching Google's stack: agent workloads are spiky and mostly idle, and billing models that assume always-on compute will overcharge you. Our guide to AI agent cost control covers the levers that work on ordinary infrastructure.

Agent Substrate: the same ideas, open source, on Kubernetes

For teams standardized on Kubernetes, Google released Agent Substrate, an open-source execution runtime on GKE with the same agent-first design. When an agent goes idle, Agent Substrate snapshots its active memory and returns the machine to the pool, resuming the agent when needed. Google claims up to 10x higher compute density than traditional compute with full kernel isolation, and in a benchmark of 200,000 agents it sustained 500 activations per second at under 500 ms suspend-and-resume latency. Google Cloud blog: Introducing Agent Compute Engine

Isolation is your choice of microVM or gVisor, every agent gets a cryptographic identity with egress proxies that enforce network policy and inject credentials out of the agent's reach, and the runtime works with any agent framework, including Claude Code, OpenClaw, and Nous Research's Hermes. Nous Research says it is already using the architecture to deploy multi-tenant agents into customer infrastructure. The project is developed in the open on GitHub. Google Cloud blog: Introducing Agent Compute Engine Source

Governance leaves the Google perimeter

The second half of the announcement extends Gemini for business governance beyond Google's own runtime. The existing pieces are Agent Gateway (policy enforcement for agent traffic), Agent Registry (a central catalog of approved agents, tools, MCP servers, skills, and models), Agent Identity (SPIFFE-based IDs per agent), and OTel-compliant observability across every model call and tool invocation. The expansion pushes these across Google Cloud runtimes, into other clouds and on-prem through lightweight Envoy-based policy enforcement points, and onto managed endpoint devices, where coding agents like Claude Code and Antigravity CLI get an OS-level sandbox with local governance. The cross-cloud and endpoint pieces are marked as coming to preview soon. Google Cloud blog: Introducing Agent Compute Engine

New Agent Gateway capabilities coming this quarter include granular token and cost governance with budget guardrails, model routing policies, and delegated user authorization through Ping Identity, SailPoint, and Saviynt. L'Oreal's AI lead engineer is quoted using the governance layer to unify identity, policy, and observability across runtimes like Cloud Run. For teams building their own observability practice, our agent observability checklist maps the same telemetry categories onto vendor-neutral tooling. Google Cloud blog: Introducing Agent Compute Engine

The pattern is now table stakes

Strip away the vendor specifics and Google's design rules match NVIDIA's from the day before: sandbox the agent in hardware isolation, keep credentials outside its reach, mediate all egress through a policy-enforcing gateway, give every agent an attested identity, and log every action against the human who delegated it. When Google and NVIDIA independently ship the same architecture in the same week, that architecture stops being a differentiator and becomes the baseline enterprise buyers will expect.

The practical takeaway: you do not need Titanium or BlueField silicon to apply the pattern. Sandboxed execution, short-lived scoped credentials, egress policy, and agent-level audit trails are all buildable on ordinary cloud infrastructure today, and they are the pieces procurement teams will ask about first.