Kubernetes owned the container era. Google is betting the agent era needs something else: in May 2026 it declared GKE Agent Sandbox generally available and revealed Agent Substrate, a project built on a conclusion the Kubernetes old guard had long avoided stating in public — the platform that won containers is architecturally wrong as the control plane for AI agents.
Not a feature gap. A fundamental mismatch.
Where Kubernetes’ Container Thinking Breaks
Kubernetes was born in 2014 to manage a fixed set of long-running replicated services. A Deployment with three replicas, each running steadily, traffic load-balanced through a Service, HPA scaling on CPU utilization — that model fit microservices perfectly.
Agents are not microservices. Picture an agent as an operating system process instead. A modern OS runs thousands of processes that mostly sleep: it wakes them on events, hands them a sliver of CPU, pages their idle memory to disk to make room for the next one. Agents map onto that almost exactly:
-
A coding agent, open all afternoon, runs for 10 seconds when a prompt lands and waits 20 minutes for the next one.
-
Multiplied across a team, that becomes thousands of nominally “active” sessions that are actually asleep.
-
Every session needs a stable identity and the ability to pause and resume without losing memory.
-
The code it runs is generated by an LLM at runtime — the host must default to treating it as untrusted.
Kubernetes pins a full pod to every idle session, wasting the pod’s reserved memory and CPU. Worse, its centralized API server and scheduler assume scheduling decisions are infrequent and durable. Agents shatter that assumption with a continuous stream of fine-grained events, and the control plane itself becomes the bottleneck.
Three Essential Traits of Agents as Workloads
Trait one: sessions that sleep for hours. Web services burn CPU while requests flow; agent sessions consume almost nothing between prompts. Pinning a full pod per idle session is paying for something to do nothing. New-generation runtimes strip the idle session’s state off the compute — snapshotting volatile RAM and filesystem state while it sleeps, restoring it in seconds on wake. That is the OS virtual memory paging mechanism, applied to agents.
Trait two: code the platform cannot predefine. Because the LLM writes the code at runtime, the host cannot assume benign behavior. The isolation boundary therefore moves from the container edge to the kernel edge — ordinary containers share the host kernel and trust the workload; agent sandboxes must assume hostile intent.
Trait three: state that must survive dormancy. An agent that loses its context every time it suspends is useless. Working memory, filesystem, tool-call history — all of it must persist through sleep and return exactly on wake. That is beyond what Kubernetes natively designs for.
The Three-Layer Architecture
Google’s answer is not one platform replacing another but a purpose-built control plane layered over Kubernetes:
Layer 1 — Agent Sandbox, the security isolation layer. An open-source execution environment on Kubernetes giving each agent a hardened space for LLM-generated code. Where normal containers share the host kernel, the Sandbox defaults to kernel-level isolation via gVisor plus default-deny network policy. Design highlights: a warm pool of pre-configured replicas (Google reports 300 sandbox allocations per second per cluster, 90% within 200 milliseconds), and pod snapshots that suspend idle agents and release their compute instead of billing you for memory-bound sleep. Adoption grew about 16× in under five months; LangChain and Lovable run millions of agents on it.
Layer 2 — Agent Substrate, the scheduling and runtime layer. Where the Sandbox is the jail, Substrate is the dispatcher. It reuses the Sandbox’s hardened runtime and snapshots, pairing them with a small control plane beside the Kubernetes cluster that takes the standard control plane off the critical path. The core idea is virtual memory overcommit applied to compute: overlay a registry of many stateful agents onto a small pool of warm worker pods, persisting snapshots of the idle ones. Project data: because worker pods are already running when events arrive and never wait on the Kubernetes scheduler, it achieves 30× or higher oversubscription with sub-second activation. It is framework-agnostic — ADK, LangChain, Claude Code, or any OCI container — and exposes two custom resources to developers: WorkerPool (defines ready compute) and ActorTemplate (defines the agent).
Layer 3 — Kubernetes, the resource management layer. Substrate is not a K8s replacement; it still uses pods and autoscaling for provisioning and layers its scheduler above. Kubernetes manages machines; Substrate manages agents. As Google’s own blog puts it: standard Kubernetes is optimized for thousands of long-running services, while Agent Substrate is built for the noise of millions of sub-second tool calls that would drown a standard control plane.
The Birth of a Fourth Computing Paradigm
The hyperscalers are already positioning for this: session-aware, isolated agent runtimes are emerging as the fourth computing paradigm after virtual machines, containers, and serverless. The underlying logic runs three deep.
First, agents are processes, not services — the root cognitive shift. Services are “always on, waiting for requests”; processes are “wake on demand, sleep when idle.” Kubernetes was designed for services, not processes. Substrate’s own architecture docs say it plainly: there is no clever way to fit this many objects through a standard control plane.
Second, idle cost is becoming a real line item. As agent counts go from single digits to tens of thousands and millions, pinning pods to sleeping sessions becomes unacceptable. Virtual-memory-style overcommit compresses the cost of an idle agent toward zero.
Third, the ecosystem question: one control plane or many? Substrate is early and experimental. Solo.io has integrated it into kagent with a unified UI. But the open question is who owns the agent control plane layer. Optimistic scenario: the field converges on a single open-source project, the way orchestration converged on Kubernetes. Realistic scenario: every hyperscaler ships its own — and the fragmentation agents were supposed to escape simply reappears one layer up.
What Engineering Teams Should Ask Now
1. Is your agent architecture “process-thinking” or “service-thinking”? If you still deploy agents as Deployments-plus-Services with one long-lived pod each, idle cost balloons fast past a few hundred agents. Introduce session snapshots and on-demand restore early.
2. Is security isolation a factory default? Agent Sandbox’s philosophy is “assume the agent is hostile.” If your runtime treats isolation as an add-on for high-security deployments, invert that order.
3. Watch where the agent runtime ecosystem converges. Agent Substrate, AWS Bedrock AgentCore, Azure AI Foundry Agent Service, LangGraph Platform, Agyn — the 2026 agent runtime market is as crowded as container orchestration was in 2015. History says this layer consolidates. The question worth tracking: will Agent Substrate, with its open ecosystem and Google’s backing, become the Kubernetes of the agent era?
Kubernetes remains an excellent datacenter scheduler and is still irreplaceable for provisioning machines underneath. But for workloads shaped like vast swarms of sleeping processes, it is not the right scheduler. Agent Substrate was built precisely for them.
References: The New Stack: Kubernetes won the container decade. Google’s Agent Substrate wants the next one. | Google Cloud Blog: Agent Sandbox on GKE is now available
