Google Cloud Agent Compute Engine: One MicroVM per Agent
Google Cloud announced Agent Compute Engine on October 22, 2026, and trade press picked it up again this week. It gives each AI agent session its own hardware-isolated microVM and keeps credentials outside that VM. Idle agents are paused, and nobody outside Google can use it yet. Google says it will reach preview "in the coming months." For teams that run coding agents on untrusted code, the questions are what persists between runs and where memory lives.
What is Agent Compute Engine, in one sentence?
Agent Compute Engine is a Google Cloud service that runs each agent session in its own microVM, with a persistent workspace disk and no long-lived credentials inside.
Google built it for its own products first. The launch post says it "already powers Gemini as an agent for work tasks." The engineering deep dive quotes a Google DeepMind VP saying it gives Antigravity its snapshot-and-fork primitives. Customers can register interest through a form on both pages.
The same announcement covered Agent Substrate, an open-source runtime that brings the design to Kubernetes, and new agent governance features. Some coverage, such as SecurityBrief Australia, presents the governance as reaching agents on other clouds. Google labels that part "in preview soon."
How does Agent Compute Engine differ from Agent Substrate on GKE?
Google announced two ways to run agents in microVMs. One is a managed service. The other is software you run yourself.
| Agent Compute Engine | Agent Substrate | |
|---|---|---|
| What it is | Managed compute service. Google runs the fleet | Open-source execution runtime for Kubernetes |
| Availability | Preview "in the coming months" | "Try it on GKE today" |
| Isolation | Cloud Hypervisor microVM with its own guest kernel, on Titanium hardware | Your choice of microVM or gVisor |
| Where it runs | Google Cloud | Any Kubernetes cluster, per Google |
| When the agent is idle | Checkpointed, using no active resources until it resumes | Memory snapshotted, machine returned to the pool |
| Storage | Its own Hyperdisk per microVM | Filestore agent volumes, one shared workspace for multi-agent work |
Sources: Google's launch post and deep dive. Google says Agent Substrate works with any agent harness, Claude Code among them.
How does an Agent Compute Engine microVM work?
The deep dive says each agentic session runs inside "a dedicated, single-tenant" microVM. The launch post phrases it per agent: every Gemini agent gets its own computer. Whether one long-lived agent keeps one microVM across sessions is not stated. Developers pick each environment's image, identity and network access, and Google manages the hosts.
Agents spend much of a task waiting, often on a person or another system. The sandbox reports when no commands or background tasks are running. The host then checkpoints it and holds it with "zero active resources." The launch post says a paused microVM can resume from snapshots when the human or external system answers.
Density comes from shared memory. Machines that use the same base image share the same physical memory pages for the OS and libraries, through copy-on-write clones. For evaluation runs, Google says a team can snapshot one environment and fork it "into thousands of memory-deduplicated copies." The deep dive also lists rewind and rollback.
A microVM has no standard network interface and no direct access to your VPC. All traffic crosses a point-to-point channel to a local proxy, then an external proxy, where a gateway checks each request against policy. Private network access is attached on demand through Private Service Connect and VPC Service Controls.
Where do the credentials live?
Outside the microVM. The deep dive says guest environments hold no persistent secrets in memory or on disk. That covers OAuth refresh tokens and service account keys. They also cannot reach the cloud metadata server.
Each microVM receives a short-lived identity token and an ephemeral, session-scoped SPIFFE certificate. Long-lived user credentials stay off the host. Agent Gateway swaps them in on egress, after a policy check.
This matters for coding agents that run untrusted code from the web or a pull request. A prompt-injected agent can still misuse the access it has during the session. The design limits how long that access lasts and where it can go.
What state survives between runs?
The deep dive splits storage into three layers:
- Scratch data, such as OS logs and temporary build output, goes to disposable overlays.
- Base images and shared files, such as toolchains and package caches, are mounted read-only across sandboxes.
- Only "the user's working state and saved artifacts" are kept as durable state.
The launch post says each microVM "has its own Hyperdisk," which keeps execution workspaces and agent context across long-running sessions. Google's example is an agent that installs libraries on Monday and still has them on Tuesday. The deep dive promises to preserve "files and memory across turns and days."
So the workspace of one agent persists as a disk and a memory snapshot, tied to that agent's microVM. The platform's services for conversation history and long-term memory are Sessions and Memory Bank, which neither Google post mentions.
How does it relate to Agent Runtime and Memory Bank?
Google renamed its agent products this year. Per its name-change table, Vertex AI Agent Engine is now Agent Runtime on Gemini Enterprise Agent Platform. Its Memory Bank and Sessions became Gemini Enterprise Agent Platform Memory Bank and Sessions.
Agent Runtime is a fully managed runtime that deploys and scales agents written in any language or framework. Agent Compute Engine is a different layer: the computer an agent acts on. The launch post lists both among the runtimes that the governance tools cover.
Memory Bank stores facts about a user. An LLM extracts what it judges meaningful from stored sessions, and new facts are merged into existing memories. Each memory is scoped to an identity such as a user. Memories can expire on a time to live and keep revisions. IAM conditions control who reads or writes each scope. Agents can reach it from Agent Runtime or a local environment. Agents built on other frameworks call it through tools and callbacks you write.
For an agent on Agent Compute Engine, that gives two kinds of persistence. The Hyperdisk keeps the workspace. Memory Bank keeps facts about the user. Google has not described how the two connect.
What does Agent Compute Engine cost, and which governance features ship?
Neither Google post publishes a price. Neither the Agent Platform pricing page nor Google's compute pricing page mentions Agent Compute Engine. That fits a product that has not reached preview.
The governance side is further along. The launch post describes four parts built into the Gemini platform:
- Agent Gateway, which handles policy and traffic for agent connections
- Agent Registry, the list of approved agents and the tools they may use
- Agent Identity, which gives each agent a SPIFFE-based ID
- Agent observability, using OpenTelemetry
Covered runtimes include Agent Runtime and Cloud Run, plus Agent Compute Engine once it reaches preview. New Agent Gateway features are "coming this quarter in preview." They add token budgets and model routing. Delegated user authorization works through identity partners such as Ping Identity.
What should you read in the fine print?
Several reports dated November 6, 2026, including SecurityBrief Australia, say Google "launched" the service. Google's own posts say preview is still months away. For now, the only way in is the interest form.
Governance for agents on other clouds is not available yet. The launch post describes Envoy proxy-based enforcement points for multicloud and hybrid setups as "in preview soon." The same label applies to local governance for Claude Code and Antigravity CLI on managed devices.
Google publishes no benchmark for Agent Compute Engine itself. The headline numbers belong to Agent Substrate. In Google's own test with 200,000 agents, it sustained 500 activations per second with suspend and resume under 500 ms. Google also claims "as much as 10x higher compute density compared to traditional compute." We found no independent test of either claim.
The bottom line
If you run untrusted agent code on Google Cloud, register interest in Agent Compute Engine and design around its credential model now. Keeping every long-lived secret outside the sandbox is the part worth copying, whatever runtime you use. Teams that need microVM isolation today can run Agent Substrate on GKE. Treat the cross-cloud governance as a roadmap item until it reaches preview.
Where does agent memory live when the workspace belongs to one microVM?
Say a coding agent on Agent Compute Engine spends Monday learning your repository. It installs the toolchain and works out how your tests run. On Tuesday the microVM resumes with all of it on its Hyperdisk. Then you open Claude Code on your laptop for a quick fix. That disk belongs to one microVM, and your laptop agent knows none of it.
| Agent Compute Engine workspace and Memory Bank (separate services) | memU | |
|---|---|---|
| What is kept | Files and working state on one microVM's disk, plus user facts in Memory Bank | A shared Markdown wiki and reusable skills, distilled from agent history |
| Who writes memory | Memory Bank's LLM extracts and merges facts from sessions | The agent writes the Markdown. memU's MemoryService makes no LLM calls |
| Who can read it | The workspace stays with its microVM. Memory Bank serves code you connect to it, with IAM access to a scope | Every supported host shares one backend, so the laptop session and a cloud agent read the same memory. Hosts include Claude Code, Codex and Cursor |
| Fixing a wrong memory | Revisions show how a memory changed. The docs we read do not describe hand edits | Readable Markdown you open and fix |
| Where it lives | A Google Cloud project | Hosted on memu.so, free and synced across devices, or self-hosted |
If every agent you use runs on Agent Runtime or Agent Compute Engine, Google's pieces are enough. The Hyperdisk keeps the workspace, Memory Bank keeps user facts behind IAM, and there is nothing extra to install.
memU adds something once a second host, like Claude Code on your laptop, needs the same memory without custom tool code. To try the hosted version, get an API key from memu.so and send your agent one message:
Read https://memu.pro/SKILL.md, follow its instructions to install and configure memU, API Key is
YOUR_MEMU_API_KEY.
The self-hosted setup and the per-host support matrix are in the memU GitHub repository. More on the design is at memu.pro.
FAQ
Is Google Cloud Agent Compute Engine available?
Not yet. Google announced it on October 22, 2026 and says preview will arrive in the coming months. Interested teams can fill out an interest form linked from Google's launch post.
How much does Agent Compute Engine cost?
Google has not published pricing. Its launch post and engineering deep dive give no price, and the service has not reached preview.
Do Agent Compute Engine microVMs keep state between sessions?
Within a microVM, yes. Each has its own Hyperdisk for the user's working state and saved artifacts, and idle sandboxes resume from snapshots. Google has not said whether an agent keeps the same microVM across separate sessions.
Is Agent Compute Engine the same as Vertex AI Agent Engine?
No. Vertex AI Agent Engine is now called Agent Runtime, a managed runtime for deploying agents. Agent Compute Engine is a separate microVM service that gives each agent session its own isolated computer.
Can Google's agent governance cover agents on AWS or Azure?
Not today. Google says Envoy-based enforcement points for multicloud and hybrid environments are "in preview soon." Agent Substrate, the open-source runtime, already runs on any Kubernetes cluster, but that is the runtime, not the governance layer.