Kubernetes Is Being Re-Engineered for AI Agents That Sit Idle Most of the Time

Kubernetes wasn't built for AI agents, and the gap is getting harder to ignore. Making it fit the agentic era will take real re-engineering, not just tuning. That was the consensus at KubeCon + CloudNativeCon North America 2026 this week, where speakers kept returning to three problems: how efficiently agents consume infrastructure, how the control plane holds up under their load, and how to secure agents that run on the same servers as the clusters.

The idle-pod problem

Here's the core mismatch. Agents spend a lot of time waiting. They pause for a model response, an external service, or a human to approve something. Today, each active agent gets its own pod, and that pod keeps its memory and CPU reserved through every pause. Multiply that across fleets of agents and you get a lot of paid-for capacity doing nothing.

The control plane takes a hit too. Kubernetes ends up tracking millions of persistent objects, a scale its designers never planned for. Mickey Boxell, senior principal product manager for cloud native services at Oracle, pointed to the API side of the problem. Agents make calls to the Kubernetes API at a rate that climbs fast as deployments grow, and the control plane's performance starts to matter a lot more than it did when workloads were mostly stateless web services.

Google's answer: park the state, free the worker

Google's Agent Substrate, now contributed to the Cloud Native Computing Foundation as an open source framework, goes after the idle-pod problem directly. It separates an agent's stateful session and identity from the compute it's running on. When an agent goes quiet, the framework snapshots its state and saves it to storage, then returns the worker to a shared pool. When the agent needs to pick up again, the state gets restored on whichever worker is free. Google says a session can be restored in under 500 milliseconds.

That's the part I'd watch. If restore times hold up under production load, the economics shift. You stop paying for a pod to sit around waiting on a model response, and you can run far more agents on the same hardware. The catch is that this is a framework, not a finished feature in mainstream distributions. Speakers suggested it could be about a year before efforts like this show up in the Kubernetes distributions IT teams actually deploy.

Securing agents on shared infrastructure

Efficiency is only half the problem. Agents execute code and make decisions, which means they need isolation and guardrails, and the two projects in play tackle different layers.

Google has also contributed gVisor to the CNCF. It isolates untrusted code inside a lightweight userspace application kernel that can itself run as a container, which keeps that code away from the host's kernel. Alex Zenla, CTO of Edera, a company that makes a hypervisor optimized for running containers securely, argued that this kind of isolation is where the industry has to go. He also made a broader point: Kubernetes has absorbed hard architectural shifts before, most notably when stateful applications had to run on a platform designed for stateless workloads. The community adapted then, and he sees no reason it can't do it again.

NVIDIA took a different angle. It has contributed OpenShell, an open source runtime for deploying AI agents securely, to the CNCF as well. Where gVisor limits what untrusted code can touch, OpenShell focuses on policy: defining what an agent is allowed to access and do. Put simply, gVisor is about containment and OpenShell is about governance. Both are needed, and they don't overlap much.

What this means for platform teams

Nobody has a timeline for when all of this lands in the clusters that run in enterprise data centers. What's clear is that the pressure is building. Some IT teams are already looking at alternatives to a standard Kubernetes setup for agent workloads, which is a signal the current defaults aren't holding.

My read: the Kubernetes that ends up running agentic workloads well will look noticeably different from what most teams operate today. Session-aware scheduling, lighter-weight state handling, and policy enforcement built into the runtime are moving from proposals to shipping code. For platform teams, the practical step now is to start tracking these projects and to measure how much of your current cluster capacity is sitting idle behind agents that are only waiting.