Google Agent Compute Engine: What It Is and Why Every AI Agent Gets Its Own microVM

Last Updated: 23 October 2026

Key takeaways

• Google Agent Compute Engine is a new Google Cloud service, announced on 22 October 2026, that gives every AI agent its own hardware-isolated microVM with a separate kernel, root access, a persistent disk and a cryptographic identity.
• It already powers Gemini, Gemini for business and Antigravity inside Google, and it opens to Cloud customers in preview "in the coming months". Google has not published pricing.
• Each sandbox holds zero long-lived credentials. Identity tokens are short-lived, network egress is brokered through a proxy, and backend credentials are injected outside the microVM at the gateway.
• Idle agents are checkpointed to encrypted snapshots, so an agent waiting on a model or a human consumes close to zero active compute and resumes in milliseconds.
• The open-source sibling, Agent Substrate on Google Kubernetes Engine, sustained 500 activations per second across 200,000 agents with under 500 milliseconds of suspend and resume latency in Google's own benchmark.

What is Google Agent Compute Engine?

Google Agent Compute Engine is a purpose-built compute service that runs each AI agent inside its own hardware-isolated microVM. Announced at the Linux Foundation's AGNTCon + MCPCon in San Jose on 22 October 2026, it is the internal platform that already runs Gemini's agentic workloads, now being productised for Google Cloud customers. Each microVM boots fast, carries its own guest kernel and root access, mounts its own Hyperdisk for persistent work, and holds no cloud credentials. Preview access opens in the coming months, and pricing has not been announced.

According to Google Cloud's announcement, the service was built because agentic workloads became one of the fastest-growing consumers of compute and storage across Google's fleet. The post is signed by Nirav Mehta, Michael Bachman and Kevin Hutchins, three infrastructure leaders at Google Cloud, and a technical deep dive followed a day later from Distinguished Engineers Ramanathan Venkatapathy and Rohit Jnagal.

The design splits every agent into two parts. The harness is the brain: it calls the model and decides what to do next. The sandbox is the hands: it runs the code, shell commands and browser sessions the model requests. Google's rule is that the brain never runs inside the hands. The harness stays outside the execution boundary and dispatches explicit commands, which gives a deterministic audit trail for every tool call.

Why agents break traditional cloud compute

Traditional virtual machines are too slow and containers are too porous for autonomous agents. A VM boots and configures a full machine, so start, suspend and resume take seconds to minutes. Agents start, pause and resume constantly, so that overhead compounds with every turn. Containers are fast because they share the host kernel, but coding agents and developer assistants need full kernel isolation and root control. Agent Compute Engine takes the isolation of a VM and the speed and density of a container, then adds application awareness so the platform knows when an agent is working and when it is waiting.

Google's teams also found that tearing down a sandbox between turns destroys the agent's working state and forces a slow rebuild. Provisioning an always-on VM for every waiting agent wastes capacity. The microVM model fixes both problems: state survives, and idle sessions stop consuming active resources.

How the security model keeps credentials out of the sandbox

The security model assumes an attacker controls everything inside the sandbox and makes sure there is nothing there worth stealing. Guest environments hold no OAuth refresh tokens, no service account keys and no access to the instance metadata server. Each microVM receives only an ephemeral, session-scoped SPIFFE certificate and a short-lived identity token through a dedicated local listener. Long-lived user credentials stay off-host and are swapped in at egress by the Agent Gateway, only after it validates the session's mutual TLS identity and egress policy.

According to Google's deep dive, microVMs have no standard virtual network interface, no default IP gateway and no direct VPC access. All traffic crosses a point-to-point virtio-vsock boundary to an unprivileged local proxy, which forwards to an external gateway that validates request scopes and brokers outbound traffic. Attestation keys sit in Google's Titan silicon and Titanium IPU, outside the guest, and block storage attachments are hardware-mediated with instance-bound cryptographic grants, so a compromised sandbox cannot mount another tenant's volume.

That design answers the obvious attack. An enterprise agent reads an inbox, finds a hidden instruction asking it to exfiltrate API keys, and the model occasionally complies. With no keys in the box and no direct route to the internet, the instruction yields nothing usable.

Who is the agent acting for?

Once credentials are removed from the sandbox, the next question is authority. When an agent opens a document in Google Drive, nobody clicked anything. Google answers this with four separate identities and never lets the sandbox hold the identity that opens the door: the user identity that started the request, a delegated on-behalf-of grant held in a central authorization service, a short-lived agent workload identity issued under the SPIFFE standard when the microVM spins up, and an optional workforce identity for agents that act as their own principal.

Only the workload identity is used on the host. The local proxy binds it to node attestation, forwards the request to the Agent Gateway, and the gateway validates the full triad of user delegation, agent identity and node identity before applying data-loss-prevention and egress policy. The downstream service sees a standard, auditable identity showing that an agent acted for a specific user. This is the piece most enterprise security teams have been missing: the agent is neither a person nor a service, and now it has a first-class identity of its own.

Why idle agents should cost almost nothing

Google measured its own fleet and found that agents spend most of their lives waiting, either on the model's next step or on a human reply. At any moment only a small portion of open sessions were actually running code. Reserving CPU and memory for every open session would have priced the fleet for work that never happened, so the platform was designed around application-aware idle detection instead of hypervisor guesswork.

Because the sandbox command runtime and the host executor are co-designed, the infrastructure knows when a tool call ends and the agent enters its thinking phase. The host checkpoints that microVM to an encrypted snapshot and returns its resources to the pool. On the next tool call the agent resumes from the snapshot. Google pairs this with cloning, forking, rewind and rollback primitives, which matter for coding agents that want to branch into parallel experiments without rebuilding an environment each time.

Density comes from memory sharing as much as from pausing. Hundreds of agents on one host run the same base image, Python runtime and browser. Agent Compute Engine builds pre-warmed snapshot images with initialised binaries, maps them into physical memory with Direct Access, and uses copy-on-write clones so every microVM shares the same physical pages for the base OS and libraries. Memory is allocated only for the private pages an agent actually modifies. According to Google, that lets a single physical node host orders of magnitude more live microVMs than conventional VMs.

Persistence is handled with Hyperdisk per microVM. Ephemeral scratch data lands in disposable overlays, shared toolchains and package caches mount read-only across sandboxes, and only the user's working state is stored durably. The result is the behaviour users actually notice: an agent that installed two Python libraries on Monday still has them on Tuesday, without paying for a machine that sat idle overnight.

Capacity planning gets a second lever from scheduling. Google plotted demand from Gemini, Gemini for business and its evaluation and RL pipelines and found the curves do not peak together. Consumer agents peak morning and evening, enterprise usage follows business hours across time zones, and evaluation runs fill whatever capacity is free. All three share one fungible hardware pool, with policy-aware global scheduling that still respects geographic and compliance boundaries.

Agent Compute Engine vs Agent Substrate vs Bedrock AgentCore

Google shipped two runtimes, not one. Agent Compute Engine is the managed Google Cloud service where Google operates the fleet. Agent Substrate is open-source software that runs the same agent-first design on any Kubernetes cluster, including GKE, and it is the part developers can try today. AWS's nearest equivalent is Bedrock AgentCore Runtime, which offers consumption-priced microVMs with CPU scaling to zero during I/O wait and idle memory reclaimed after 120 seconds. The practical difference is control versus convenience: Substrate is portable and self-run, Agent Compute Engine is managed and tied to Google's identity and network fabric, and AgentCore is the AWS-native option.

According to Google, Agent Substrate reached up to 10x higher compute density than traditional compute while keeping full kernel isolation, and in a benchmark of 200,000 agents it sustained 500 activations per second at under 500 milliseconds of suspend and resume latency. Those numbers belong to Substrate, not to Agent Compute Engine, which has no published performance figures yet. The Substrate design also decouples agent execution from machine management, snapshots an idle agent's memory, and resumes it on demand, with Filestore agent volumes giving multi-agent workflows a shared workspace.

The endorsement that matters most for teams running heterogeneous agents is framework neutrality. Substrate works with Claude Code, OpenClaw and Hermes, which means it is not tied to Google's ADK. "We built Hermes Enterprise to enable customers to deploy into their existing infrastructure, while handling per-agent isolation and extensible access control," says Hervé Bizira, Chief Business Officer at Nous Research. "Agent Substrate addresses both at the platform layer in a way that also preserves valuable compute resources."

What Australian teams should take from this

The immediate lesson is architectural, not commercial. Most Australian teams building agents right now run the harness and the sandbox in the same process, keep long-lived cloud keys in environment variables, and pay for an always-on container between turns. That pattern fails the two tests Google just made explicit: an agent that can read hostile content must not hold credentials, and an agent that is waiting should not bill like an agent that is working. Preview availability in Australian regions has not been announced, so Sydney-based teams should plan for data residency review before adoption, given APP 8 obligations on cross-border disclosure under the Privacy Act 1988.

In our own dual DGX Spark setup running Hermes and OpenClaw agents at roughly 35 tokens per second on a single stream and 62 at four concurrent, inference throughput was never the constraint. The constraint was keeping per-agent workspaces and session state alive between turns without the gateway ballooning in memory. That is exactly the problem Agent Compute Engine solves with checkpointing, and it is why we now treat idle agent state as a first-class design concern rather than an afterthought.

"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," says Clement Farabet, VP at Google DeepMind. "Agent Compute Engine gives Antigravity the instant snapshot-and-fork primitives and rapid resume speeds that make long-horizon software engineering feel effortless."

How to prepare before the preview opens

You do not need to wait for preview access to adopt the design. Four changes deliver most of the security and cost benefit on today's infrastructure: separate the harness from the execution sandbox, remove long-lived credentials from the guest, checkpoint idle sessions instead of keeping containers warm, and give every agent a distinct short-lived identity. Teams that do this now can move to Agent Compute Engine or Agent Substrate without re-architecting, and they get the audit trail that enterprise buyers increasingly ask for.

1. Split the brain from the hands. Run orchestration outside the execution boundary and dispatch explicit commands into the sandbox.
2. Strip secrets from the guest. Inject credentials at egress from a gateway, and give the sandbox only a short-lived workload identity.
3. Design for idle. Snapshot agent memory and filesystem state so a waiting agent can be parked and resumed rather than kept warm.
4. Instrument every hop. Emit OpenTelemetry traces per model call and tool invocation so agent actions are auditable end to end.

Frequently asked questions

Is Google Agent Compute Engine the same as Google Compute Engine?

No. Google Compute Engine rents general-purpose virtual machines and has done so since 2013. Agent Compute Engine is a separate service that runs one hardware-isolated microVM per AI agent, with agent-specific lifecycle controls such as checkpoint, resume, fork and rollback.

When can I use Agent Compute Engine?

Google says preview access will open "in the coming months" and is collecting interest through a form linked from the announcement. There is no consumer version, and no pricing has been published. The open-source Agent Substrate runtime on Kubernetes is available today if you want to test the architecture.

Does Agent Compute Engine replace Vertex AI Agent Engine?

No. Agent Engine, now part of the Gemini Enterprise Agent Platform, is the managed runtime for deploying and scaling agents with memory and sessions. Agent Compute Engine is the compute layer beneath that class of workload, giving each agent its own isolated computer rather than a shared runtime.

How much does an idle AI agent cost on Agent Compute Engine?

Google has not published pricing, but the design intent is that idle agents cost close to nothing. Idle microVMs are checkpointed and release their active CPU and memory, so you pay for the encrypted snapshot and disk rather than a running machine. For comparison, AWS Bedrock AgentCore Runtime bills $0.1276 per vCPU-hour and $0.0169 per GB-hour on consumption, with idle memory reclaimed after 120 seconds.

Is Agent Compute Engine secure enough for untrusted agent code?

It is designed for that threat model. Google assumes an attacker controls the sandbox and removes anything worth stealing: no long-lived credentials, no metadata server access, no direct network interface, hardware-mediated storage grants, and credential injection at the gateway outside the microVM. Whether that is sufficient for your compliance regime still depends on your own controls, logging and data classification.