---
url: "https://www.xcademia.com/news/google-brings-agent-substrate-to-gke-for-high-density-ai-agent-workloads"
title: "Google Brings Agent Substrate to GKE for High-Density AI Agent Workloads"
description: "Google brings Agent Substrate to GKE for high-density AI agent workloads with sandbox isolation, fast resume operations and active-only compute."
publishedAt: "2026-09-16T07:21:30.492+00:00"
updatedAt: "2026-09-16T07:24:11.263149+00:00"
type: news
category: devops
source_name: Google Cloud Blog
source_url: "https://cloud.google.com/blog/products/containers-kubernetes/agent-substrate-available-on-gke"
tags:
  - "#GoogleCloud"
  - "#GKE"
  - "#Kubernetes"
  - "#AIInfrastructure"
  - "#AIAgents"
  - "#AgentSubstrate"
  - "#CloudComputing"
  - "#DevOps"
---

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

> Google Cloud has made Agent Substrate available on GKE, introducing an open-source agent execution runtime designed for high-density sandboxing, secure isolation, fast suspend/resume operations, and large-scale autonomous agent workloads.

Source: **Google Cloud Blog** · 16 September 2026

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**.

### 

![info-1](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1789540023254-info-1--150-.webp)

## 
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.

### 

![info-2](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1789540047109-info-2--131-.webp)

## 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.

### 

![info-3](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1789543074858-info--3.webp)

## 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.

## Original source

https://cloud.google.com/blog/products/containers-kubernetes/agent-substrate-available-on-gke

## Tags

`#GoogleCloud` · `#GKE` · `#Kubernetes` · `#AIInfrastructure` · `#AIAgents` · `#AgentSubstrate` · `#CloudComputing` · `#DevOps`

---

## About this content

This Markdown news article is the citation-grade twin of [Google Brings Agent Substrate to GKE for High-Density AI Agent Workloads](https://www.xcademia.com/news/google-brings-agent-substrate-to-gke-for-high-density-ai-agent-workloads). It is published by **Xcademia** (UK Companies House 12322710) and is available for AI search engines and large language models to index, summarise, and cite.

When citing or quoting, please attribute *Xcademia* and link back to the source URL above.

- Source: https://www.xcademia.com/news/google-brings-agent-substrate-to-gke-for-high-density-ai-agent-workloads
- Publisher: Xcademia — https://www.xcademia.com
- Catalogue index: https://www.xcademia.com/llms-full.txt
