AI agents vs. Kubernetes: where each belongs in the control loop
The New Stack Vikram Seshadri ● Covered by 2 sources
Kubernetes and AI agents are not the same thing, even if they both act in loops. The clean split is reasoning first, execution only after approval.
Based on reporting by The New Stack, Vikram Seshadri — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
Kubernetes has always run on agents of its own, just not the AI kind now getting all the attention. The familiar controller loop compares actual state with declared state and then tries to close the gap. That similarity makes AI agents and Kubernetes operators sound like cousins. They aren’t, and the difference matters more now that agent tooling has started moving into the cloud-native stack.
Over the past 18 months, CNCF has accepted agent frameworks into its Sandbox, and Kubernetes SIG Apps has taken on Agent Sandbox as a subproject for running agent workloads safely. Meanwhile, platform teams are already deciding what an agent can touch in a live cluster, often one pull request at a time and without a written policy. In practice, the boundary between reasoning and execution is often set by habit rather than design.
The safer model is split-brained on purpose. An AI agent is good when the destination is clear but the route isn’t: it can gather context, compare tradeoffs, and suggest a path forward. Operators, policy engines, and other deterministic systems should still handle the actual change. The article points to kagent, a CNCF Sandbox project, as an example: it can inspect resources, fetch logs and events, query metrics, read documentation, and coordinate other agents, but sensitive changes such as applying, patching, or deleting resources can require approval first. That creates a loop of observe, diagnose, propose, approve, reconcile, and verify.
The Karpenter example makes the point cleanly. Karpenter already reconciles NodePools and NodeClaims, so swapping that logic for an LLM would only make the control loop less predictable. A kagent-style operations agent can work above it, reading configuration, pending pods, events, Pod Disruption Budgets, logs, and Prometheus metrics to explain why the cluster is behaving the way it is. It might find a disruption budget blocking consolidation, a do-not-disrupt annotation pinning a node, or instance constraints that leave too little room for Spot capacity.
The same split applies to Argo CD. An agent can compare release notes, values, and rendered manifests, then turn that into a focused pull request that explains the risk and the checks needed before rollout. But Argo CD should still do the reconciliation once the change is approved. The message is blunt: let agents think, let Kubernetes execute, and make autonomy something the team earns step by step, not something it assumes because kubectl is within reach.
My take — AI-written commentary, not fact-checked reporting
The industry keeps confusing “can reason” with “can be trusted to act,” which is how people end up handing a live cluster to a glorified intern with a shell. The saner move is boring and correct: agents draft, operators enforce, policy says no when needed. Autonomy in infrastructure should be earned in tiny, audited steps, not declared in a blog post and prayed over.
Read more about this at: The New Stack