Kubernetes has long depended on agents—though not the machine-learning-powered variety now reshaping cloud-native discussions. Controllers observe the actual state of a cluster, measure it against the desired state, and execute changes to eliminate the difference. That structural parallel can make AI agents and Kubernetes operators appear functionally equivalent. In practice, they serve fundamentally different purposes.
The distinction has moved beyond academic debate. Agent tooling has transitioned from experimental work to a recognized component of the cloud-native ecosystem over the last 18 months. The CNCF has brought agent frameworks into its Sandbox program, and Kubernetes SIG Apps has launched Agent Sandbox as a dedicated subproject for safely executing agent workloads.
Many platform teams are currently making decisions about what agents can modify in production clusters, frequently handling one pull request at a time without formal governance. The line separating reasoning from execution typically follows convention rather than deliberate architectural choice.
Operators execute; agents think
Kubernetes operators are built for consistency. They apply encoded rules to reconcile resources, repeat operations when they fail, and drive the system toward the declared desired state. AI agents deliver value when the goal is known but the method is unclear. They can explore unfamiliar conditions, pull information from multiple sources, evaluate competing priorities, and suggest a path forward.
A more robust design merges these capabilities. Agents furnish reasoning and situational awareness. Deterministic systems—operators, policy engines, and similar tools—maintain authority over what actually changes.
A reasoning layer for Kubernetes
kagent, a CNCF Sandbox initiative available as open source, demonstrates this pattern in action. It deploys AI agents as Kubernetes resources and integrates them with Kubernetes itself, Helm, monitoring systems, and purpose-built tools. An agent can examine resource definitions, pull logs and events, access metric data, review documentation, and orchestrate other specialized agents.
Not all operations should be available without restriction. Read-only queries that pose minimal risk can execute without intervention, whereas modifications—applying, patching, or removing resources—should demand human sign-off. This distinction enables agents to perform thorough analysis while preventing an imperfect reasoning system from gaining unchecked power over cluster operations.
This separation lets the agent conduct a broad investigation without giving an uncertain reasoning process unrestricted authority over the cluster.
The resulting workflow proceeds through six stages: observe, diagnose, propose, approve, reconcile, and verify. Agentic reasoning handles the first three. Kubernetes and its operators manage reconciliation. Verification completes the cycle by confirming that an accepted change actually delivered the intended outcome.
Karpenter shows the difference
Picture a cluster where Karpenter successfully allocates resources, yet the platform team notices wasted node capacity, sluggish consolidation, Spot instance turnover, or queued pods. Karpenter functions as an operator itself. It assesses scheduling requirements and manages NodePools and NodeClaims. Swapping that deterministic logic for an LLM would undermine the reliability of an already-working control loop.
A kagent-based operations agent should sit above Karpenter. It can review NodePool and EC2NodeClass settings (in EKS environments), pending workloads, cluster events, Pod Disruption Budgets, Karpenter logs, and relevant Prometheus metrics. It can then investigate why actual behavior diverges from the team's objectives.
The analysis might reveal that a Pod Disruption Budget is preventing consolidation, a do-not-disrupt label is anchoring a node, or a disruption budget is blocking pod eviction. It might uncover that consolidateAfter settings are too strict for variable workloads, creating unnecessary churn. It could also spot instance type restrictions that leave Karpenter with insufficient options when sourcing Spot capacity.
Karpenter itself is already an operator. Replacing that logic with an LLM would make a reliable control loop less predictable.
The agent's recommendation should not be vague. Instead, it should lay out the facts, articulate the tradeoff, and deliver a precise configuration change. A NodePool disruption budget adjustment should quantify the maximum nodes at risk. A consolidation tweak should specify how long stability will be monitored. An expansion of instance types should respect architectural, zone, and workload constraints.
The proposed change then moves through an approval or policy check. After clearance, Karpenter applies its standard scheduling and disruption procedures. The agent monitors the outcome over a set window and confirms whether consolidation improved without raising pending-pod delays or harmful disruption. Should the results fall short, the system can recommend or execute a rollback via the same gated mechanism.
Argo CD applies the upgrade. The agent builds the case.
Suppose a platform team wants to bump a Helm chart version managed by Argo CD. Updating the chart version in Git is simple. Predicting how that change will ripple through a live application is harder. Argo CD can list which resources will change; an agent can help clarify what those changes mean for the workload.
A new chart version might alter a configuration key that the team relies on for readiness probe settings. The agent can cross-reference release notes, current values, and the rendered manifest to spot whether the upgrade would silently revert to a default behavior. It should turn that discovery into a targeted pull request that advances the chart version, corrects the affected values, documents the operational risk, and outlines the validation steps needed before deployment.
When the pull request gets approved and merged, Argo CD processes the chart and deploys the resulting manifests using the application's sync rules. The agent then reviews Argo CD's sync state and health alongside application performance. A successful sync does not guarantee that the upgrade maintained latency, error rates, or uptime.
If those metrics deteriorate, the agent can suggest a Git revert or a recovery strategy through the same approval workflow, accounting for any data or schema changes that a simple revert cannot address. Responsibility remains transparent: the agent investigates, proposes, and validates; Argo CD reconciles the approved desired state.
Autonomy should be earned
Organizations can roll out this approach incrementally. Begin with an agent that only reads. Progress to allowing patch or pull request generation. Then enable approved, low-impact changes with clear limits and rollback options. Reserve full autonomy for actions that are well-understood and produce measurable results.
The important boundary is not whether an agent can call kubectl, Helm, or a cloud API. It is whether every action is authorized, bounded, observable, and reversible.
Kubernetes can host agents that help govern Kubernetes, provided each part performs the role it handles best. Agents tackle reasoning about uncertain scenarios, operators enforce declared state, and policy establishes guardrails for both. Accountability for the pace of transition from recommendation to autonomous action rests with the humans overseeing the system.