The New Stack maps where AI agents belong in a Kubernetes cluster

Platform teams are already letting coding agents change live Kubernetes clusters, one pull request at a time, with no policy for what the agent may do by itself. Vikram Seshadri, writing in The New Stack, says the boundary between what the agent decides and what Kubernetes carries out should be set by written design, so every team has one answer to the question.

Seshadri frames it as a split of jobs. A Kubernetes operator reconciles resources to a declared state, retries failed operations and converges on a known shape. An AI agent is useful when the goal is clear but the path is not: it can read across several systems, weigh tradeoffs and suggest a next step. A safer pattern, he writes, is to give the agent the reasoning and the context, and keep the operators, policy engines and other deterministic systems in charge of execution.

The six-step loop

The piece names the loop as observe, diagnose, propose, approve, reconcile and verify. The first three steps use the agent. Kubernetes and its operators handle reconciliation. Verification closes the loop by checking that the accepted change produced the intended result, rather than treating a successful merge as proof of success.

Two worked examples carry the recommendation. In the first, a kagent-based operations agent sits above Karpenter. It reads NodePool and EC2NodeClass settings, pending pods, Kubernetes events, Pod Disruption Budgets, Karpenter logs and Prometheus metrics, then asks why the observed behaviour differs from the team's goal. The agent writes a narrow configuration patch and explains the tradeoff: a NodePool disruption budget change states the maximum number of nodes affected, a consolidation change states how long the team will watch workload stability. Karpenter still schedules and disrupts.

Helm charts, Argo CD and rollback

The second example is a platform team upgrading a Helm chart managed by Argo CD. The agent compares release notes, existing values and rendered manifests, catches that a renamed value would silently fall back to a default, and opens a focused pull request that updates the chart version and the affected values and defines the checks required before rollout. Once the request is merged, Argo CD renders and synchronises the chart under its sync policy. The agent then reads Argo CD's sync and health status alongside application metrics, and proposes a Git revert or a recovery plan through the same approval process if the checks fail.

Seshadri closes with a line any platform team can hand to its security team. The agent may call kubectl, Helm or a cloud API, Seshadri writes, as long as every action is authorized, bounded, observable, and reversible.

The authority that stays with a human is the pace of autonomy. Teams can start with a read-only investigator, let it generate patches or pull requests, then permit approved, low-risk changes with explicit scope and rollback conditions. Only well-understood actions with measurable outcomes should run on their own.

For a team already running a coding agent inside a Kubernetes cluster, the loop is a concrete answer to a question that is usually left to the next incident: who merges the chart, who writes the policy and who checks that the chart did what it said.

Source

• AI agents vs. Kubernetes: where each belongs in the control loop, by Vikram Seshadri in The New Stack