This post was originally published on this site

As AI shifts from human scale to agent scale, from systems of record to systems of action, and from simple requests to complex agentic workflows, the workload underneath your platform changes completely. An agent works in a continuous, stateful loop: It proposes an action, spins up subagents, executes code or tool calls inside a sandbox, and feeds the results back into the model for the next turn. Running that loop at scale requires the same open foundation and neutral governance that Kubernetes and the Cloud Native Computing Foundation (CNCF) brought to containers in the 2010s.

Today, we are announcing the donation of Agent Substrate, gVisor, and OpenRL, three open source projects that started at Google, to the CNCF following their acceptance last month into the CNCF Sandbox. To bring this open stack into managed production and accelerate it across TPUs and GPUs, we are also announcing that Agent Substrate has reached its 1.0 milestone and is now generally available as Agent Substrate on GKE.

Each project is now working through CNCF Sandbox onboarding with community maintainers and independent build infrastructure, and gVisor is on a path toward Incubation. These releases deliver an open stack that runs on any Kubernetes cluster, on any cloud, across CPUs, GPUs, or TPUs, by:

  • Scaling isolated agent environments without idle compute overhead with Agent Substrate (now 1.0 and GA on GKE): Agents execute code or tests for a few seconds, then wait on model turns, external APIs, or human input. Keeping a dedicated container alive during those pauses ties up memory and compute. Agent Substrate decouples stateful agent sessions and identities from active compute, snapshotting idle agents to storage and restoring them in under 500 milliseconds to run millions of sandboxes at 10x container density.

  • Isolating untrusted code within a sandbox with gVisor: Agents routinely generate and run unreviewed code and external packages, making standard containers that share a host Linux kernel a security risk. gVisor isolates generated code inside a lightweight userspace application kernel at container packing density on any Linux node.

  • Distributing post training and serving efficiently with OpenRL: Training agents with reinforcement learning (RL) gives builders an open loop to learn across millions of parallel sandboxed rollouts. OpenRL orchestrates self-hosted RL post-training loops in plain Python on Kubernetes.

Scale fully isolated agent environments with Substrate

Agents need isolated compute resources and strict access boundaries, yet spend most of their time waiting: executing code for a few seconds, then pausing while a model reasons or a human responds. They need a discrete identity and central enforcement point to ensure the agent only accesses authorized tools and services without holding sensitive keys. In standard Kubernetes, giving every active agent its own Pod locks up memory and CPU while the agent sits idle, forces the control plane to track millions of persistent objects it was never designed to hold, and ties identities directly to Pods. At the same time, identities are intrinsically tied to Kubernetes Pods, adding exponential complexity for controlling access and secrets.

Agent Substrate solves this by separating the stateful agent from the underlying compute:

  • Actors hold each agent’s memory, files, and discrete identity.

  • Workers are reusable execution sandboxes drawn from a warm Kubernetes pool.

  • Gateways enforce inbound and outbound access control and inject secrets based on Actor identity, keeping sensitive keys out of the agent environment.

When an agent pauses to wait on a model turn or tool call, Agent Substrate snapshots the agent’s memory and files to storage and immediately returns the Worker to the warm pool. When the next request arrives, Agent Substrate restores the Actor onto any available Worker in under 500 milliseconds and picks up right where it left off. Think of it as a hotel room rather than a house: you don’t keep a room when you leave town, and a new room is ready when you come back.

1

Agent Substrate decouples stateful Actors and policy Gateways from a warm pool of Kubernetes Workers, restoring idle sessions in under 500 milliseconds.

Since public development started in May 2026, the Agent Substrate project has grown to more than 100 contributors. Early design partners like Nous Research are building Hermes Enterprise on it, and it already powers other CNCF projects like kagent.

Further, reaching the 1.0 milestone shows that Agent Substrate can accept production workloads across millions of sandboxes, achieving 10x the density of standard container runtimes, and performing more than 500 suspend and resume activations per second.

Underneath, you can choose Cloud Hypervisor microVMs or gVisor as your isolation boundary without changing how you manage agent lifecycles. Because Agent Substrate runs standard OCI containers, it works out of the box with Agent Development Kit (ADK) agents, stateful coding environments, and productivity agents.

With today’s general availability of Agent Substrate on GKE, you can run this runtime as a managed capability on Google Cloud or deploy the open-source code on any Kubernetes cluster. For teams that want a dedicated microVM compute service through an API without having to manage clusters, Agent Substrate complements Agent Compute Engine, our Titanium microVM service that features fast hibernation and parallel environment-forking for evaluation and RL pipelines.

SPIRITT is building their SPIRITT Workspace, a platform where agents run real work autonomously while humans collaborate to steer the vision, on top of Agent Substrate on GKE. 

”At SPIRITT, every customer gets an autonomous AI workspace where an agent, or a whole swarm of agents, builds, runs, and ships real work across the organization, from code and development cycles to marketing and operations. Agent Substrate on GKE gives us the security isolation to let agents execute code safely, the extensibility to plug in our own runtime, and the density to run every customer’s agents economically at scale.” – Tamir Magen, CEO, SPIRITT

Isolate untrusted agent code with gVisor

When agents shift from systems of record to systems of action, they run generated shell commands and unreviewed packages. Standard containers share the host Linux kernel with every other workload on the node, which is a risky bet for untrusted code. Hardware microVMs offer a strong boundary, and Agent Substrate supports them natively. Many teams also need strong isolation that runs at container density across any standard Linux instance, even when bare metal or nested virtualization isn’t available.

gVisor provides that isolation through a lightweight application kernel written in Go. Sitting between the container and the host OS, gVisor intercepts and handles application system calls in userspace so untrusted code never talks directly to the host kernel. Open sourced by Google in 2018, gVisor runs millions of sandboxes every day underneath GKE Sandbox and Cloud Run. Outside Google, Anthropic and OpenAI use it to contain code execution, Modal and Snowflake run their execution sandboxes on it, and Ant Group and Tencent run it in production at scale.

Three capabilities make gVisor a natural fit for agent fleets:

  • Container density and flexible memory: Unlike VMs that preallocate fixed blocks of RAM, gVisor keeps a container process model where memory scales up and down with the workload, packing more agents onto every node and lowering your cost per agent.

  • Native GPU, TPU, and snapshot support: gVisor supports GPUs, TPUs, and checkpoint/restore natively, so agents can access accelerators inside the sandbox and pause when idle.

  • Runs anywhere Linux runs: Because it doesn’t require nested virtualization, gVisor deploys identically across any cloud or local Linux node. Northflank, for example, uses gVisor to sandbox GPU workloads when nested virtualization isn’t available.

Donating gVisor to the CNCF clears a longstanding performance barrier for the community. Sandboxed infrastructure providers, including Google, all carry host kernel patches that bring gVisor’s I/O performance close to that of native Linux, but upstream Linux maintainers declined to merge them while the project was owned by a single vendor. Moving to neutral CNCF governance opens the path to upstreaming those kernel optimizations, so every builder gets near native performance out of the box. With this move, Ant Group, Modal, and Tines have committed to join gVisor’s maintainers, with OpenAI, Tencent, and NVIDIA continuing their contributions.

Scale RL post training on Kubernetes with OpenRL

The sandbox that runs your agent in production is the exact same environment you need to train an agent with reinforcement learning. Today, most frontier capability gains come from RL post-training: running millions of multiturn rollouts inside real tools, scoring the outcomes, and updating model weights. Building that loop yourself usually means forking a monolithic RL framework and debugging distributed weight transfers before you ever touch your training algorithm.

OpenRL brings a clean, self-hosted Python post-training loop directly to your Kubernetes cluster, with:

  • Simple Python primitives: Write your training loop using four clean primitives (sample, forward_backward, optim_step, and save_state) through a Tinker compatible API while keeping your weights and data on your own cluster. Existing tinker-cookbook recipes run unchanged, supporting both LoRA adapters and full parameter fine-tuning.

  • Pluggable engines and Kubernetes scheduling: OpenRL uses Kubernetes Dynamic Resource Allocation (DRA) to partition your accelerator pool and orchestrate RL work on the shared pool. Its pluggable architecture uses standard engines, including PyTorch/AutoModel for training and vLLM for sampling, with Gemma and Qwen validated out of the box, and with TPU support on the roadmap.

OpenRL also pairs with llm-d, the CNCF distributed inference and RL project founded by Red Hat, Google Cloud, IBM Research, CoreWeave, and NVIDIA that recently reached 1.0, to keep your accelerators busy across both phases of RL. Here, llm-d provides:

  • Prefix-aware rollout routing: The llm-d router routes multiturn rollouts to samplers that already hold matching KV cache prefixes, cutting redundant prefill compute.

  • GPU time-slicing between training and sampling: In RL training, samplers and trainers take turns, leaving one set of chips idle while the other works. OpenRL uses llm-d time-slicing to share the same physical GPUs between sampling and training, reclaiming idle accelerator cycles the same way Agent Substrate reclaims idle CPU and RAM.

2

OpenRL drives plain Python RL loops on Kubernetes, running episodes inside Agent Substrate sandboxes while llm-d routes rollouts and time slices accelerators.

OpenRL is the newest layer of this stack by a wide margin. It started in February as a research preview, and we are bringing it to the CNCF early on purpose. Its north star is one recipe for any model on any accelerator, and no single company can get there alone. To get there, you need the people building accelerators (NVIDIA, AMD, Intel, and TPUs), inference engines (llm-d, vLLM, SGLang), training frameworks, and open-weight models starting with Gemma and Qwen. Setting up neutral CNCF governance before the design hardens makes room for everyone to build it together.

Why the CNCF, and why now

Improving the security and efficiency of AI agents takes joint design across the runtime, scheduler, compiler, and silicon. The past year made the need for affordable, isolated sandboxing and open post-training infrastructure exceedingly clear. Donating Agent Substrate, gVisor, and OpenRL to the CNCF reaffirms Google’s commitment to open collaboration and co-investment. Vendor-neutral ownership lets cloud providers, hardware vendors, and independent software companies participate in the future growth of agentic workloads equally. 

We believe that these donations will accelerate the development and adoption of agentic workloads through these projects similarly to what we saw with Kubernetes.

Come find us at KubeCon

Join us at KubeCon + CloudNativeCon North America in Salt Lake City (November 9 to 12) across our sessions and at the Google Cloud booth to learn more about Agent Substrate, OpenRL, and gVisor. You will also hear soon from community partners including Modal, Anyscale, and Tecton on what this open stack means for their agentic workloads. In the meantime, here is where to start: