agent substrate: Google Donates Its Agent Orchestrator to the CNCF as 1.0 Goes GA

agent substrate, Google's open source orchestrator for sandboxed AI agent workloads, reached its 1.0 milestone this week and is now generally available as Agent Substrate on GKE. At the same time, Google announced it is donating the project, along with gVisor and OpenRL, to the Cloud Native Computing Foundation, where all three were accepted into the Sandbox last month. The announcement, made ahead of KubeCon North America in Salt Lake City, gives the cloud-native ecosystem a vendor-neutral runtime stack aimed squarely at the problem of running stateful, untrusted agent code at scale. Source

This post covers what shipped, how the runtime works, what Google carefully scoped in its claims, and what the donation means for teams building agent infrastructure. The facts come from Google's Cloud and Open Source blogs, with Drop Agentic's report as an independent read.

The two problems agent substrate attacks

Google's argument starts with a mismatch: the Pod, Kubernetes' unit of compute, assumes a program that boots, serves traffic, and runs until stopped. An AI agent does the opposite. It executes a step, calls a model, and waits. Google says a typical interactive agent spends 90 to 95 percent of its time waiting on model inference, external APIs, or human review, consuming zero CPU while holding critical state in memory and on disk: language runtimes, local Git repositories, uncommitted edits, and tool sessions. Source

That creates what Google calls the idle resource problem. Keep a dedicated Pod warm for every agent and you pay for compute around the clock; at ten thousand active users, the cost becomes hard to justify. Scale to zero instead and the cold start forces the container to clone repositories, reinstall packages, and rebuild memory, pushing wakeup latency past 20 seconds and breaking the interactive feel. Source

The second problem hits at the other extreme: control plane overload. Reinforcement learning loops and benchmark suites need thousands of short-lived sandboxes starting and stopping every minute. If each sandbox is a full Pod, scheduling churn overwhelms etcd, saturates the kube-apiserver, and exhausts subnet IP addresses. Kubernetes was built to manage stable application topologies, not to act as what Google calls a microsecond sandbox allocator. Source

How the runtime works

Agent Substrate adds an actor-based control and data plane on top of Kubernetes, and its core move is to separate state from compute. An Actor represents one agent session: its filesystem, environment variables, memory state, and network rules. A Worker is a pre-warmed Pod in a shared pool that supplies the actual compute, equipped with container runtimes and sandbox boundaries. Source

The lifecycle of a single agent turn shows why this matters. An incoming request hits an L7 proxy called atenet-router. If the target Actor is suspended, the proxy parks the request and alerts the Substrate controller, which places the Actor on a warm Worker slot. The Actor's memory and disk state restore from tiered storage, and Google says the agent resumes in under 500 milliseconds, right where it paused. When the turn finishes, Substrate snapshots the Actor back to storage and frees the Worker slot. Because Actor state is managed directly rather than through Pod objects, thousands of agents can activate, suspend, and resume every second without stressing etcd. Source

At the 1.0 milestone, Google's figures are 10x the density of standard container runtimes, more than 500 suspend and resume activations per second, and production workloads across millions of sandboxes. The runtime accepts standard OCI containers, so it works out of the box with Agent Development Kit agents and stateful coding environments, and you can pick Cloud Hypervisor microVMs or gVisor as the isolation boundary without changing how you manage agent lifecycles. Google also positions it as complementary to Agent Compute Engine, its Titanium microVM service with fast hibernation and parallel environment-forking for evaluation and RL pipelines. Source

gVisor: the isolation layer with a governance story

Agents routinely execute model-generated, unreviewed code, and standard containers share the host Linux kernel with every other workload on the node. gVisor answers that with a lightweight application kernel written in Go that intercepts system calls in userspace, so untrusted code never talks directly to the host kernel. Open sourced by Google in 2018, it already runs millions of sandboxes a day under GKE Sandbox and Cloud Run; Google says Anthropic and OpenAI use it to contain code execution, and Modal, Snowflake, Ant Group, and Tencent run it in production. Source

The donation has an unusually concrete payoff here. Sandboxed infrastructure providers, Google included, carry host kernel patches that bring gVisor's I/O performance close to native Linux, but upstream Linux maintainers declined to merge them while a single vendor owned the project. Neutral CNCF governance opens a path to upstreaming those optimizations. Google says Ant Group, Modal, and Tines have committed to join gVisor's maintainers, with OpenAI, Tencent, and NVIDIA continuing to contribute, and that gVisor is on a path toward CNCF Incubation. Source

OpenRL: the newest and greenest layer

The third donated project targets training rather than serving. OpenRL runs self-hosted reinforcement learning post-training loops in plain Python on Kubernetes, using four primitives (sample, forward_backward, optim_step, save_state) through a Tinker-compatible API, with tinker-cookbook recipes running unchanged. It schedules across accelerator pools with Kubernetes Dynamic Resource Allocation, uses PyTorch with AutoModel for training and vLLM for sampling, and validates Gemma and Qwen out of the box, with TPU support on the roadmap. Source

OpenRL pairs with llm-d, the CNCF distributed inference project founded by Red Hat, Google Cloud, IBM Research, CoreWeave, and NVIDIA, for prefix-aware rollout routing and GPU time-slicing between sampling and training. Google is unusually candid about maturity here: OpenRL started in February as a research preview and is, in Google's words, the newest layer of the stack by a wide margin, donated early on purpose so neutral governance is in place before the design hardens. Source

What Google did not claim

The headline numbers deserve attribution. The under-500-millisecond restore, the 10x density figure, and the 500-plus activations per second are Google's own published figures for the 1.0 release; we did not find independent benchmarks of the stack this week. General availability applies to the managed offering, Agent Substrate on GKE. The open source code runs on any conformant Kubernetes cluster, but self-managed operators are adopting a project that entered the CNCF Sandbox, the foundation's entry level, only last month. Source

Drop Agentic's coverage reflects the same caution: its report attributes every performance and scale claim explicitly to Google Cloud rather than asserting them independently. And the three projects are at very different maturity levels: gVisor has run production workloads since 2018, Agent Substrate just hit 1.0, and OpenRL is a research preview graduate. Treating them as one equally proven stack would be a mistake. Source

What this means for agent operators, in our assessment

This section is our read, separate from the sources. The donation confirms that agent infrastructure is following the container playbook: a de facto standard emerges from one vendor, then moves to neutral governance once the ecosystem decides the layer is too important to be proprietary. Google is explicit that it wants a repeat of what Kubernetes did for containers, and the maintainer commitments from Ant Group, Modal, and Tines suggest the bet is attracting real co-investment rather than courtesy endorsements. Source

For teams already running agent workloads, the practical question is where this fits beside what you have. If you sandbox agent code execution today with dedicated VMs or hand-rolled container pools, Substrate's snapshot-and-restore model directly attacks your two biggest costs: idle compute and cold starts. We covered Google's lower-level microVM approach in our Google Agent Compute Engine post, and Microsoft's answer to the same isolation problem in our execution containers coverage; Agent Substrate sits one layer up, multiplexing stateful sessions onto whatever isolation boundary you choose.

The second observation is about the coordinator pattern. A runtime that can suspend and restore thousands of stateful agents per second makes the persistent-agent architectures we described in our managed deep agents post cheap to operate, not just possible to build. Our advice: if you are designing an agent platform for 2027, evaluate Substrate's actor model now, in a sandbox project, but pin your production plans to the managed GKE offering until the open source control plane has more miles on it.