Agent Substrate Reaches 1.0 as Google Hands Its Agent Stack to the CNCF

TL;DR

• Agent Substrate is an open-source runtime that runs each AI agent session as an isolated sandbox on a Kubernetes cluster.
• On 6 November 2026 Google donated Agent Substrate, gVisor and OpenRL to the CNCF Sandbox, and released Agent Substrate 1.0 as a managed capability on Google Kubernetes Engine.
• A session is split in two: an Actor holds its memory, files and identity, and a Worker is a reusable sandbox taken from a warm pool.
• An idle Actor is snapshotted to storage, its Worker returns to the pool, and the session comes back on a free Worker in under 500 milliseconds.
• Google reports 10x the density of standard container runtimes, more than 500 suspend and resume activations per second, and over 100 contributors since development opened in May 2026.
• gVisor, the userspace application kernel that isolates untrusted code, carried host kernel patches that upstream Linux declined to merge while one vendor owned the project, and neutral ownership opens that path.
• OpenRL brings the reinforcement-learning loop to the same sandbox, with four Python primitives and a Tinker compatible API.
• Agent Substrate on GKE requires Standard clusters on version 1.37 or later and x86 CPU worker nodes.
• An operator still owns egress policy, the snapshot size that sets resume latency, and the identity each Actor carries.

Agent Substrate preserves session state while returning idle worker capacity

An agent works in a loop: it proposes an action, runs code or a tool call, reads the result, and waits while a model reasons or a person answers. Google's post puts the wait at the centre of the design problem. A standard Kubernetes Pod that stays allocated through those pauses holds memory and CPU that nothing uses, forces the control plane to track a persistent object for every agent in the fleet, and ties an identity to a Pod that may outlive its usefulness.

Substrate separates the stateful part of the session from the compute that runs it. An Actor carries the memory, the files and a discrete identity. A Worker is a reusable sandbox taken from a pool that is kept warm. A gateway sits on both sides of the sandbox, enforcing access rules and injecting credentials so that a secret never enters the agent's environment. When the agent pauses, the runtime writes its memory and files to storage and hands the Worker back to the pool.

The request path comes from the Open Source blog post, and it is worth knowing because it explains where latency lives. An incoming call reaches the atenet-router proxy. When the target Actor is suspended, the proxy holds the request in memory and alerts the Substrate controller. The controller assigns the Actor to a free slot in the warm pool, the state reloads from tiered storage, the process wakes up, and the proxy delivers the request. Google reports the restore at under 500 milliseconds and more than 500 activations per second, with thousands of agents waking every second without creating Pod objects or loading etcd.

The identity model is the part a platform team will feel first. The GKE documentation states that Substrate issues a unique SPIFFE X.509 certificate and a JSON Web Token for each Actor, giving each session a distinct identity for request attribution. Credentials stay outside the sandbox: when an outbound request matches an egress rule, the gateway authenticates the Actor's mTLS tunnel and replaces placeholder headers with a fetched secret or the Actor's token.

gVisor spent years waiting for a neutral owner to merge its kernel patches

Substrate supports gVisor and Cloud Hypervisor microVMs as isolation boundaries. It is a lightweight application kernel written in Go, open sourced in 2018, sitting between the container and the host operating system and handling application system calls in userspace so that generated code never talks to the host kernel directly. Google says it runs millions of sandboxes a day underneath GKE Sandbox and Cloud Run, and names Anthropic and OpenAI as users for code execution, Modal and Snowflake for execution sandboxes, and Ant Group and Tencent in production at scale.

The donation matters because it changes the path available for upstreaming the kernel patches. Google's post states that sandboxed infrastructure providers, Google included, carry host kernel patches that bring gVisor's I/O performance close to native Linux, and that upstream Linux maintainers declined to merge those patches while the project was owned by a single vendor. Neutral CNCF governance opens the path to upstreaming them. Ant Group, Modal and Tines have committed to join gVisor's maintainers, with OpenAI, Tencent and NVIDIA continuing their contributions.

What the kernel patch queue changes for a buyer

Read that as a procurement signal. A governance change that determines what can be merged into a Linux kernel has a performance consequence and a date attached to it, and the maintainer list is where the evidence sits. For a team choosing an isolation boundary this quarter, the honest position is that gVisor's I/O advantage depends on out-of-tree patches today and on upstream work that has just become possible.

OpenRL puts the reinforcement-learning loop on the same sandbox

OpenRL is the youngest of the three projects, a research preview in February that now reaches the CNCF early on purpose. The argument in the post is that the sandbox running an agent in production is the same environment needed to train one with reinforcement learning: millions of multiturn rollouts inside real tools, scored, then folded back into the weights. Building that loop from scratch usually means forking a monolithic framework and debugging distributed weight transfers before touching the training algorithm.

OpenRL exposes four primitives, sample, forward_backward, optim_step and save_state, behind an API compatible with Tinker, with weights and data staying on the operator's own cluster. It uses Kubernetes Dynamic Resource Allocation to partition an accelerator pool, trains through PyTorch and AutoModel, samples through vLLM, and validates Gemma and Qwen out of the box. It pairs with llm-d, the distributed inference project that reached 1.0, for prefix-aware routing of rollouts to samplers that already hold matching KV cache, and for time-slicing the same GPUs between sampling and training.

The shared-resource idea is the one to copy. Time-slicing training and sampling on the same chips attacks the same waste as snapshotting idle agents: one set of hardware sits idle while the other phase runs, and both projects reclaim that idle time, which buys capacity back without a purchase.

Agent Substrate on GKE has specific deployment requirements

The donation and general availability were announced together. The donation covers three projects entering the CNCF Sandbox, the foundation's entry stage, announced at KubeCon and CloudNativeCon North America in Salt Lake City. General availability covers Agent Substrate on GKE, Google's managed product. Agent Substrate on GKE is generally available as a managed runtime. The three projects are working through CNCF Sandbox onboarding with community maintainers and independent build infrastructure.

The managed GKE capability has specific deployment constraints. The GKE documentation requires Standard clusters on version 1.37 or later on both the control plane and the node pools, with x86 CPU worker nodes. Autopilot is excluded because the node agent, atelet, runs as a privileged DaemonSet, and microVM pools need nested virtualisation or bare metal. Accelerator-heavy agent workloads use the Pod-based path that Google calls Agent Sandbox, where GPUs and TPUs are supported with gVisor.

The restore figures carry conditions as well. Memory, root file system and volumes come back in under one second when the Actor resumes with the same hardware, sandbox runtime and container image. A change to the node hardware or runtime restores the root file system and volumes and restarts the processes. Updating the image while the Actor is suspended restores the volumes into containers started from the updated image. Resume latency also scales with snapshot size, which is why the documentation pushes large workspaces onto external Filestore volumes and keeps their data outside the snapshot.

What an operator still owns after the donation

Egress is the first item. Substrate blocks all outbound traffic by default, including traffic to other Actors, to the Kubernetes control plane, to the Compute Engine metadata server and to the internet, and it blocks non-DNS UDP, raw TCP connections and HTTP WebSocket upgrades. Rules live in an EgressPolicy resource and accept fully qualified domain names or wildcard hostnames, with no IP addresses and no CIDR ranges. A fleet that needs to reach an internal service by address has to put a name in front of it.

Capacity is the second. The warm pool sets both the latency a waking agent sees and the idle spend the operator carries, and the 10x density figure compares Substrate against container runtimes that hold one Pod per agent. A team sizing a pool for a few hundred concurrent sessions should measure its own ratio in a Standard cluster on 1.37 before quoting Google's number internally.

Governance is the third, and it is the one with the longest horizon. Three projects have just entered the foundation's entry stage, gVisor is on a path toward Incubation, and the design of the agent runtime, the sandbox kernel and the training loop will be settled in public maintainer forums. For teams that run agent workloads on their own Kubernetes estate, the transferable design is the split itself: stateful session identity in one layer, disposable compute in another, credentials enforced by the gateway.

Sources

• Powering open infrastructure for autonomous agents, Google Cloud Blog, 2026-11-06, cloud.google.com
• Sandboxing untrusted AI agents at scale: Google donates Agent Substrate and gVisor to the CNCF, Google Open Source Blog, 2026-11, opensource.googleblog.com
• Plan an architecture for AI agent workloads on GKE, Google Cloud documentation, docs.cloud.google.com

Source: three Google documents read in full on 9 November 2026, the Google Cloud blog post by Drew Bradstock dated 6 November 2026, the Google Open Source blog post on sandboxing untrusted agents at scale, and the GKE documentation page on planning an architecture for AI agent workloads. Every figure and limit above, including the 10x density, the 500 millisecond restore, the 500 activations per second, the 100 contributors, the gVisor kernel-patch sourcing, and the 1.37, x86 and no-accelerator constraints, comes from those pages.