Google’s Agent Substrate project is best understood through one analogy, and Google’s own architecture docs make it precisely: treat agents as processes in an operating system, not services in a datacenter. Everything else about the project — the warm pools, the snapshots, the 30× oversubscription — follows from that single reframing.
If you have run AI agents in production over the past year, you have probably felt it already: Kubernetes is somehow off. Not because it is bad — Kubernetes is the most successful scheduling system of the cloud-native era. The problem is simpler: agents are not microservices.
The Mismatch, in One Lifecycle
An agent session’s life looks like this: a prompt arrives, it runs for 10 seconds, then it waits 20 minutes for the next event. Multiply by the developers on a team and you have thousands of nominally “active” sessions that are actually asleep. Kubernetes’ API server and scheduler were designed for long-running services with fixed replica counts. When agents arrive in the millions, suspend and resume constantly, the control plane stops being an arbitration layer and becomes the bottleneck.
At Cloud Next ‘26 in May 2026, Google took GKE Agent Sandbox to general availability and introduced the Agent Substrate project — two announcements that quietly conceded what Kubernetes veterans were reluctant to say out loud: the platform that owned the container era is not the right control plane for AI agents.
Agent as Process: The Dimension-by-Dimension Split
| Dimension | Traditional service (K8s strength) | AI agent (K8s weakness) |
|---|---|---|
| Lifecycle | Long-running, always on | Bursty, mostly idle |
| State | Stateless / external storage | Heavily stateful, session context |
| Scheduling granularity | Minute-scale pod scheduling | Millisecond-scale event wakeups |
| Isolation requirement | Container boundary | Kernel boundary (untrusted code) |
| Scale | Thousands of pods | Millions of sessions |
These differences explain why agent infrastructure today mostly runs on top of Kubernetes rather than inside it as a native workload type the way Deployments and StatefulSets do.
Google’s Three-Layer Answer
Layer 1: Agent Sandbox — safe isolation
Agent Sandbox is an open-source execution environment built on Kubernetes that gives every agent a hardened space to run. Its baseline assumes any agent may run something it should not:
-
Kernel isolation by default via gVisor, with default-deny network policy — factory settings, not a security add-on.
-
Warm pools: each cluster can allocate 300 sandboxes per second, 90% of them within 200 milliseconds — the cold-start problem solved with preheated capacity.
-
Pod snapshots: idle agents suspend to snapshots and recover in seconds, releasing the compute underneath.
Customers including LangChain and Lovable already run millions of agents on it.
Layer 2: Agent Substrate — hyperscale scheduling
Isolation solved, the harder problem remains: scheduling millions of idle sessions. Substrate’s core move is applying virtual memory’s overcommit mechanism to compute scheduling. An OS lets programs address far more memory than physically exists by paging cold pages to disk; Substrate overlays a registry of many stateful agents onto a small pool of warm worker pods, persisting snapshots of idle sessions. The reported numbers: 30× or better oversubscription with sub-second activation.
Substrate does not replace Kubernetes. It uses pods and autoscaling for provisioning, then layers its own scheduler on top for the agent-specific decisions K8s was never built to make.
Layer 3: Kubernetes — resource management underneath
Kubernetes keeps managing the nodes. The architectural decision is about which layer owns which job. In practice, teams running coding agents at scale sandbox the code, schedule through Substrate, and let Kubernetes provision the nodes under both.
Will the Agent Control Plane Converge?
When Kubernetes went open source in 2014, container orchestration was a crowded field — Mesos, Swarm, Nomad — and K8s won outright. Substrate now stands somewhere similar, with real differences on both sides of the ledger.
The bull case: Google’s pedigree — Tim Hockin, a core Kubernetes contributor, is directly involved in Substrate’s design; the project launched open source on GitHub, inviting community co-design exactly the way K8s did; it is framework-agnostic, running ADK, LangChain, Claude Code, or any OCI container without binding to Google’s ecosystem; and Solo.io’s kagent has already adopted it as an optional runtime with a unified UI.
The bear case: the competitive field is more crowded — AWS, Azure, and Cloudflare all ship their own agent sandbox designs, and ecosystem fragmentation may simply migrate up a layer. Agent infrastructure is still evolving fast (Kimi K3’s subscriptions melting its servers within 48 hours shows demand outrunning supply, hardly an environment where standards solidify). And the open-source community’s trust in AI-generated code remains unsettled — recent restrictions on AI-generated contributions in GCC and the Linux kernel are a reminder.
The likeliest path: Substrate probably does not become a sole monarch the way K8s did. More plausibly it catalyzes a standardized interface layer for the “agent control plane” — defining abstractions like Session and Snapshot the way Kubernetes defined Pod and Service — while clouds compete on implementation quality underneath.
What This Means for Builders
-
Adopt the process model. Stop deploying agents as microservices. Session state management, idle resource reclamation, and sub-second wakeups are now core architectural metrics, not nice-to-haves.
-
Follow the project. Agent Substrate is open on GitHub (github.com/agent-substrate/substrate) — its API design and community discussions are the early signals worth watching.
-
Keep Kubernetes, reposition it. It remains an excellent low-level resource manager; the agent scheduling layer grows above it. Platform teams should be drafting their agent infrastructure layering strategy now.
-
Watch density economics. Idle-session waste is becoming a line item platform teams cannot ignore. The 30× oversubscription number points at the winning formula: whoever packs sessions denser without sacrificing latency wins.
Agent-era infrastructure is undergoing a paradigm shift from containers to processes. Kubernetes owned the container decade — but the vote for the next decade’s control plane has only just opened.
References: The New Stack | Google Cloud Blog
