AI agents and Kubernetes operators should not be treated as equivalent alternatives within the control loop. An operator is designed to monitor the actual state, compare it with the desired state, and then execute defined rules reproducibly until the system approaches the declared outcome. An agent, by contrast, is most useful when the outcome is known but reaching it requires investigation, information gathering, and weighing trade-offs.
The article, sponsored by the Cloud Native Computing Foundation (CNCF), says that introducing agents into cloud-native infrastructure makes defining authorization boundaries a design issue rather than merely a convention. The safest approach is to keep the agent responsible for reasoning, context, and proposals, while operators, policy engines, and deterministic systems retain execution authority.
A Control Loop That Separates Reasoning from Execution
This model proposes a practical sequence of six stages: observation, diagnosis, proposal, approval, reconciliation, and finally verification. In the early stages, the agent can inspect resources, logs, events, metrics, and documentation, but it does not automatically receive permission to apply changes or modify or delete resources. Nonsensitive read operations can be automated, while impactful changes pass through explicit approval or a policy gate.
The kagent project, an open-source project within the CNCF Sandbox, presents an example of this. It runs agents as Kubernetes resources and connects them to Kubernetes, Helm, observability tools, and custom tools, enabling investigation of problems or coordination among specialized agents without removing the barriers between analysis and execution.
Why Operators Should Not Be Replaced by a Language Model
The case of Karpenter clearly illustrates the difference. Karpenter is an operator that handles scheduling constraints and reconciles NodePool and NodeClaim resources. If underutilized nodes, fluctuations in Spot resources, or pods waiting to be scheduled appear, an operational agent can inspect the NodePool and EC2NodeClass configurations, events and logs, Pod Disruption Budgets, and Prometheus metrics to search for the cause.
The investigation might reveal that a disruption-blocking policy is preventing consolidation, that the disruption budget is obstructing eviction, or that the value of consolidateAfter is causing avoidable fluctuations in a variable workload. But the desired output is not a general recommendation such as “optimize the NodePool.” It is a specific configuration patch that explains the evidence and trade-off, the potential number of affected nodes, and the period for monitoring stability.
After approval, Karpenter executes the change according to its existing scheduling and disruption logic. The agent then monitors the result and verifies improved consolidation without increasing pod wait times or causing harmful disruption. If the acceptance criteria are not met, it can propose a rollback through the same path.
Another Example: Argo CD and Helm Upgrades
In a Helm chart upgrade managed by Argo CD, changing the version in Git is relatively easy, but estimating its impact on the running application is more difficult. The agent can compare release notes, current values, and generated data to discover, for example, that a new name for a value used to configure the readiness probe could cause an unnoticed fallback to a default value.
This finding should be converted into a focused merge request that updates the version and affected values, explains the operational risk, and specifies pre-deployment checks. After review and merging, Argo CD generates and synchronizes the data according to the application policy. Successful synchronization alone is not sufficient to prove the upgrade is safe; latency indicators, error rates, and availability must also be checked. If the checks fail, the agent can propose reverting the change or a recovery plan, while recognizing that data or schema changes may not be fully reversible.
Autonomy Is Earned Gradually
The article recommends starting with an agent limited to reading and investigation, then allowing it to create patches or merge requests, and afterward to execute low-risk, narrowly scoped changes with clear rollback conditions. An action should become autonomous only when it is understandable and measurable.
Editorial reading: The real change here is not adding an agent capable of invoking kubectl or Helm, but redrawing the control loop so that probabilistic reasoning does not become unlimited execution authority. The model’s practical value depends on auditable authorization, limited scope, monitoring, and the ability to reverse the impact. Human responsibility remains in determining how quickly to move from proposal to autonomy, and the article does not establish that this approach eliminates the risks of errors or makes rollback possible in every case.