Google Cloud Builds a MicroVM Compute Layer Specifically for Long-Running AI Agents

Agent Compute Engine brings Google’s internal agent infrastructure toward external customers. The announcement pairs persistent workspaces with controls designed to keep service credentials outside the execution environment.

Google Cloud announced Agent Compute Engine on October 22, 2026, introducing a compute service designed around agents that execute tools, pause between tasks and return to an existing workspace. Google says the infrastructure already supports Gemini agent workloads. A customer preview is planned for the coming months.

The announcement at AGNTCon + MCPCon gives developers an early view of how Google intends to host those workloads. It does not yet provide a firm preview date or a public price list.

An agent’s workspace needs to survive the wait

A long-running agent does not necessarily run code continuously. Consider a hypothetical coding assistant that prepares a change, waits for human approval and returns later to run tests. Its useful working state includes the files it changed and the environment needed to continue.

This is an agent execution infrastructure problem: preserve the workspace while avoiding unnecessary compute consumption during the wait.

In its launch announcement, Google describes microVMs that pause and resume from snapshots, share unchanged memory through copy-on-write techniques and retain workspaces using Hyperdisk. Each environment has its own guest kernel and root access, with a hardware isolation boundary.

The practical question for customers will be whether maintaining that continuity reduces the total work needed to complete a task. Fast resume matters most when the restored environment remains consistent and the agent can continue without repeating earlier steps.

Service credentials stay outside the sandbox

Google’s technical description places the agent’s orchestration harness outside its execution sandbox. It says persistent secrets, OAuth refresh tokens and cloud service-account keys are excluded from the guest environment.

A sandbox instead receives a temporary workload identity. Outbound traffic passes through proxies to Agent Gateway, which checks delegation, identity and policy before inserting the necessary backend credential.

This is a company-described architecture. AgentsCalling has not independently tested whether its boundaries withstand a compromised guest or malicious tool output.

The distinction between identity and authority matters. An agent can identify the environment making a request without holding the reusable secret that grants access to an external service. That creates an opportunity to enforce access decisions beyond the code the agent can modify.

Hiding a credential does not settle every security question

AgentsCalling’s analysis is that this design moves a critical control outside the agent’s working environment. Its effectiveness still depends on the permissions granted and the policies enforced at that boundary.

For example, an agent legitimately allowed to read a document could mishandle its contents without ever stealing the credential used to open it. Preventing credential extraction and preventing misuse of authorized access require different checks.

This connects with the distinction explored in our coverage of 1Password’s user-approved agent logins: protecting the sign-in secret is one part of controlling what software may do inside an account.

A useful evaluation would therefore examine both denied requests and permitted actions that conflict with the user’s task. It would also check whether revoking access stops an agent that has already resumed from a saved state.

Agent Substrate is a separate part of the announcement

Google also described Agent Substrate, an open-source runtime for Kubernetes. The Decoder’s coverage identifies the distinction between that runtime and the managed Agent Compute Engine service.

The frequently cited figures of up to ten times higher compute density and suspend/resume latency below 500 milliseconds belong to Google’s Agent Substrate claims. They should not be presented as measured performance guarantees for Agent Compute Engine.

Google says additional token-management and model-routing controls are planned for preview this quarter. These features address a related concern for buyers: a technically successful agent can still be expensive to operate.

What developers still need to measure

External customers will need preview access and commercial details to compare the service fairly with their existing infrastructure. A claim about lower active compute consumption cannot, by itself, establish the total cost per accepted result, including persistent storage, model calls and operational oversight.

A practical evaluation should use the same agent, model and workload across environments. It should record tool actions and their outcomes, alongside startup and resume times, successful task completion, state consistency after interruptions, credential exposure, and the effect of withdrawing permissions mid-task. No such comparison was performed for this article.

Google’s proposal makes the execution environment an explicit part of agent design. The next evidence developers need is whether the service delivers dependable task continuity and enforceable access boundaries at a predictable cost.

Reporting note: This article compares Google’s launch announcement and technical explanation with accessible coverage from The Decoder. Security, efficiency and internal deployment descriptions remain attributed to Google. AgentsCalling has not benchmarked the service or audited its safeguards.