Kubernetes won the container decade. Google’s Agent Substrate wants the next one.

Google just admitted, in the driest possible corporate language, that the infrastructure everyone spent a decade standardizing on isn't right for the thing everyone is now building. GKE Agent Sandbox went generally available, and tucked into the same announcement was a second, newer project called Agent Substrate. Read together, they're a confession: Kubernetes won the container decade, but it's the wrong control plane for an agent decade.

The reason is structural, not political. Kubernetes was built to manage a fixed set of long-running, replicated services — the kind that sit at steady load and rarely change shape. An agent doesn't behave like that at all. It behaves like a process on an old-school time-sharing operating system: mostly asleep, woken by an event, given a short burst of CPU, then put back to sleep. A developer's coding agent might run for ten seconds after a prompt and then idle for twenty minutes. Multiply that across a team and you get thousands of sessions that are technically alive and practically dormant, which is exactly the pattern Kubernetes' API server and scheduler were never tuned to handle efficiently.

Agent Sandbox solves the half of this problem that's about trust. Because the code an agent runs is generated by a model at runtime, the platform has to treat it as hostile by default — a jail, not a container. Google's version leans on gVisor for kernel-level isolation, adds default-deny networking, and lets teams swap in Kata Containers when they need harder guarantees. After roughly 16x growth in GKE sandbox usage in under five months, with customers like LangChain and Lovable running millions of agents through it, Google tuned the cold-start path hard: 300 sandbox allocations per second per cluster, 90 percent finishing inside 200 milliseconds, and idle sessions snapshotted out rather than left holding reserved compute.

Agent Substrate tackles the other half: where an agent actually runs. It borrows Sandbox's isolation and snapshotting, then sits its own lightweight control plane alongside Kubernetes rather than inside it, pulling scheduling off the API server entirely. The trick is basically virtual memory for compute — a small pool of pre-warmed worker Pods gets massively oversubscribed against a much larger registry of mostly-sleeping agent sessions, with idle ones paged out to storage. Google claims 30x-plus oversubscription with sub-second wake times, defined through two custom resources, WorkerPool and ActorTemplate, and it's framework-agnostic enough to run ADK, LangChain, or Claude Code as an actor. Solo.io has already plugged it into kagent, giving teams a UI to schedule agent harnesses onto Substrate without touching Kubernetes' own scheduler.

None of this replaces Kubernetes — it still provisions the machines underneath everything. What's changing is which layer makes the moment-to-moment decisions, and Google isn't the only one who'll want to own that layer. Agent Substrate is explicitly a first look, kagent is early, and every hyperscaler has the same idle-agent cost problem staring at their infrastructure bill. The real question isn't whether this new scheduling layer gets built — it's whether it consolidates into one open standard the way container orchestration did around Kubernetes, or whether every vendor ships its own and agents end up just as fragmented as the infrastructure they were supposed to simplify.