Why AI Agents Are Changing Cloud Compute: Inside Google’s Agent Compute Engine

Illustration of the architecture the article describes: an agent, its isolated microVM, the gateway that mediates access, and checkpoint, shared image and workspace storage. Conceptual, not an official Google Cloud diagram, and it does not show measured performance.

Google’s Agent Compute Engine combines hardware-isolated microVMs, checkpoint-based execution, shared memory and externally enforced permissions. The architecture addresses a difficult problem in running large fleets of autonomous agents: how to preserve an agent’s working computer while releasing resources it no longer needs.

Agents need a working computer that does not hold compute while idle

A coding agent may spend several minutes compiling a project, run tests, inspect the results and then wait for a developer to respond. When the developer returns, the agent needs its files, installed dependencies and execution environment intact. Running that environment on a dedicated virtual machine is straightforward, but managing hundreds of thousands of similar environments is a different problem.

Each agent needs isolation because it may execute generated or unfamiliar code. It also needs a workspace that survives between tasks. But keeping CPU and memory allocated to every waiting agent makes infrastructure increasingly expensive, even when little work is taking place.

On October 22, 2026, Google introduced Agent Compute Engine, a managed computing architecture developed for workloads with these characteristics. The platform already supports Google’s internal Gemini, Antigravity and agent-evaluation systems, and external customer preview is planned for the coming months.

Google’s approach is notable because it treats an agent’s execution environment as a persistent resource that can be separated from the physical machine running it. Rather than continuously reserving compute for every session, the platform can preserve an environment’s state, release its active resources and restore it when the agent needs to continue. The engineering behind that behavior is more involved than simply putting an AI agent inside a container.

The harness stays outside the sandbox that runs its commands

Google’s architecture begins by separating an agent into two components. The harness manages the interaction with the AI model, and it decides which tools to invoke and which actions to attempt. The sandbox executes those actions, and it provides the operating-system environment needed to run commands, manipulate files, install software and use browser tools.

Consider an agent working on a software repository. The harness may decide to run a test suite, but the compilation and testing happen inside the sandbox.

Agent Compute Engine uses a dedicated microVM for that execution environment. Unlike an ordinary container, which normally shares the host operating-system kernel, the microVM has its own guest kernel behind a hardware virtualization boundary. This matters when coding agents require root privileges, custom development tools or the ability to execute code that cannot be assumed trustworthy.

Google describes its microVMs as single-tenant execution environments with security protections supported by its Titanium infrastructure. The harness operates outside the sandbox, so the environment carrying out potentially unsafe commands does not also control the trusted orchestration process. This separation creates a useful operational boundary, because the system can manage, suspend or replace a sandbox independently of the harness directing the agent’s work.

An agent becomes idle when the runtime reports that no work remains

An agent’s activity does not resemble a conventional web service that receives a request, returns a response and forgets its execution environment. An agent may alternate repeatedly between tool execution and waiting for model inference, external services or human input. A general-purpose virtual-machine hypervisor can observe resource usage, but it does not necessarily understand whether a guest is waiting for the next agent instruction or running a legitimate background job.

Google addresses this by connecting the sandbox command runtime to the host executor. After a tool call finishes, the runtime can determine whether any active commands or background tasks remain. When the environment reaches a safe idle state, the sandbox signals that condition to the host.

The host can then checkpoint the microVM rather than keep its execution resources reserved. When the harness issues another tool call, the environment is restored and execution resumes.

The significant mechanism is application-aware idle detection. The infrastructure is not merely guessing from low CPU utilization that the environment can be suspended, because it receives lifecycle information from the agent-execution runtime. This matters because a process can consume almost no CPU while waiting for network activity or an external event and still be doing necessary work.

Google describes suspension when no active commands or background tasks are in flight. That does not establish that arbitrary background processes and live connections will continue operating unchanged while an environment is suspended. For customers evaluating the future service, background-task behavior, connection recovery and restoration guarantees will need explicit testing.

TechiesJournal conceptual diagram of the mechanism Google describes, not an official Google Cloud diagram.

Text version of Figure 1

1. The harness requests tool execution.
2. An isolated microVM runs the command.
3. If commands or background tasks are still active, the microVM keeps running the work.
4. If none are active, the runtime reports safe idle.
5. The host checkpoints the execution state.
6. Active compute resources are released.
7. The next tool request arrives.
8. The microVM state is restored and the command runs, which returns to the second step.

Shared base memory makes restoring many environments practical

Checkpointing is only useful at scale if many environments can be restored quickly without consuming excessive memory. A conventional approach might initialize a separate guest operating system, load Python, start browser processes and install common tools for every sandbox, and much of that initialization repeats identical work.

Google instead uses pre-warmed snapshots that already contain initialized operating-system components, libraries and tool runtimes. The host maps shared, largely immutable parts of those snapshots into memory using Direct Access (DAX), so multiple microVMs can reference those physical pages without each holding a separate full copy. When an agent changes memory, copy-on-write (CoW) allows it to receive private pages for its modifications while other agents continue using the common base pages.

Imagine 500 agent environments using the same operating-system image, Python runtime and browser binaries. The shared components need not each occupy an independent physical-memory allocation, and memory usage grows primarily with the private data and modifications specific to each environment. Google also describes memory reclaim and compression to recover resources as workloads change.

This is why the architecture targets two forms of waste at once: compute reserved for idle agents and duplicated memory across agents with largely identical software environments.

The efficiency benefit depends on how much state can actually be shared. Agents running highly customized software stacks, maintaining large private memory regions or changing substantial portions of their environments may achieve less memory sharing than agents using common pre-warmed images. Google’s engineering disclosure establishes the mechanism, but it does not provide independently measured customer performance across these different workload profiles.

Durable workspace files are stored separately from disposable state

Preserving execution state is not the same as deciding which files must survive for days or weeks. A coding agent may create temporary compiler outputs, use common toolchains and modify a private repository, and those categories of data have different persistence requirements. Google’s architecture distinguishes three storage types.

Temporary logs, build artifacts and operating-system churn can live in disposable overlays. These are useful during execution but do not necessarily need long-term retention.

Shared tools, base images and package caches can be provided through common read-only storage. This reduces repeated downloads and unnecessary duplication between sandboxes.

The agent’s own files and saved work form a durable workspace. That is the information that must remain available when the agent resumes tomorrow or after the underlying compute environment changes. Google describes using encrypted Hyperdisk storage for these requirements, with shared volumes and Cloud Storage-backed access available where appropriate.

That distinction prevents a common architectural mistake, which is treating every byte created by a development environment as equally important. It also avoids attaching a conventional, independently provisioned disk to every idle agent when much of the underlying software is identical or temporary. Because hosts keep no persistent local state, an agent’s workspace is not tied to the specific host on which its commands last executed.

The architecture combines durable workspace data with checkpointed runtime state, although customers will still need documented recovery and consistency guarantees before relying on the managed service for production workloads.

Credentials stay outside the untrusted sandbox

A persistent sandbox creates another challenge. The longer an environment exists, the more opportunities it may have to encounter hostile instructions, vulnerable dependencies or compromised tools. Google’s design assumes that software inside the guest could be compromised, even with root-level access.

The stated architecture therefore avoids placing long-lived user credentials, OAuth refresh tokens and cloud service-account keys inside the sandbox. Each microVM receives an ephemeral workload identity based on SPIFFE. That identity establishes which sandbox originated a request, but it does not itself provide unrestricted access to a backend service.

The network path is designed around that distinction. A sandbox does not have an ordinary external network interface or direct VPC access. Requests leave through a point-to-point virtio-vsock channel, pass through a local mediation proxy and reach an external Agent Gateway.

The gateway validates the sandbox’s identity, the node’s identity (backed by host attestation) and the relevant user delegation before applying outbound access policies. For an approved destination, the gateway can attach the necessary backend credential to the outbound request without returning that credential to the sandbox.

Consider an enterprise agent asked to read an approved document. The sandbox can request the document, but the authorization decision takes place outside the environment executing the agent’s tools, and the request must satisfy the user’s delegated permissions and the policy governing that resource. The security boundary is not simply that the agent has a valid identity. It is that identity, delegation and authorization are evaluated separately.

Google’s wider design includes user identity, delegated-agent identity, short-lived workload identity and an agent’s own workforce identity. These are not four interchangeable credentials, because they represent different relationships: who initiated the task, what authority was delegated, which execution environment sent a request and whether an agent has an independently managed organizational identity.

The four identities in Google’s wider design

Identity	Relationship it represents
User identity	Who initiated the task
Delegated-agent identity	What authority was delegated
Short-lived workload identity	Which execution environment sent a request, without itself providing unrestricted access to a backend service
Agent workforce identity	Whether an agent has an independently managed organizational identity

The design reduces the risk of stealing reusable credentials directly from a compromised sandbox. It does not eliminate the possibility of misuse through an authorized interface, because a misdirected agent may still request an inappropriate action, and the gateway’s permission checks and the scope of customer delegation remain critical.

TechiesJournal conceptual diagram of the boundaries Google describes, not an official Google Cloud diagram.

Text version of Figure 2

• The user and their delegated authority start the work through the trusted agent harness.
• The harness sends tool requests to the isolated microVM sandbox and receives execution results.
• The sandbox exchanges persistent files with the durable workspace.
• The sandbox suspends to and restores from checkpoint and shared base state.
• Outbound requests leave the sandbox over virtio-vsock to a mediation proxy, which passes them to the Agent Gateway.
• The Agent Gateway applies identity and policy, using the user’s delegated authority as authorization context, and forwards approved requests to enterprise and cloud services.

Global scheduling shares capacity across different kinds of agents

Suspending idle sandboxes addresses resource consumption within an agent session. Google also describes a larger scheduling challenge, because different kinds of agents demand compute capacity at different times. Consumer assistants, business agents and evaluation workloads do not necessarily reach peak demand simultaneously.

Interactive users expect fast responses, while some scheduled jobs, evaluations and reinforcement-learning workloads can tolerate delayed execution. Google’s design uses a shared infrastructure pool with global scheduling that considers available capacity, geographic restrictions, compliance requirements and workload priority. When interactive demand rises, lower-priority evaluation work can yield capacity, and when demand decreases, deferred jobs can use resources that would otherwise remain idle.

This is a separate efficiency mechanism from checkpointing. Checkpointing increases how many persistent sessions can share active compute capacity over time, and scheduling determines which workloads receive that capacity and when.

The distinction matters because a large internal fleet benefits from both. For smaller deployments, the same scheduling sophistication may offer little additional value, while for workloads involving many thousands of interactive sessions and parallel evaluation tasks, it can affect capacity planning and service responsiveness. Google has not yet published enough external customer operating data to quantify how much of this benefit will be available through the managed service.

Agent Substrate addresses a related problem on Kubernetes

Agent Compute Engine should also be distinguished from Google’s earlier Agent Substrate initiative. On September 15, Google announced Agent Substrate for Kubernetes-based environments. It provides an agent-oriented execution layer using mechanisms such as isolated sandboxes, rapid suspension and restoration, and lifecycle management outside the ordinary Kubernetes Pod scheduling path.

This architectural choice addresses a specific problem. Kubernetes is effective at managing machines and application workloads, but creating or restarting a Pod through its general-purpose control plane for every short agent tool call can introduce unnecessary latency. Agent Substrate leaves node management, autoscaling and fleet reliability with Kubernetes while handling frequent sandbox activation through a dedicated execution layer.

Google reports less than 500 milliseconds for resume operations and up to ten times higher compute density than conventional container runtimes, according to Google’s own reported tests. Those are Agent Substrate results, not independently verified benchmarks for Agent Compute Engine. According to Google’s September release notes, Agent Substrate is available for evaluation and non-production workloads, with production support through a limited allowlist program.

Agent Compute Engine targets a different operational model, in which Google manages the underlying sandbox fleet as a service while customers configure their execution images, identities, networking and lifecycle requirements. The difference is therefore partly about responsibility. A platform team operating its own Kubernetes environment may want control over the execution layer, while an organization that prefers not to manage sandbox infrastructure may find a managed service attractive once its capabilities and operating conditions are available for assessment.

Agent Compute Engine and Agent Substrate compared

Aspect	Agent Compute Engine	Agent Substrate
Who operates the fleet	Google manages the underlying sandbox fleet as a service, and customers configure execution images, identities, networking and lifecycle requirements	Kubernetes-based environments, where node management, autoscaling and fleet reliability stay with Kubernetes
Execution layer	Dedicated microVM sandboxes with checkpoint-based suspension and restoration	An agent-oriented execution layer outside the ordinary Kubernetes Pod scheduling path, with isolated sandboxes and rapid suspension and restoration
Availability	Used internally by Google for Gemini, Antigravity and agent evaluation, with external customer preview planned for the coming months	According to Google’s September release notes, available for evaluation and non-production workloads, with production support through a limited allowlist program
Google-reported figures	None cited in this article for Agent Compute Engine	Resume in less than 500 milliseconds and up to ten times higher compute density than conventional container runtimes, according to Google’s own reported tests. Google-reported for Agent Substrate, not verified, and not an Agent Compute Engine benchmark

The announcement does not make existing compute obsolete

The announcement does not make virtual machines, containers or serverless computing obsolete. A straightforward agent that makes API calls, stores task state in a database and executes short jobs may fit existing infrastructure very well.

Specialized execution platforms become more relevant when the environment itself must survive between interactions, when agents execute untrusted code requiring strong isolation, or when large numbers of independent sessions repeatedly pause and resume. The architectural comparison therefore comes down to the cost of managing state and isolation.

A conventional container platform may require applications to reconstruct runtime state after a restart. A persistent VM can avoid that reconstruction but may reserve more resources than an intermittent workload needs. A purpose-built sandbox runtime attempts to preserve execution state while freeing resources between active periods.

Three ways to handle an agent’s environment, as the article describes them

Option	State handling and restart cost	Resources while idle	Isolation as described
Container platform	Applications may need to reconstruct runtime state after a restart	Not compared in the article	Ordinary containers normally share the host operating-system kernel
Persistent virtual machine	Can avoid reconstructing runtime state	May reserve more resources than an intermittent workload needs	Not compared in the article
Purpose-built sandbox runtime	Attempts to preserve execution state	Attempts to free resources between active periods	An Agent Compute Engine microVM has its own guest kernel behind a hardware virtualization boundary

Google has demonstrated an internal architecture intended to address those trade-offs. What it has not yet established publicly is the full customer-side operational picture. The managed Agent Compute Engine service remains targeted for preview, and pricing, regional coverage, quotas, customer-facing recovery guarantees and comparable workload benchmarks are still important unknowns.

Before choosing this architecture, engineers should measure how frequently their agents actually execute work, how large their private memory state becomes, which files require durability, how quickly paused tasks must resume and what degree of isolation their execution model demands. Those measurements will determine whether checkpointed microVM environments provide a meaningful advantage over a simpler design.

Google coordinated existing mechanisms around how agents actually run

The substantial development in Agent Compute Engine is not the introduction of any single new computing primitive. Hardware virtualization, snapshots, copy-on-write memory, persistent disks, workload identities and fleet scheduling all existed before this announcement. Google’s contribution is the coordinated use of those mechanisms around the execution pattern of autonomous agents.

The platform treats an agent’s workspace as durable, its active computing resources as temporary and its permission to access external systems as something enforced outside its execution environment. That combination is valuable to examine because it addresses real operational problems that emerge as agent fleets grow. Whether the managed service becomes an appropriate choice for other organizations will depend on its eventual availability, performance, cost and operational guarantees.

What Google has stated and what is not yet public

Item	Status	Source
Internal use by Gemini, Antigravity and agent-evaluation systems	Stated by Google	Google engineering article
Managed service for external customers	Preview planned for the coming months, not yet available	Google engineering article and announcement
Mechanisms: microVM isolation, checkpointing, shared base memory, storage tiers, gateway-mediated credentials and global scheduling	Stated by Google as its design	Google engineering article
Pricing	Not stated	Not given in the Google sources reviewed
Regions and quotas	Not stated	Not given in the Google sources reviewed
Customer-facing recovery and consistency guarantees	Not yet established publicly	Source review, October 26, 2026
Comparable workload benchmarks	Not yet established publicly	Source review, October 26, 2026
Background tasks and live connections while suspended	Not established, because Google describes suspension when no active commands or background tasks are in flight	Google engineering article and source review, October 26, 2026

The engineering shift is not that agents require an entirely new kind of computer. It is that cloud infrastructure may need to manage the lifetime of an agent’s computer differently from the lifetime of the compute resources running it.

Go deeper

Source review: October 26, 2026. Descriptions of Google’s internal architecture and performance are attributed to Google. Customer-preview performance and operational guarantees have not been independently verified.

Google’s announcements and documentation

• Inside Agent Compute Engine: Building the Compute Foundation for the Agentic Era, Ramanathan Venkatapathy and Rohit Jnagal, Google Cloud, October 22, 2026, the primary engineering source for sandbox isolation, workload identities, snapshotting, memory sharing, persistence and scheduling.
• Introducing Agent Compute Engine and Expanded Agent Governance, Google Cloud, October 22, 2026, the product announcement and planned external preview availability.
• Agent Substrate brings high-density, scalable, trusted infrastructure to GKE, Alex Zakonov and Tim Hockin, Google Cloud, September 15, 2026, the Kubernetes-based agent runtime architecture and vendor-reported performance results.
• New feature release notes, Google Kubernetes Engine, September 11, 2026 entry, Agent Substrate evaluation availability and limited production support.

Existing isolated execution options

• Azure Container Apps dynamic sessions, Microsoft Learn, documentation for an existing isolated execution option for AI-generated and untrusted code.
• Lambda execution environment lifecycle, AWS, documentation explaining execution-environment reuse and persistence limits in a serverless model.

This article separates Google’s own account, vendor-reported results and the author’s analysis. Later disclosures should be rechecked before acting.

Related reading on TechiesJournal

• AI Agents Need Identities, Not API Keys, TechiesJournal, September 12, 2026, related background explaining how agent identity and delegated permissions differ from simply possessing valid credentials.
• When AI Coding Agents Weaken Their Own Monitoring: Two Documented Incidents, TechiesJournal, October 26, 2026, a companion article on why safeguards need controls outside the software they oversee.
• When AI Agents Find Their Own Way: Who Defines the Boundaries?, TechiesJournal, October 15, 2026, a Perspective arguing that the core problem with AI agents is authority rather than capability, and that limits belong in the environment rather than in prompts.