AI agents spend most of their time doing nothing. Google says an agent in a typical interactive session waits 90% to 95% of the time for a model, an external API or a human reviewer. Its open-source runtime, Agent Substrate, is built to stop teams from paying for that idle time while keeping agent-written code away from the host.
On November 5, Google Cloud said it is donating Agent Substrate and gVisor to the Cloud Native Computing Foundation (CNCF) in Sandbox status, alongside a third project called OpenRL. The plan appeared in a Google Open Source Blog post on sandboxing untrusted AI agents at scale by Mofi Rahman and Brandon Royal. It is timed to KubeCon North America in Salt Lake City, which runs November 9 to 12.
What Google is giving to the CNCF
Google presents the three projects as one open stack for running agents. Each project covers a separate layer.
| Layer | Project | What it does |
|---|---|---|
| 1. Secure isolation | gVisor | Runs untrusted, agent-generated code behind an extra kernel boundary |
| 2. Agent runtime | Agent Substrate | Starts, parks and resumes agent sessions on shared compute |
| 3. Training orchestration | OpenRL | Coordinates Kubernetes-native reinforcement learning loops and evaluation sandboxes |
Google says the move gives the projects “a neutral, vendor-independent foundation” that works on any conformant Kubernetes cluster. The company argues that, without a shared open standard, teams keep building their own custom schedulers.
Why idle agents are a problem for Kubernetes
Google describes two issues. The first is wasted resources. A running agent Pod holds open tools, local code checkouts and unsaved file changes, so it keeps using compute while it waits. Google says this cost becomes unsustainable at around ten thousand active users.
Scaling to zero fixes the bill but hurts response time. According to Google, serverless-style cold starts can push wake-up delays past 20 seconds.
The second issue hits training and testing. Reinforcement learning and evaluation runs can need thousands of short-lived sandboxes. Creating and deleting that many Pods every minute, Google says, “overwhelms etcd, saturates kube-apiserver, and exhausts subnet IP addresses.”
What changes for developers and platform teams
The table below compares the two common options with the approach Google describes. Speed figures are Google’s own targets and claims, not independent tests.
| Approach | While the agent is idle | Time to wake up |
|---|---|---|
| Always-on Pod | Keeps holding compute | Instant |
| Scale to zero | Frees compute, loses the warm session | Can exceed 20 seconds |
| Agent Substrate | Snapshot saved to tiered storage, compute slot freed | Target under 500 milliseconds |
For teams running chat-style agents, the pitch is simple: pay for compute only while an agent works. For teams training or grading models, Substrate can activate, suspend and resume agents “without creating new Pod objects or stressing etcd.” That should ease pressure on the control plane and on IP address pools.
Security teams also get stricter defaults. The Agent Substrate repository on GitHub says actors run only in gVisor or Cloud Hypervisor microVM sandboxes, not plain Linux containers. Networking is default-deny. Actors hold no credentials, and an egress gateway injects them into approved outbound requests. Each active actor also gets a short-lived SPIFFE X.509 certificate.
The project is framework-agnostic and runs standard OCI container images. It targets the latest stable Kubernetes release and the one before it. On Google Kubernetes Engine (GKE), version 1.37 or later serves the required APIs by default, while version 1.36 needs them enabled as beta APIs.
How Agent Substrate works
This section covers the technical design for readers who want the details.
Actors and Workers
Substrate splits an agent’s state from the machine that runs it. An Actor holds one session’s state: its filesystem, environment variables, memory and network rules. Workers are pre-warmed Kubernetes Pods in a shared WorkerPool. One Worker can serve many isolated sessions, one after another.
The session lifecycle
Google lists four steps. First, a request reaches the atenet-router, a layer 7 proxy. If the target Actor is asleep, the proxy holds the request in memory and alerts the Substrate controller. Next, the controller places the Actor in a free slot in the warm Worker pool. Then the system restores memory and files and the agent continues where it stopped. When the agent goes idle again, Substrate saves a snapshot to tiered storage and frees the slot.
The GitHub README makes bolder claims than the blog. It cites resume times under 400 milliseconds, more than 1,500 activations per second and roughly 10x the density of standard containers. These are the project’s own numbers.
Where gVisor fits
Standard Linux containers share the host kernel. gVisor, which Google calls an application kernel written in Go, intercepts system calls in user space instead. That adds a second boundary between agent-written code and the host. For workloads that need hardware virtualization, Substrate also supports Cloud Hypervisor microVMs.
How this fits Google’s earlier agent moves
- November 2025: Google previewed Agent Sandbox for GKE at KubeCon North America.
- May 20, 2026: Google made GKE Agent Sandbox generally available and introduced Agent Substrate as a new open-source project. Its Google Cloud blog post on Agent Sandbox and Agent Substrate reported more than 16x growth in GKE sandboxes in under five months. It also cited 300 sandbox allocations per second per cluster, with 90% finishing in 200 milliseconds. LangChain and Lovable were named as customers.
- July 2026: The New Stack’s look at Kubernetes as an AI agent runtime called Substrate “a first look rather than a finished product.” It reported 30x or more oversubscription and noted that Solo.io had added Substrate to kagent as a selectable runtime.
- November 5, 2026: Google announced the CNCF donation and pointed to a 1.0 release of Agent Substrate.
What remains unclear
The project’s maturity is the biggest open question. Google’s blog refers to “the latest 1.0 release.” Yet the GitHub README still describes the project as pre-1.0, offers no backward compatibility guarantees and calls it “VERY young.” Its Releases section also lists no published release. Teams planning production use should check which state is current.
OpenRL gets far less detail. Google’s post describes its role but does not say who built it or how mature it is. Google also has not published independent benchmarks for its speed claims.
How to try it
Documentation lives at ate.dev, and the code is on GitHub under an Apache-2.0 license. gVisor has its own site at gvisor.dev. Developers can join the #substrate-dev and #substrate-user channels on the CNCF Slack.
At KubeCon, Google plans an Agent Substrate Day on November 9 and a hands-on workshop on November 11. It will also run an Expo Hall demo session and staff Google Cloud booth #122.
