{"slug": "powering-open-infrastructure-for-autonomous-agents", "title": "Powering open infrastructure for autonomous agents", "summary": "Google donated three open source projects it originated — Agent Substrate, gVisor and OpenRL — to the Cloud Native Computing Foundation, following their acceptance into the CNCF Sandbox last month. Agent Substrate reached its 1.0 milestone and is generally available as Agent Substrate on GKE; it snapshots idle agents to storage and restores them in under 500 milliseconds, running millions of sandboxes at 10x container density, while gVisor isolates generated code in a userspace application kernel and OpenRL orchestrates self-hosted reinforcement learning post-training loops in plain Python on Kubernetes. The stack runs on any Kubernetes cluster, on any cloud, across CPUs, GPUs or TPUs, and gVisor is on a path toward CNCF Incubation.", "body_md": "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.\n\nToday, we are announcing the donation of [**Agent Substrate**](http://ate.dev), [** gVisor**](https://gvisor.dev), and [** OpenRL**](https://openrl.dev), 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**](https://docs.cloud.google.com/kubernetes-engine/ai-ml/about-agent-substrate).\n\nEach 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:\n\n**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.\n\n**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.\n\n**Distributing post training and serving efficiently with** [**OpenRL**](https://openrl.dev): 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.\n\nAgents 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.\n\nAgent Substrate solves this by separating the stateful agent from the underlying compute:\n\n**Actors** hold each agent's memory, files, and discrete identity.\n\n**Workers** are reusable execution sandboxes drawn from a warm Kubernetes pool.\n\n**Gateways** enforce inbound and outbound access control and inject secrets based on Actor identity, keeping sensitive keys out of the agent environment.\n\nWhen 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.\n\nSince 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](https://cloud.google.com/blog/products/containers-kubernetes/agent-substrate-available-on-gke), and it already powers other CNCF projects like [kagent](https://kagent.dev).\n\nFurther, 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**.\n\nUnderneath, 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.\n\nWith today's **general availability of** [**Agent Substrate on GKE**](https://docs.cloud.google.com/kubernetes-engine/ai-ml/about-agent-substrate), 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**](https://cloud.google.com/blog/topics/ai-infrastructure/agent-compute-engine-deep-dive), our Titanium microVM service that features fast hibernation and parallel environment-forking for evaluation and RL pipelines.\n\n[SPIRITT](https://spiritt.ai/) 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. \n\n”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\n\nWhen 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.\n\n[gVisor](https://gvisor.dev) 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](https://www.anthropic.com/engineering/how-we-contain-claude) and [OpenAI](https://openai.com/index/securing-research-infrastructure-for-advanced-ai/) use it to contain code execution, [Modal](https://modal.com/docs/guide/security) and [Snowflake](https://www.snowflake.com/en/blog/engineering/rebuild-snowpark-execution-sandbox-with-gvisor/) run their execution sandboxes on it, and [Ant Group](https://gvisor.dev/blog/2021/12/02/running-gvisor-in-production-at-scale-in-ant/) and [Tencent](https://gvisor.dev/blog/2026/04/23/scaling-agentic-rl-sandboxes-to-the-millions-with-gvisor-at-tencent/) run it in production at scale.\n\nThree capabilities make gVisor a natural fit for agent fleets:\n\n**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.\n\n**Native GPU, TPU, and snapshot support:** gVisor supports [GPUs](https://gvisor.dev/docs/user_guide/gpu/), [TPUs](https://gvisor.dev/docs/user_guide/tpu/), and [checkpoint/restore](https://gvisor.dev/docs/user_guide/checkpoint_restore/) natively, so agents can access accelerators inside the sandbox and pause when idle.\n\n**Runs anywhere Linux runs:** Because it doesn't require nested virtualization, gVisor deploys identically across any cloud or local Linux node. [Northflank](https://northflank.com/blog/gpu-sandboxes), for example, uses gVisor to sandbox GPU workloads when nested virtualization isn't available.\n\nDonating 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](https://gvisor.dev/blog/2026/10/02/gvisor-cncf/), with OpenAI, Tencent, and NVIDIA continuing their contributions.\n\nThe 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.\n\n[OpenRL](https://openrl.dev) brings a clean, self-hosted Python post-training loop directly to your Kubernetes cluster, with:\n\n**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.\n\n**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.\n\nOpenRL also pairs with [**llm-d**](https://llm-d.ai), the CNCF distributed inference and RL project founded by Red Hat, Google Cloud, IBM Research, CoreWeave, and NVIDIA that [recently reached 1.0](https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference?e=48754805), to keep your accelerators busy across both phases of RL. Here, llm-d provides:\n\n**Prefix-aware rollout routing:** The [llm-d router](https://llm-d.ai/docs/dev/architecture/router) routes multiturn rollouts to samplers that already hold matching KV cache prefixes, cutting redundant prefill compute.\n\n**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](https://github.com/llm-d-incubation/llm-d-rl-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.\n\nOpenRL 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.\n\nImproving 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.\n\nWe believe that these donations will accelerate the development and adoption of agentic workloads through these projects similarly to what we saw with Kubernetes.\n\nJoin us at [KubeCon + CloudNativeCon North America](https://events.linuxfoundation.org/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:\n\n**Follow the CNCF Sandbox applications:** gVisor [#521](https://github.com/cncf/sandbox/issues/521), Agent Substrate [#523](https://github.com/cncf/sandbox/issues/523), and OpenRL [#518](https://github.com/cncf/sandbox/issues/518), alongside cohort peer KubeRay [#525](https://github.com/cncf/sandbox/issues/525)\n\n**Kick the tires:** [ate.dev](http://ate.dev), [gvisor.dev](https://gvisor.dev), and [openrl.dev](https://openrl.dev) \n\n**Run agents on GKE today:** [Agent Substrate on GKE](https://docs.cloud.google.com/kubernetes-engine/ai-ml/about-agent-substrate), and [GKE Sandbox](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods)\n\n**Read the deep dives:** [Agent Substrate on GKE](https://cloud.google.com/blog/products/containers-kubernetes/agent-substrate-available-on-gke), [gVisor's move to the CNCF](https://gvisor.dev/blog/2026/10/02/gvisor-cncf/), and [Introducing OpenRL](https://opensource.googleblog.com/2026/06/introducing-openrl-a-self-hosted-post-training-api-for-fine-tuning-llms.html)", "url": "https://wpnews.pro/news/powering-open-infrastructure-for-autonomous-agents", "canonical_source": "https://cloud.google.com/blog/products/containers-kubernetes/open-infrastructure-for-autonomous-agents-comes-to-cncf/", "published_at": "2026-11-05 12:30:00+00:00", "updated_at": "2026-11-05 12:54:35.047362+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools", "ai-safety", "mlops"], "entities": ["Google", "Agent Substrate", "gVisor", "OpenRL", "Cloud Native Computing Foundation", "Kubernetes", "Google Kubernetes Engine"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/powering-open-infrastructure-for-autonomous-agents", "markdown": "https://wpnews.pro/news/powering-open-infrastructure-for-autonomous-agents.md", "text": "https://wpnews.pro/news/powering-open-infrastructure-for-autonomous-agents.txt", "jsonld": "https://wpnews.pro/news/powering-open-infrastructure-for-autonomous-agents.jsonld"}}