K8s Agents: Phased Autonomy for Infrastructure
CNCF accepted agent frameworks into the Sandbox tier. The kagent project, now open source, provides a concrete example of how AI agents can operate inside Kubernetes clusters. Vikram Seshadri of DoiT describes a progressive approach where each step widens what the agent is allowed to do. The progression is explicit, auditable, and reversible.
This matters because Kubernetes is where infrastructure governance either works or fails at scale. And the pattern kagent introduces transfers well beyond clusters.
The Four Phases
The article recommends a progressive approach to agent autonomy:
Phase 1: Read-only. The agent observes cluster state, reads logs, inspects resources. It cannot change anything. Every query is logged. The operator gains confidence in what the agent understands before granting it any authority to act. This is the onboarding period.
Phase 2: Patch generator. The agent proposes changes as patches or pull requests. A human reviews and applies them. The agent reasons; the human executes. The separation is structural, not a gentleman’s agreement.
Phase 3: Approved low-risk. The agent executes a defined set of operations without human approval. The boundary is explicit: specific actions, on specific resource types, within specific namespaces. The approval surface is documented and auditable.
Phase 4: Autonomous well-understood. The agent handles routine operations end to end. Scaling, rolling restarts, certificate renewals, resource cleanup. These are operations the team has run hundreds of times, where the failure modes are known and the rollback path is tested.
The phases form a trust ladder. Some agents will stay at Phase 2 permanently. That is a design decision.
Agent Reasons, Operator Executes
The architectural separation in kagent is worth studying on its own. The agent is a reasoning component. It observes state, interprets intent, and proposes actions. The Kubernetes operator is the execution component. It validates the proposed action against policy, applies it to the cluster, and records the result.
This separation has two consequences.
First, the agent does not need unrestricted authority over the cluster. The operator mediates every action. The agent’s compromise surface is limited to bad recommendations, not unauthorized mutations. A reasoning failure produces a rejected patch. An operator failure produces an audit entry with a rollback target.
Second, the policy layer sits between reasoning and execution, not after execution. Traditional monitoring catches problems in retrospect. This architecture catches them before they happen. The operator can enforce constraints the agent does not know about: resource quotas, network policies, compliance labels. The agent proposes a deployment to a namespace it considers appropriate. The operator checks whether that namespace accepts workloads of that classification. The rejection happens before any pod is scheduled.
Four Properties of Every Action
Seshadri argues that every agent action should satisfy four properties: authorized, bounded, observable, and reversible.
Authorized means the action maps to a permission the agent was explicitly granted. The permission set is a deliberate document, not a side effect of cluster RBAC.
Bounded means the blast radius is defined before execution. The bound is not advisory. The operator enforces it.
Observable means the action produces a structured log entry that includes the reasoning chain, the proposed action, the policy evaluation result, and the execution outcome. The logs constitute the audit trail that justifies the autonomy level.
Reversible means the action has a tested rollback path. Actions that lack a clean reversal require a higher authorization level and, in most configurations, human approval regardless of the agent’s autonomy phase.
These four properties are not Kubernetes-specific. They apply to any system where an agent acts on infrastructure.
Beyond Kubernetes
The phased autonomy model transfers to any domain where agents touch production systems. Database agents that start by generating query plans (Phase 2) before executing them (Phase 3). CI/CD agents that propose pipeline changes as pull requests before merging them. Cloud cost agents that recommend right-sizing before applying it.
The reasoning-execution separation transfers too. An agent that recommends a Terraform change and an operator that applies it after policy evaluation follows the same architecture. The agent never holds cloud credentials. The policy layer sits between the recommendation and the API call.
Teams building governance into their tooling already understand the principle. What kagent adds is a concrete progression model. Instead of binary states (human-in-the-loop or fully autonomous), the four phases give teams a vocabulary for intermediate states. Each agent can sit at a different phase for different operation types, and the phase assignment is a document the team can review.
What This Means in Practice
If your team runs agents against infrastructure today, map each agent to kagent’s four phases. You will likely find most are operating at Phase 1 or Phase 4 with nothing in between. The middle phases are where operational maturity develops. A Phase 2 agent that generates patches for six weeks teaches the team what the agent gets right and where it drifts. That data justifies the Phase 3 boundary definition.
If your agents lack the reasoning-execution separation, that is the first architectural change to make. An agent that holds credentials and executes its own recommendations has no structural point where policy can intervene. The separation is the mechanism that makes the phases enforceable.
CNCF’s acceptance of agent frameworks into Sandbox signals that the Kubernetes ecosystem treats agent governance as infrastructure, not as an application concern. The four-phase model, the reasoning-execution separation, and the four properties of authorized, bounded, observable, reversible will show up in other ecosystems within the year. Teams that adopt the pattern now will have the operational data to tune it. Teams that wait will adopt it under pressure, without that data.
This analysis synthesizes AI Agents Kubernetes Control (Vikram Seshadri, DoiT, October 2026).
Victorino Group helps teams implement phased autonomy for infrastructure agents. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation