kagent 1.0: why AI agents may no longer need an always-on Kubernetes Pod

What actually became generally available

On November 10, 2026, Solo.io announced kagent 1.0 and generally available enterprise releases of Agent Substrate for AI agents running on Kubernetes, including OpenShift. Rather than selling another chat interface, the company describes an execution architecture covering sandboxing, identity, resource scheduling, conversation state, policy enforcement and tool connectivity.

kagent and Agent Substrate are open source projects in the CNCF ecosystem, but a CNCF Sandbox designation is not a security certification or independent production approval. Vendor GA status should also be separated from universal availability of every enterprise feature in every environment.

Why a Kubernetes Pod for every agent can waste capacity

Conventional Kubernetes deployments keep replicated Pods available to handle requests. An interactive AI agent behaves differently: it often spends time waiting for model inference, tool output or a human decision, while keeping its workspace and conversation state. If every session permanently occupies a Pod, CPU, memory, scheduling capacity and networking resources can be reserved without productive work.

That does not make Pod-per-agent wrong for every workload. Small stateless bots and predictable jobs can still fit standard Kubernetes abstractions. The problem grows with many tenant-specific, stateful sessions and substantial idle time.

Agent Substrate separates actors from workers

Agent Substrate represents a session as an actor and schedules it onto a pool of warm worker Pods. When a session is idle, it can snapshot the workspace and optionally memory state, release the worker and resume the actor on an eligible worker when a new request arrives. The conversation state therefore need not be tied to permanently allocated compute.

This is an architectural improvement worth testing, not a mathematical guarantee of lower total cost. Snapshot storage, restore time, idle/active ratios, platform overhead and application behavior determine the actual result. Some low-volume deployments may become more complicated rather than cheaper.

Sandbox isolation and persistent workload identity

Solo.io says each actor operates inside a gVisor or microVM sandbox and receives its own SPIFFE-based identity. Inbound requests go through authentication and authorization; outbound requests pass agentgateway and EgressPolicy rules. The design keeps actual API secrets in a credential service and injects them through the gateway rather than leaving them in the agent workspace.

Those controls can reduce exposure to prompt injection and credential theft, but their effectiveness depends on policy design and enforcement. An over-permissive EgressPolicy or compromised administrator can still authorize dangerous actions, and a sandboxed agent can make incorrect business decisions within its granted scope.

What kagent adds to the runtime

Agent Substrate manages actors, workers, snapshots, identities and egress. kagent adds the application model: users, ownership, shared conversations, reusable agent definitions, model and prompt revisions, approval points and observability. It exposes defined interfaces using A2A and MCP and can integrate different model providers and agent harnesses.

Human-in-the-loop support matters particularly in stateful workflows: an agent can pause for approval, free resources and later resume the same operation. Revision-aware rollouts also aim to prevent active conversations from silently changing behavior halfway through a task. These are more consequential operational features than a long list of framework integrations.

Open source, enterprise GA and upgrade caveats

The open projects and Solo.io enterprise releases are not the same product package. Solo describes enterprise functionality for detailed permissions, tracing and evaluation from execution traces, capacity monitoring, air-gapped installation and paid support. Running the open-source stack still requires Kubernetes, Helm, persistent storage and a model provider with its own usage costs.

The company explicitly cautions kagent 0.x users that version 1.0 introduces a new API and runtime. A fresh deployment is recommended, so an upgrade deserves data-export, regression, credential and rollback planning. GA does not mean an automatic non-disruptive update.

An honest cost model for suspending agents

The potential saving comes from separating registered sessions from simultaneously active compute. To test it, measure the 24-hour active-to-idle ratio, worker CPU and memory utilization, checkpoint sizes, storage spending, wake-up latency, failed restores and model/tool costs. Compare identical tasks with identical models and policy constraints.

A headline number of 10,000 supported sessions is not the same as 10,000 simultaneous tasks, and a vendor sizing calculator cannot replace production telemetry. In some workloads, savings may be offset by operational complexity and snapshot I/O. Without independent workload measurements, a fixed cost-reduction percentage would be invented.

AgentenCode decision: which teams should pilot kagent?

A single internal research assistant rarely justifies an entire dedicated agent platform. Large interactive fleets with separate user workspaces, significant idle periods, multiple tenants and strict tool policies have a clearer reason to evaluate actor/worker execution. In regulated environments, the test plan should cover audit evidence, approval checkpoints, secrets rotation and recovery failure modes.

We recommend starting with a bounded read-only pilot of roughly 50–100 concurrent sessions, varying the idle ratio and deliberately denying several tool calls. Only after validating the logs and permission boundaries should teams consider write-capable workflows. Solo names OutSystems and Swissquote as production customers, but those are vendor and partner reports—not independent proof that the same performance is guaranteed everywhere.

Solo.io names OutSystems and Swissquote as customers. The former illustrates multi-tenant agent workloads; the latter describes financial-crime investigation agents running within a controlled stack. Both are plausible production examples, but neither supplies independent, reproducible benchmark results. Before procurement, operators should establish what telemetry can be exported, how snapshots are encrypted, and who owns recovery when a suspended session cannot be restored.