Agent Substrate, the open source runtime Google built for running large fleets of AI agents on Kubernetes, has passed its vote to join the CNCF Sandbox. The vote closed on September 28, 2026 with eight of eleven binding votes in favour and none against. It is not a CNCF project yet: the contribution agreement still has to be signed.
The short version
| Agent Substrate | |
|---|---|
| What | A high-density, low-latency runtime for AI agent workloads on Kubernetes |
| Contributed by | |
| Repository | agent-substrate/substrate, public since May 2026 |
| Licence | Apache 2.0 |
| Application | CNCF Sandbox issue #523, opened September 8, 2026 |
| Vote | Passed September 28, 2026: 8 in favour, 0 against, 3 not voted |
| Contributors | 90+ across Google, NVIDIA, Solo.io and Microsoft, per the application |
| Formal adopters | None listed yet |
What it does
Kubernetes starts and stops containers. An agent does something else: it works hard for a few seconds, then sits idle waiting on a model or a person. The application says these workloads are idle more than 90% of the time.
Agent Substrate is built around that shape. It maps many logical agents, which it calls actors, onto a much smaller pool of warm worker pods. An idle actor is suspended, with its memory and filesystem checkpointed, and resumed when it is needed. Sandboxing is pluggable: gVisor, or microVMs through Kata Containers and Cloud Hypervisor.
The application's own numbers are sub-second suspend and resume, and 30x to 100x density from multiplexing workers. Those are the project's claims and we have not benchmarked them.
Where it is in the CNCF process
From application to CNCF project. The vote is done; the paperwork is not.
- SEP 08ApplicationGoogle opens Sandbox issue #523 for Agent Substrate.
- SEP 22Vote calledThe CNCF TOC starts a binding vote. It needs 66% in favour.
- SEP 28Vote passed72.7% in favour: eight binding votes for, none against.
- PENDINGAgreementThe contribution agreement must be signed before onboarding starts.
- NOV 2026AnnouncementThe application plans a public transfer at KubeCon North America.
One detail is worth knowing. The automated pre-review flagged the project as too new, since the repository was under four months old against a six-month guideline. The TOC chair's reply was that this is a fast-moving area and the TOC would discuss it during review. The vote went ahead and passed.
Why the governance matters more than the code
The code was already open. What changes is who owns it. The application is direct about the reason: single-company stewardship deters other cloud providers and large vendors from adopting a project. Under the CNCF, the trademarks and accounts move to a neutral foundation.
For a team choosing where its agents run, that changes the risk. An agent runtime is a deep dependency: it holds the sandbox, the state and the network path. Building on one that a single vendor controls is a bet on that vendor. Building on a foundation project is a smaller bet, in the same way Kubernetes itself became safe to standardise on.
Sandbox is the CNCF's entry level, though. It signals that the foundation thinks the project is worth incubating. It is not a statement that it is production-ready, and the application lists no formal adopters.
What to do with this
If you run agents on Kubernetes today, nothing needs to change this quarter. Three things are worth doing:
- Watch the roadmap. It targets sub-100ms wake-up at p95 and over a million concurrent actors. Those are goals, not shipped features.
- Keep your runtime swappable. Agent packaging, state and tool access should not assume one runtime. That is what makes a later move cheap.
- Read how it fits with AX. Substrate is the compute layer; Google's AX orchestrator schedules agent tasks onto it. We covered that in AX by Google.
Where and how an agent runs is an engineering decision with security and cost attached to it. That is the work behind agent deployment and runtime.