Google Brings Agent Substrate to GKE for High-Density AI Agent Workloads

Google Cloud is bringing Agent Substrate to Google Kubernetes Engine (GKE), introducing an open-source runtime designed specifically for running large numbers of AI agent sandboxes.

The technology is aimed at a different infrastructure problem from simply running an AI model.

Autonomous agents can generate and execute code, interact with command-line tools, use browsers, access files, and remain active across multiple interactions. Running large fleets of these agents introduces challenges around isolation, networking, scheduling, startup latency, and compute utilization.

Google Cloud says Agent Substrate is designed to address those challenges by separating agent execution from machine management and building an execution layer on top of Kubernetes infrastructure.

The company says the runtime can run millions of sandboxes, offers 10x higher density than standard container runtimes, and supports sub-500ms resume operations at more than 500 suspend/resume activations per second. These figures are claims from Google Cloud's announcement, not independent benchmarks.

Why Agent Infrastructure Becomes Different at Scale

Running a single coding agent locally is very different from operating hundreds of thousands or potentially millions of concurrent agent environments.

Google Cloud identifies several infrastructure challenges that become more significant as agent workloads scale.

Untrusted code and trust boundaries

AI agents can generate and execute code dynamically.

That means infrastructure may need to execute code that has not been manually reviewed by a human. Google Cloud highlights potential risks around host escape, credential theft, and data exfiltration when isolation and network controls are insufficient.

Tool access

Agents often need more than a model endpoint.

They may require command-line tools, headless browsers, filesystem workspaces, and other computer environments to complete tasks.

Providing those environments while maintaining isolation introduces additional infrastructure requirements.

Bursty workloads

Agent harnesses, benchmarks, and reinforcement learning workloads can create large bursts of sandbox creation.

Google Cloud says such workloads can generate thousands of sandboxes per minute, creating scheduling and storage pressure for general-purpose infrastructure.

Idle compute

An agent does not necessarily consume compute continuously.

It can spend time waiting for model inference, tool responses, or human input.

Keeping CPU and memory reserved for these inactive environments can leave infrastructure resources underutilized.

Agent Substrate is designed around this characteristic.

Agent Substrate Separates Agent Execution From Machine Management

Google Cloud describes Agent Substrate as an execution layer built on cloud-native Kubernetes infrastructure.

Rather than requiring platform teams to manage every individual agent environment as a conventional workload, the substrate manages the lifecycle of sandboxed agent environments.

The system is designed around four main capabilities:

• Security by default

• Sub-second activation

• High compute efficiency

• Open-source portability

The runtime supports hardware-isolated Cloud Hypervisor microVMs or gVisor sandboxes, along with an integrated gateway for controlling network traffic.

Activated agents can be dispatched onto pre-warmed workers, while inactive agents can be suspended to release compute resources.

Google Cloud says the system works with agent frameworks and harnesses including Claude Code, OpenClaw, and Hermes.

Security Starts at the Kernel and Network Layers

One of Agent Substrate's core principles is to provide isolation at both the kernel and network levels.

Google Cloud says teams can choose between:

Cloud Hypervisor microVMs

These provide hardware-isolated environments with full Linux kernel compatibility.

gVisor

This provides kernel-level sandboxing with lower overhead, according to Google Cloud.

The runtime also includes an integrated gateway for managing ingress and egress traffic.

This allows teams to apply granular network policies to agent environments.

Google Cloud says credentials can be injected outside the reach of agents through the egress proxy architecture.

The underlying goal is to avoid treating agent isolation as only a container-level problem.

When agents can generate arbitrary commands and code, the infrastructure needs to consider what happens at the kernel and network layers as well.

A Control Plane and Data Plane Designed for Fast Activation

Agent Substrate separates its control and data planes to address the latency requirements of high-frequency agent workloads.

The control plane handles scheduling and coordination.

The data plane operates directly on pre-warmed workers and handles frequent suspend and resume operations.

Google Cloud says snapshots are written to local disk and Google Cloud Storage for durable state persistence.

When an agent becomes inactive, its environment can be suspended.

When the agent needs to continue working, its previous state can be restored.

The company says a sandboxed environment can resume to its previous state in less than 500 milliseconds and can then be suspended again when it becomes idle.

This approach is intended to avoid repeatedly starting a complete environment for every agent interaction.

The "Zero-Idle" Model Targets Compute Density

The architecture is also designed around the fact that autonomous agents may spend significant periods waiting.

Instead of reserving CPU and RAM continuously, Agent Substrate can suspend an agent when it becomes inactive.

Google Cloud says the runtime snapshots the guest hypervisor state to local disk and Cloud Storage, releasing CPU and memory while preserving the session state.

When another interaction arrives, the environment can be resumed.

The company describes this as a zero-idle model and says it can pack more than 1,000 dormant agents per host, delivering 10x higher compute density than traditional compute. These are Google Cloud's stated figures.

For workloads that need shared filesystems between agent turns, Google Cloud also points to an optional Filestore agent volume controller.

The controller provides persistent NFS storage for these stateful workspaces.

Kubernetes Still Handles the Infrastructure Layer

Agent Substrate does not replace Kubernetes.

Instead, Google Cloud positions Kubernetes as the foundation underneath the agent-specific execution layer.

Kubernetes continues to handle infrastructure-level responsibilities such as:

• Node self-healing

• Fleet autoscaling

• Cluster reliability

• Worker pod lifecycle

• Machine management

Meanwhile, Agent Substrate's data plane handles the high-frequency suspend and resume operations that would otherwise pass through the standard Kubernetes Pod lifecycle.

Google Cloud says this combination is intended to avoid introducing the full latency of a conventional Pod lifecycle for every short agent interaction.

Existing Kubernetes primitives such as Agent Sandbox and kernel-isolated Pods can also continue to operate alongside Agent Substrate for workloads that require standard Pod semantics.

This creates a layered model:

Kubernetes manages the infrastructure.

Agent Substrate manages agent execution.

Sandboxing provides isolation.

The data plane manages rapid activation and suspension.

Scaling Toward Million-Agent Infrastructure

Google Cloud frames Agent Substrate around infrastructure capable of supporting agent platforms at very large scale.

The announcement repeatedly references a 1 million-agent scale as a target for the architecture.

That does not mean a customer is automatically running one million agents simply by deploying Agent Substrate.

Instead, the architecture is designed around the infrastructure requirements involved in reaching that scale.

Those requirements include:

• High-density compute

• Rapid sandbox activation

• Efficient suspension

• Kernel isolation

• Network controls

• Large-scale scheduling

• Machine autoscaling

• Persistent state

• Kubernetes-based reliability

The distinction is important because agent scale is not determined only by model capability.

The underlying execution infrastructure also has to manage the environments in which those agents operate.

Optimized for Google Cloud Infrastructure

Google Cloud has also optimized Agent Substrate for infrastructure available through GKE.

The system uses custom ComputeClasses to dynamically manage machine pools across different machine shapes and families.

These pools can include both spot and on-demand capacity.

Agent Substrate on GKE also supports Google's Axion Arm-based processors.

Google Cloud says Axion can provide up to 30% better price-performance for sandbox workloads compared with competitive cloud offerings. This is a company-reported comparison and is not an independent benchmark.

For stateful agent workspaces, Agent Substrate can optionally integrate with Filestore agent volumes.

Google Cloud says these volumes can attach and detach NFS mounts in milliseconds and support:

• Read-Write-Many access

• POSIX-compliant file locking

• Persistent NFS storage

These capabilities are intended to support agents that need to maintain shared workspace state across interactions or collaborate without write collisions.

Nous Research Is an Early Design Partner

Google Cloud says Nous Research, the team behind the Hermes Agent, is actively building on Agent Substrate.

The company describes Nous Research as an early design partner that has evaluated the runtime's approach to isolation and identity requirements for agent workloads.

Google Cloud also states that Hermes is ranked number one by OpenRouter usage across productivity, coding, CLI and personal agent categories.

That ranking is attributed to Google Cloud's source and should be understood as a dated, source-reported ranking rather than an independent assessment.

Hervé Bizira, Chief Business Officer at Nous Research, also provided a statement about the company's experience with Agent Substrate, particularly around per-agent isolation, access control and compute resource preservation.

The source does not provide independently verified production-scale performance data from Nous Research.

Open Source, With Production Availability Managed Separately

Agent Substrate is being offered as an open-source solution.

Google Cloud says it can run on any Kubernetes cluster in any compute environment, while being optimized for GKE.

However, the availability model differs between non-production and production workloads.

The announcement states that Agent Substrate is available to all GKE customers for non-production workloads.

General availability support for production is available through an allowlist.

This distinction is important for organizations evaluating the technology for production deployments.

Google Cloud provides documentation for deploying Agent Substrate on GKE, along with an open-source repository for the project.

What Agent Substrate Changes for Kubernetes-Based AI Infrastructure

The announcement highlights a broader shift in how cloud infrastructure is being designed for autonomous agents.

Traditional container infrastructure assumes that workloads are frequently active and that the container lifecycle is an acceptable unit of execution.

Agent workloads can behave differently.

An agent may need a complete computer environment, execute untrusted code, interact with tools, remain idle for extended periods, and then resume with its previous state.

That creates a different infrastructure pattern.

Agent Substrate addresses this by combining several layers:

Kubernetes provides infrastructure management and reliability.

Sandboxing provides isolation.

The Agent Substrate data plane manages rapid activation and suspension.

Network controls govern agent connectivity.

Persistent storage preserves state when required.

ComputeClasses and autoscaling provide flexibility across infrastructure pools.

For engineering teams, the significance is therefore less about adding another Kubernetes runtime and more about adapting Kubernetes infrastructure to the operating characteristics of autonomous agents.

The Road Ahead for Agent Infrastructure

As autonomous agents move beyond simple chat interactions and begin executing code, operating tools, and maintaining state, infrastructure becomes part of the agent platform itself.

The challenge is not only how quickly a model can generate an answer.

It is also how safely and efficiently the system can create an execution environment, provide the tools the agent needs, isolate that environment, suspend it when it becomes idle, and restore it when work resumes.

Google Cloud's Agent Substrate is designed around that problem.

Its architecture combines Kubernetes management with a dedicated agent execution layer, sandbox isolation, rapid suspend/resume, network controls and high-density compute.

The company says the runtime can scale to millions of sandboxes and deliver sub-500ms resume operations, while supporting more than 500 suspend/resume activations per second. It also claims more than 1,000 dormant agents can be packed per host under its zero-idle model. These figures are based on Google Cloud's own announcement.

Agent Substrate is now available as an open-source solution, with non-production availability for GKE customers and production GA support through an allowlist.

For organizations building large agent platforms, the development reflects a growing focus on agent-native infrastructure rather than treating autonomous agents as simply another application running inside conventional containers.