In May 2026, Google did two things at Cloud Next: it took GKE Agent Sandbox to general availability, and it pulled the curtain off a project called Agent Substrate. Together, the announcements admitted what Kubernetes veterans had long been reluctant to say in public — the platform that owned the container era is not built to be the control plane for AI agents.
This is not a missing feature. It is a fundamental architectural mismatch, and it comes down to three concrete problems.
Why Kubernetes and Agents Don’t Mix
The clearest way to see it: an agent behaves like a process in an operating system, not a service in a datacenter. A modern OS runs thousands of processes, most of them dormant. It wakes them on events, grants a sliver of CPU, pages their idle memory to disk to make room for the next one. Agents behave almost exactly the same way — while Kubernetes was designed to manage a fixed set of long-running replicas. That mismatch explains why agent infrastructure today runs on top of Kubernetes rather than inside it as a first-class workload.
-
The workload is fundamentally different. Agents are long-lived, stateful sessions that spend most of their life idle, wake to run a burst of code, and sleep again. That code is generated by an LLM at runtime, so the host must treat it as untrusted by default.
-
The consumption pattern is different. A coding agent sits open all afternoon, runs for 10 seconds when a prompt arrives, then waits 20 minutes for the next one. Multiply by the team and you get thousands of nominally active sessions that are actually asleep.
-
The scheduling granularity is different. Agents generate a continuous stream of fine-grained scheduling events, breaking the assumption behind a scheduler built for a moderate number of long-lived pods.
What Each Project Actually Solves
The two Google projects are not competitors — they are layers with separate jobs.
Agent Sandbox: the security cell
Agent Sandbox answers the isolation question. It is an open-source execution environment built on Kubernetes that gives each agent a hardened space to run LLM-generated code — think jail, not ordinary container. Regular containers share the host kernel and trust the workload to behave; the Sandbox assumes the workload is hostile and draws the boundary accordingly.
-
Kernel isolation by default through gVisor, with pluggable interfaces to swap in Kata Containers for full kernel isolation.
-
Warm pools beat cold starts: each cluster allocates 300 sandboxes per second, 90% within 200 milliseconds.
-
Pod snapshots suspend idle sessions, releasing compute so you stop paying for sleeping agents.
-
Default-deny network policy ships as the baseline, on the assumption any agent might run something it shouldn’t.
Adoption grew roughly 16× in under five months, which is why Google pushed it to full availability. LangChain and Lovable run millions of agents on it.
Agent Substrate: a runtime for millions of idle agents
If the Sandbox is the jail, Agent Substrate is the scheduler deciding which agent runs where. It reuses the Sandbox’s hardened runtime and snapshot machinery, then pairs them with a small control plane that sits beside the Kubernetes cluster — taking the standard control plane off the critical path.
The design borrows directly from virtual memory’s overcommit playbook: agents are processes, warm pools correspond to a set of CPU cores, and idle-session snapshots are pages swapped to disk. Substrate overlays a registry of many stateful agents onto a small pool of warm worker pods. Because worker pods are already running when events arrive — never waiting on the Kubernetes scheduler — the project reports 30× or higher oversubscription with sub-second activation.
It is also framework-agnostic: ADK, LangChain, Claude Code, or any OCI container can be the executor.
The Agent Runtime as a Fourth Computing Paradigm
Zoom out and session-aware, isolated agent runtimes are shaping up as the fourth computing paradigm after virtual machines, containers, and serverless:
| Paradigm | Core abstraction | Scheduling granularity | Isolation | Typical examples |
|---|---|---|---|---|
| Virtual machines | Full OS | Minutes | Hardware-level | VMware, EC2 |
| Containers | Process groups | Seconds | Kernel-level (cgroups) | Docker, Kubernetes |
| Serverless | Functions | Milliseconds | Runtime-level | Lambda, Cloud Functions |
| Agent runtimes | Stateful sessions | Sub-second + dormancy | Kernel-level (gVisor/Firecracker) | Agent Substrate, E2B |
What makes the agent runtime unique is that it must handle two extremes at once — long dormancy and sudden bursts — a combination none of the previous three paradigms ever had to face.
What the Shift Means
Kubernetes stays infrastructure, loses the control plane
Kubernetes keeps handling pods and autoscaling underneath, but the logic that governs agent scheduling is being lifted upward. This is not replacement — it is layering. Kubernetes does what it is good at (nodes); Agent Substrate does what it is good at (agent lifecycles).
Agent infrastructure is consolidating fast
AWS, Google Cloud, Azure, and Cloudflare all ship agent sandbox designs now, and they diverge in implementation: Cloudflare uses container isolation plus V8 isolates, E2B uses Firecracker microVMs, Google uses gVisor. The field faces the same convergence question the orchestration wars did — will one open-source agent runtime dominate the way Kubernetes did?
For developers: from deploying services to managing sessions
Once agents become mainstream compute, the questions change from “how do I deploy a service” to “how do I manage the sleep and wake cycles of a million stateful sessions” — which demands new monitoring, logging, debugging, and cost tooling. Solo.io has already integrated Substrate into kagent with a unified management UI.
What You Can Do
-
Platform teams: follow Agent Substrate’s open-source progress and model the cost of an agent runtime. Beyond a certain deployment scale, Kubernetes-native scheduling stops being enough.
-
AI application developers: internalize the mental model — agents are processes, not services. Don’t force agent behavior into Kubernetes primitives; use an existing Agent Sandbox offering.
-
Architects: watch where agent runtimes converge. It is early, but once a standard forms, the whole AI application infrastructure stack reshuffles.
Google’s Agent Substrate is an early exploration, not a finished product. But its design already points the way: an agent is not a service — it is a process. When the infrastructure layer fully absorbs that idea, agents can finally scale like they mean it.
Kubernetes owned the container decade. The next one belongs to agents — and agents need their own runtime.
References: The New Stack / Google Cloud Blog / InfoQ
