The Kubernetes ecosystem is seeing a new proposal for running AI agents, one that challenges the common practice of assigning a separate Pod to each agent. The open source project kagent argues that this model is inefficient, and it is introducing a control plane that schedules logical actors onto long lived worker Pods instead.
The proposal comes at a time when many organizations are moving AI workloads to Kubernetes and looking for ways to manage resources more effectively. According to the project’s developers, AI agents are often bursty, short lived, and may spawn subagents or wait for human approval, making a one to one mapping between agents and Pods wasteful.
Why One Pod per Agent Is Seen as Inefficient
In traditional Kubernetes deployments, each application instance typically runs in its own Pod, which provides isolation and scaling. But for AI agents, this approach can lead to underutilized resources, as agents may be idle while waiting for user input or external events.
The kagent project suggests that agents should not be treated as static workloads but as logical units that require dynamic scheduling. By separating the agent logic from the underlying infrastructure, the system can pack multiple agents onto fewer Pods, improving resource utilization and reducing operational costs.
The Agent Substrate Control Plane
The new design introduces a component called agent substrate, which acts as a control plane. It is responsible for scheduling logical actors, which are the execution units for agent tasks, onto a pool of worker Pods. These Pods are long lived and can host multiple actors over time.
This approach is similar to how job schedulers in high performance computing allocate tasks to nodes, rather than launching a new virtual machine or container for every job. The control plane can make decisions based on resource availability, agent priorities, and other runtime metrics.
The concept aims to address several operational challenges. For example, an agent that forks subagents can run those subtasks on different workers without needing to create new Pods. Similarly, when an agent pauses for human approval, its resources can be released and used by other agents, instead of remaining occupied.
Implications for Kubernetes and AI Operations
If adopted, this model could change how developers deploy and scale agent based applications on Kubernetes. Current best practices often involve using operators or custom controllers to manage agent lifecycles, but they typically create a Pod per agent instance.
The kagent approach offers a more abstract layer, allowing platform teams to manage a pool of workers and let the control plane assign work dynamically. This could lead to more predictable infrastructure costs and simpler autoscaling, as worker Pods can be provisioned based on overall demand rather than individual agent counts.
Early documentation from the project emphasizes that the control plane is designed to be extensible, supporting custom scheduling policies and integrations with existing Kubernetes primitives. This aligns with the broader trend of building domain specific control planes on top of Kubernetes, rather than forcing all workloads into the default replication controller model.
The proposal is still in its early stages, and the project has not announced a formal release date or a stable API. The team behind kagent plans to publish detailed design documents and prototype implementations in the coming months, and it welcomes community feedback from users who are running AI workloads in production.
Industry observers note that this is one of several attempts to optimize AI inference and agent execution on Kubernetes, alongside efforts to use serverless functions or custom resource types. The outcome of these experiments could influence how platform engineers design infrastructure for the next generation of AI driven applications.
