Google Wants a Kubernetes Moment for AI Agents

In 2014 Google open-sourced Kubernetes, a container orchestrator modeled on its internal Borg system. A year later it handed the project to a brand-new foundation, the CNCF, and let everyone else build on it. That one decision is a big reason why every cloud provider now sells you the same API for running containers, and why Google Cloud still gets to sell the most polished version of it.

On November 5, 2026, Google tried the same move again, this time for AI agents. In a Google Cloud blog post, Drew Bradstock (VP of Product Management for Orchestration and Kubernetes at Google) announced that Google is donating three of its projects to the CNCF. All three were accepted into the CNCF Sandbox in October:

Agent Substrate also hit 1.0 the same day and is generally available as a managed product on GKE. If you squint, it is the 2015 playbook again: give the core away to a neutral foundation, sell the managed version.

Why agents don't fit the Pod model

Start with what an agent looks like at runtime. A user asks for something. The agent sends a prompt to a model, gets back a plan, runs a tool call or a chunk of generated code, feeds the result back to the model, maybe spawns a couple of subagents, and repeats. That loop can run for minutes or days, and it carries state the whole time: conversation history, files it wrote, credentials it uses.

Most of that time the agent is waiting. It works for a few seconds, then sits idle while the model thinks, an API responds, or a human approves a step. Google's post names three problems that fall out of this shape.

Idle Pods burn money. The obvious Kubernetes design is one Pod per agent session. That Pod holds its CPU and memory requests the entire time, including the long stretches where nothing is happening. Multiply by thousands of users and you are paying for a cluster full of agents staring at the wall. It also means the control plane has to track a huge number of long-lived objects, and the agent's identity ends up tied to a Pod, which makes access control and secret handling awkward.

Agents run code nobody reviewed. A coding agent writes a script and executes it. It pip installs a package it found. A regular container shares the host's Linux kernel with every other container on the node, so a kernel exploit in that script is a node compromise. Namespaces and cgroups limit what a process can see and consume, and a seccomp profile trims the syscalls it can make, but the code still runs against the host kernel.

RL training is a pain to self-host. Teams that want to improve a model on their own agent workflows with reinforcement learning usually fork a large training framework and spend weeks debugging how model weights move between the training and sampling processes.

Each of the three projects maps to one of those problems.

Agent Substrate: separating agent state from compute

Agent Substrate splits "the agent" from "the machine the agent runs on." It does this with three components:

• Actors hold an agent's state: memory, files, and its own identity.
• Workers are reusable sandboxes that come from a warm pool of capacity in the cluster.
• Gateways sit in front of agents, enforce inbound and outbound access rules, and inject secrets based on the Actor's identity, so API keys never land inside the agent's environment.

When an agent goes idle, Agent Substrate snapshots its memory and files to storage and hands the Worker back to the pool. When the next request for that agent arrives, it restores the Actor onto whichever Worker is free. Google says the restore takes under 500 milliseconds.

The difference from a Pod per agent is when compute is reserved. A Pod holds its CPU and memory requests for the whole session. An Actor holds a Worker only while it handles a request, and between requests it exists as a snapshot in storage.

The numbers Google quotes are 10x density compared with standard container runtimes and more than 500 suspend and resume operations per second.

Practical details if you plan to try it:

• Workers run standard OCI container images, so an agent built with Google's Agent Development Kit, a coding sandbox, or your own Python service can run without repackaging.
• Isolation is pluggable: Cloud Hypervisor microVMs or gVisor, without changing how the lifecycle works.
• Public development started in May 2026 and has more than 100 contributors. Nous Research is building Hermes Enterprise on it, kagent already runs on it, and SPIRITT runs customer agent workspaces on the GKE version.

The Gateway design is the part I would look at first. Keeping secrets out of the sandbox and attaching them at the network edge based on identity is the pattern you want when the code inside the sandbox was written by a model five seconds ago.

gVisor: a kernel in between

gVisor is the oldest of the three. Google open-sourced it in 2018, and it already runs millions of sandboxes a day behind GKE Sandbox and Cloud Run.

Normally, when a process in a container calls open() or read(), that system call goes straight to the host kernel. gVisor puts an application kernel, written in Go, between the container and the host. It answers the container's system calls itself, in userspace, and only makes a small, filtered set of calls to the real kernel. Untrusted code talks to gVisor, and gVisor talks to Linux.

Compared with a microVM, gVisor keeps the normal container process model, memory grows with what the workload uses, and it needs no nested virtualization, so it runs on any Linux node, including cloud VMs that don't expose virtualization extensions. It now supports GPUs, TPUs, and checkpoint/restore, which is what lets Agent Substrate pause a sandboxed agent and bring it back later.

The production user list is the strongest argument for it: Anthropic and OpenAI use it to contain code execution, Modal and Snowflake for execution sandboxes, Ant Group and Tencent in production at scale, and Northflank for GPU sandboxes. Ant Group, Modal, and Tines are joining as maintainers.

On Kubernetes you select gVisor per Pod through a RuntimeClass. If your nodes have the runsc runtime installed (GKE Sandbox node pools ship with it), it looks like this:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
metadata:
  name: agent-code-runner
  namespace: agents
spec:
  runtimeClassName: gvisor
  containers:
    - name: runner
      image: python:3.13-slim
      command: ["sleep", "infinity"]

To confirm the Pod is sandboxed, run kubectl exec -n agents agent-code-runner -- dmesg. Under gVisor you get gVisor's own boot messages, starting with Starting gVisor..., instead of the host kernel's log. If you see real hardware and driver lines, the RuntimeClass didn't apply and the Pod is running on the shared kernel.

The catch with gVisor has always been I/O-heavy workloads, since every syscall takes an extra hop. Sandbox providers, Google included, carry host kernel patches that bring gVisor's I/O close to native Linux. According to the announcement, upstream Linux maintainers declined to merge them while one vendor owned the project. Moving gVisor under CNCF governance gives those patches a path upstream, so everyone running gVisor gets the I/O improvement without carrying their own kernel patches.

OpenRL: fine-tuning on your own cluster

OpenRL handles the training side. Reinforcement learning post-training means taking an existing model, letting it attempt tasks (often inside agent sandboxes), scoring the results, and updating the weights so it does better next time.

OpenRL reduces that loop to four Python primitives: sample, forward_backward, optim_step, and save_state. They are exposed through an API compatible with Tinker, the fine-tuning API from Thinking Machines Lab, so recipes from its tinker-cookbook repository run unchanged. It supports LoRA adapters (small trainable weight matrices added to a frozen base model) and full-parameter fine-tuning, uses PyTorch for training and vLLM for sampling, and has Gemma and Qwen validated. TPU support is on the roadmap.

OpenRL builds on two Kubernetes-native pieces. Dynamic Resource Allocation (DRA) splits the accelerator pool between training and sampling. llm-d, the CNCF inference project, routes multiturn rollouts (an episode's back-and-forth with the model) to samplers that already hold the matching KV cache (the attention state computed for earlier turns, so it isn't recomputed), and lets sampling and training time-slice the same GPUs so they don't sit idle between phases. Episodes run inside Agent Substrate sandboxes, which is where the three projects connect.

How the three fit together

Picture a company building a coding assistant for its customers:

1. Each customer session is an Actor in Agent Substrate. It sleeps between requests and wakes up on any free Worker.
2. Code the agent writes runs inside a gVisor sandbox, so a malicious package can't reach the node's kernel.
3. Every night, OpenRL replays sessions as RL episodes in those same sandboxes and fine-tunes the model on what worked.

All of it runs on standard Kubernetes, on any cloud, on CPUs, GPUs, or TPUs, which is the core of Google's pitch.

Why give it away?

The Kubernetes comparison is Google's own. The post says it expects these projects to drive agent adoption "similarly to what we saw with Kubernetes."

If agent infrastructure stays proprietary, every cloud builds its own version and customers pick a lock-in. If it lives in a neutral foundation, hardware vendors, other clouds, and startups contribute to one project, the API becomes a standard, and Google competes on running it better. Kubernetes worked out that way: AWS, Azure, and everyone else ship it, and GKE is still a major product line for Google. Agent Substrate on GKE being GA on the same day as the donation follows the same pattern.

There is also the practical point from the gVisor section. Some things, like getting patches into the Linux kernel, are hard when a single company owns the project.

What to keep in mind

Sandbox is the first rung. The CNCF has three maturity levels: Sandbox, Incubating, and Graduated. Sandbox means the CNCF accepted the project for early-stage experimentation; it makes no claim about production readiness. gVisor is aiming for Incubation; Agent Substrate and OpenRL are new.

The upstream and the managed product are different things. Agent Substrate is GA on GKE. The open source project has been public for about six months. Running it yourself on EKS or bare metal is possible on paper, but expect rough edges.

The performance claims are Google's. The 10x density, more than 500 suspend and resume operations per second, and sub-500 ms restore numbers come from the announcement, so treat them as a starting point for your own benchmarks. Your agents, your storage backend, and your snapshot sizes will set your actual numbers.

If you want to dig in, the CNCF Sandbox applications for gVisor, Agent Substrate, and OpenRL are public and show what each project committed to, and KubeCon + CloudNativeCon North America runs November 9 to 12 in Salt Lake City with sessions on all three. The cheapest experiment today is gVisor: add a RuntimeClass to a test cluster, move whatever runs model-generated code onto it, and measure the I/O cost on your own workload.