AI Agents Are Moving onto Kubernetes: What kagent and OpenChoreo Tell Us About the Next Platform Stack
A pair of open source projects highlighted by the Cloud Native Sydney community this August captures an important shift in Kubernetes. kagent is a Kubernetes native framework for building, deploying, and managing AI agents. OpenChoreo is an open source developer platform for Kubernetes that gives developers and AI agents higher level ways to build, deploy, and operate applications and agentic workloads.
The interesting part is not simply that AI can run in a Kubernetes cluster. Teams have already been placing inference services, model servers, vector databases, and GPU workloads on Kubernetes. The newer question is what happens when agents become both workloads and active users of the platform.
That makes the existing operational foundations more important. Before adding an agent layer, teams still need to understand the cluster model, workload boundaries, storage, networking, security, and recovery covered in the Mr.PlanB Kubernetes hub. Agentic tooling adds another control surface to that stack.
Kubernetes gives agents an operating environment
kagent describes itself as a Kubernetes native framework for AI agents. The appeal is straightforward. Kubernetes already provides a declarative control model, APIs, namespaces, service discovery, scheduling, secrets, policies, and a large automation ecosystem. An agent built for this environment can be deployed and managed using many of the same mechanisms that platform teams already use for applications.
This creates a potentially useful pattern for operations. An agent can be packaged as a managed workload, given explicitly scoped permissions, connected to approved tools, and observed like other services. Instead of giving an external automation system unrestricted access to a cluster, teams can place the automation inside a controlled Kubernetes context.
That does not make the agent safe by default. It makes its boundaries more visible. RBAC, service accounts, network policies, admission controls, secrets, and audit data become part of the agent design. Platform engineers need to know what an agent can read, what it can change, which tools it can call, and what happens when a model produces a bad recommendation.
OpenChoreo points toward a higher platform layer
OpenChoreo approaches the problem from another direction. Its project describes a developer platform for Kubernetes with abstractions, a developer portal, CI/CD, GitOps, and observability. The goal is to reduce the amount of raw Kubernetes complexity exposed to application developers while preserving governance for platform teams.
That idea becomes more interesting when AI agents are added. Humans are not the only consumers of a platform API anymore. An agent may need to deploy a component, inspect an environment, request a resource, or respond to an operational event. Higher level abstractions can constrain those actions more effectively than giving every automation process direct access to low level cluster objects.
The result looks less like an AI feature attached to Kubernetes and more like a new platform client. Developers, pipelines, operators, and agents may all interact with the same underlying infrastructure through different interfaces and permission boundaries.
Platform engineering becomes an AI infrastructure problem
This is where AI infrastructure and platform engineering start to overlap. Running models efficiently is only one part of the problem. Teams also need repeatable deployment, secrets management, storage, networking, observability, policy, identity, scaling, and recovery.
The AI and GPU workloads on Kubernetes guide covers the infrastructure side of accelerator discovery, scheduling, node pools, drivers, storage throughput, networking, model data, resilience, and cost. Agent frameworks sit above many of those concerns. If an agent invokes an inference service, the underlying model still needs reliable GPU capacity and data access. If an agent performs operational work, the cluster still needs controls that prevent one automation failure from becoming a platform outage.
This matters because AI agents can increase the rate of change. A human administrator may make a handful of deliberate changes during a maintenance window. An automated agent can inspect, decide, and act much faster. Faster action is useful only when permissions, validation, rollback, and auditability are equally mature.
Managed versus self managed Kubernetes still matters
The rise of agentic tooling does not remove the old infrastructure choices. It makes them more consequential. Teams still need to decide how much of the Kubernetes control plane and supporting infrastructure they want to own.
The managed Kubernetes versus bare metal comparison frames that decision around control, hardware access, performance, cost, staffing, upgrades, security, and operational burden. AI workloads can push teams in both directions. Managed services reduce some platform maintenance, while bare metal can provide tighter control over accelerators, high speed networking, storage, and data locality.
Agent frameworks can operate in either model, but the failure responsibilities differ. In a managed service, the cloud provider may own parts of the control plane while the customer still owns workloads, identities, policies, and data. On bare metal, the platform team owns much more of the stack and must plan upgrades, availability, networking, storage, and recovery directly.
Agents should begin with narrow authority
The most practical adoption path is likely to be incremental. Infrastructure teams do not need to begin by allowing an AI agent to remediate production automatically. Read only analysis, troubleshooting assistance, runbook guidance, inventory queries, and controlled nonproduction actions can provide useful experience while keeping the blast radius small.
As confidence grows, teams can introduce approval gates and narrowly defined write operations. The objective should be to make agent actions observable and reversible. A platform should be able to answer which agent acted, which identity it used, which resources changed, what evidence informed the action, and how the change can be rolled back.
This is familiar DevOps thinking applied to a new actor. Infrastructure as code made changes more repeatable. GitOps made desired state and review workflows more explicit. Agentic operations now raise the question of how much decision making can be automated without losing control.
The next Kubernetes platform may have two kinds of users
kagent and OpenChoreo are early signals of a broader direction. Kubernetes platforms were originally built for operators and application workloads. Platform engineering then created better interfaces for developers. AI agents now introduce another class of user that can consume those same abstractions programmatically and at high speed.
That does not mean every Kubernetes environment needs an agent framework. It does mean platform teams should start thinking about agents as infrastructure participants with identities, permissions, dependencies, costs, and failure modes.
The teams that benefit most will probably be those that keep the foundation boring: clear cluster ownership, reliable storage, observable workloads, controlled credentials, tested recovery, and well defined automation boundaries. On top of that, AI agents can become another tool for operating complex systems rather than another source of uncontrolled complexity.
Originally published on the Mr.PlanB blog.