Solo.io Adds Idle-Agent Suspension to Kubernetes With Agent Substrate
Why idle agents are a cluster problem
Here's the uncomfortable part of running AI agents on Kubernetes: a long-running agent sitting idle still holds a pod. Multiply that by a few hundred agents and a cluster can run out of room without anyone doing anything wrong. Solo.io's latest release goes straight at that problem.
At KubeCon + CloudNativeCon North America 2026, the company said it is making enterprise editions of Agent Substrate available. Agent Substrate is a framework for running long-running agent workloads at scale on Kubernetes more efficiently. Solo.io also announced that kagent, its tool for building and managing AI agents, is generally available. Conference timing is rarely accidental, and vendors tend to save their most useful news for the stage where the audience is already gathered. The more interesting detail is the word "enterprise," which usually means the open pieces are the starting point and the supported, governed version is what companies actually pay to run.
Suspending agents instead of paying for them
Agent Substrate, jointly developed by Google and Solo.io, separates stateful agent sessions and identities from the compute that runs them. An idle agent gets snapshotted, the snapshot is stored, and the agent is restored in under 500 milliseconds when it's needed again. The pitch is cost: infrastructure gets consumed only while agents are doing real work. That sounds simple, and in principle it is. The difficulty is that an agent isn't a stateless web request. It carries memory, context and connections that have to survive being pulled out of memory and put back, and that's where most suspend-and-resume ideas get messy.
Keith Babo, chief product officer at Solo.io, said IT teams are under significant pressure to find ways to deploy AI agents safely at scale. That's the gap this is aimed at. The framework's central piece is a runtime called the actor. It provides a sandbox that isolates execution and a gateway that governs how the actor is reached and what it can access. State, identity and access controls stay with the actor, so isolation and governance travel with every session instead of getting bolted on afterward. I'd argue that last point matters more than the cost story. Security teams have spent years being asked to retrofit controls onto systems that were built without them, and a design that starts with governance is a different conversation.
Where it fits in the Kubernetes roadmap
Agent Substrate has been donated to the Cloud Native Computing Foundation, which should mean it appears in Kubernetes distributions in 2027. That's a long wait for teams that need agents running now, so Solo.io is offering its own supported edition in the meantime. Donation to a foundation is a real signal, since it moves governance out of a single company's hands. Getting into the default distributions that most enterprises actually install is a separate and slower process, and it's the reason the interim edition exists at all.
My read is that most enterprises would rather run agents on infrastructure they already operate than stand up yet another platform for one class of workload. Solo.io is betting heavily on that instinct. If it holds, the pressure shifts from picking new tooling to making existing clusters behave well under a new kind of load. (And this is the part most people overlook: a cluster that's already tuned for web services and batch jobs may not be tuned for agents at all.) That's a harder problem than buying a product, because it touches scheduling, capacity planning and the people who own those decisions.
Solo.io's other pieces cover the rest of the stack. kagent handles building and deploying agents that can invoke Agent Substrate. agentgateway enforces identity and policy controls on ingress and egress traffic. agentshield looks for attack paths that could reach the environment. Together they span orchestration, isolation, identity and security, which is what enterprise security teams will ask for first. The bundle also tells you something about the vendor's strategy. Solo.io isn't selling a single runtime. It's selling a set of components that become harder to replace the more of them you adopt.
The unpredictability problem
Agent workloads don't follow the demand patterns Kubernetes schedulers were built around. A wave of agents can wake up at once and consume every available pod on a cluster, often with little warning. Suspend-and-restore helps with idle sessions, but it doesn't solve bursty demand by itself. Schedulers have long handled traffic spikes for web services, but those spikes tend to be smoother and easier to forecast than a fleet of agents reacting to the same triggered event.
Other gaps remain. The Kubernetes control plane will need rework to handle the API calls that enterprise IT teams will generate once they deploy agents in the thousands. That's the part to watch. Whether agents run efficiently on shared clusters will depend less on any single framework than on how quickly the control plane catches up. Frameworks can make individual sessions cheaper, but they can't make the API server faster on their own.
What this means if you're running clusters
If you're working in this space, the practical question isn't whether suspend-and-restore is clever. It's whether your cluster can tell the difference between an agent that's thinking and one that's stuck. Start by measuring how much of your capacity sits idle with long-running workloads attached, because that number is usually the first thing that justifies a change.
Not a small question. The answer will shape how much of your platform budget goes to agent infrastructure versus everything else. And the governance story deserves the same scrutiny as the cost story, since a sandbox is only as good as the policies around it.
This is more significant than it looks, but it isn't finished. Solo.io has identified the right bottleneck, and the design choices around state and identity are sound on paper. What's still unproven is how these pieces behave at real scale, under real bursts, on clusters that were never designed for this kind of traffic. That's where the next year of evidence will come from, and it's where skeptical buyers should be looking.
