Solo.io Lets Idle AI Agents Step Off Kubernetes Pods

Most AI agents spend far more time waiting than working, yet on Kubernetes each idle agent can still hold a pod. Solo.io's answer is Agent Substrate, which separates session state and identity from compute so an agent can be parked and brought back in under 500 milliseconds. Announced at KubeCon + CloudNativeCon North America 2026, it's the core of a broader push to make agents easier to run at scale.

The premise deserves a second look before the product does. Agents that sit waiting for a user, a tool response, or a downstream system are a different animal from the request-response services Kubernetes was built around. Those services hold resources because they're busy. An agent often holds resources because it's thinking about what to do next, which is a much less defensible reason. That's the gap Solo.io is trying to close, and it's a real one.

Parking agents instead of paying for them

Keith Babo, chief product officer at Solo.io, says IT teams are under real pressure to deploy agents at scale without losing control of them. Agent Substrate, developed jointly with Google, takes a snapshot of an idle agent, stores it, and restores it when work arrives. The compute goes back to the cluster in the meantime, and that's where the cost argument comes from.

The underlying idea isn't new. Operators have long suspended batch jobs and scaled down workloads that don't need to run constantly. What's different here is what has to survive the pause. An agent carries conversational context, pending tool calls, and credentials, so a restore has to bring back much more than memory. That's the hard part, and it's why the sub-500-millisecond figure deserves scrutiny. I'd want to know whether that number measures the snapshot restore alone or the full path back to a working session, including identity checks.

Here's the cost reality, though. Idle compute only becomes waste when something else could have used it. On a cluster with plenty of spare capacity, parking agents saves very little. On a shared platform running close to its limits, it can matter a lot. If you're running that kind of platform, test this scenario first and ignore the scenarios that look good in a demo.

Isolation and governance built into the runtime

At the center is what Solo.io calls an actor: a runtime that sandboxes execution and includes a gateway controlling how an agent is reached and what it can touch. State, identity, and access controls stay with the actor, so isolation and governance follow every session instead of being bolted on afterward.

Sandboxing isn't a novel idea, but it's a different problem when the logic being executed is steered by a model rather than written line by line by your team. An agent can decide to call a tool nobody anticipated, or pass along data it shouldn't. That's why the gateway sits in front of the agent rather than inside the application code. Putting the control point outside the agent means a misbehaving agent can't simply reason its way past it, at least in principle.

Two companion tools round out the stack. agentgateway enforces identity and policy on traffic entering and leaving the environment, and agentshield looks for attack paths that could reach the cluster. The pairing makes sense on paper. (And this is the part most people overlook) a policy engine is only as good as the rules someone writes and maintains, and the source doesn't say how those rules get authored, tested, or audited. That's where governance projects usually succeed or quietly fail.

A 2027 timeline and an interim edition

Agent Substrate has been donated to the Cloud Native Computing Foundation, which should bring it into Kubernetes distributions in 2027. That's a long wait for teams already running agent projects, so Solo.io is offering an enterprise edition it will support now.

The donation is a meaningful signal. Foundation backing usually means the project is meant to be a shared standard rather than a single vendor's add-on. It doesn't mean the software is ready for your production environment, and foundation projects tend to move at their own pace. Getting into distributions is a separate negotiation with separate timelines. Teams that plan around the 2027 date should treat it as a best estimate, not a commitment.

The enterprise edition is the stopgap. A long gap, especially for anyone already in production. If you're on the current version and need idle management today, you're effectively a design partner, and you'll want to know exactly what support covers before you build on it.

kagent, the tool for building and managing AI agents, is generally available. Solo.io says it can invoke Agent Substrate, so teams can build an agent and run it on the substrate from the same toolchain. kagent is probably the piece most teams will touch first, since it's the one that's already generally available. Toolchain consolidation sounds convenient, and it is, but it also means your agent code is tied more tightly to one vendor's stack than a general-purpose setup would be.

The scheduling problem is harder than it looks

Agent workloads don't behave like the services Kubernetes was designed around. Their activity is hard to predict, and a sudden wave of agents can lock up every available pod on a cluster before anyone sees it coming. Capacity planning built on historical traffic won't catch that.

Traditional web services tend to follow human rhythms, with predictable peaks tied to business hours and marketing campaigns. Agents respond to triggers that don't respect those patterns. A single event can fan out into dozens of agent sessions, each one reasoning, calling tools, and waiting in turn. Autoscalers tuned for gradual load will struggle with that shape, and the scheduler may not see the problem until pods are already exhausted.

The control plane is the bigger unknown. Clusters will have to absorb the API calls from large fleets of agents, and enterprises may deploy those fleets in the thousands. Substrate-level idle management helps with pod churn, but it doesn't settle how the control plane handles that volume. Parking an agent is cheap only if waking it doesn't overwhelm the API server on the way back.

What this means for your cluster

Here's the thing: agents are going to land on Kubernetes regardless. The real question is whether teams pack them efficiently onto the clusters they already run, or end up operating yet another platform beside the one they have. If I were running a cluster, I'd want to know how fast my idle agents can get out of the way.

That's the practical question, and it's more significant than it looks. Agent Substrate isn't just a cost tool. It's an attempt to make agents behave like well-behaved cluster citizens, releasing resources when idle and carrying identity and policy with them. If that model holds up under real load, it changes how platform teams think about agent capacity. If it doesn't, the idle-pod problem will just move somewhere else.

What this means for you depends on where you sit. If you're running agent pilots today, focus on the restore path and the control plane load, not the headline latency number. If you're responsible for a shared platform, plan for bursty fleets and ask hard questions about who writes the governance rules. And if you're waiting for 2027, you'll have time to watch whether the substrate earns its place before committing to it.