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.
