Automated, autonomous and agentic describe three different levels of decision-making, not three words for the same thing. Automated means a system executes a rule a human wrote: if CPU crosses the threshold you set, add a node. Autonomous means the system decides the action itself against an objective a human set, continuously, without a rule for each case. Agentic means the system decomposes a goal into steps, chooses its own tools, and acts across systems to reach it. Most Kubernetes tooling sold as autonomous is automated. The distinction matters because it determines what you have to keep watching.
Key takeaways
- Automated executes a rule you wrote. The system has no opinion about whether the rule is still correct.
- Autonomous acts against an objective you set, continuously, without a pre-written rule for each case.
- Agentic plans, selects tools, and acts across systems toward a goal you specify.
- Most Kubernetes tooling described as autonomous operates at Level 1: automated.
- The trust boundary does not disappear as you move up levels. It moves.
- Moving it safely requires guardrails, rollback, and decision evidence.
Why the words are used interchangeably, and why that costs you
Vendors borrow language from adjacent fields to make products sound more capable. “Autonomous” is currently doing double duty. It appears in marketing copy for tools ranging from simple threshold alerts to genuinely objective-driven systems. The result: two products described identically can work at completely different levels of decision-making.
For buyers, the confusion is practical, not academic. A team that purchases an “autonomous” autoscaler and expects no ongoing configuration often discovers the system needs constant rule updates. The tool is automated. The team expected autonomous. That gap shows up in toil, not in demos.
This post borrows a structural analogy from SAE J3016:2021, the driving automation standard defining six levels of vehicle automation. The analogy is acknowledged here, not claimed as original. SAE’s key inflection sits between Level 2 and Level 3: below that line the human holds primary responsibility, above it the automated system does. The same inflection exists in Kubernetes operations, and knowing which side of it your tooling sits on is equally important.
What a buyer is actually asking when they ask if it is autonomous
When a team asks whether a product is autonomous, they are usually asking one of three different questions. First: do I have to write the scaling rules, or does the system figure them out? Second: if conditions change significantly, do I reconfigure, or does the system adapt? Third: what am I still responsible for watching?
These are the right questions. The four-level model below answers all three for each level. Before evaluating any vendor, know which question you are actually asking. The answer determines whether you are buying automation or something genuinely different.
A four-level model of Kubernetes operations
The table below maps each level to who holds the decision, who executes the action, which Kubernetes tools live there, and what you still have to watch. It is designed to be a stable reference across future posts and vendor evaluations. When a vendor claims a level, bring them to this table.
| Level | Who decides | Who acts | Example in Kubernetes | What you still have to watch |
|---|---|---|---|---|
| Level 0: Manual | Human | Human | kubectl scale, manual node provisioning | Everything |
| Level 1: Automated | Human (wrote the rule) | System | HPA, Cluster Autoscaler, PDBs, static limits | Whether the rules are still right |
| Level 2: Autonomous | System (against your objective) | System | Rightsizing, node provisioning, Spot management, rebalancing | Objective definition and guardrail boundaries |
| Level 3: Agentic | System (decomposes goal into steps) | System across multiple tools | AI SRE: bounded failure class remediation | Goal specification, scope, and novel cases |
Level 0, manual: a human observes and acts
Level 0 is where every team starts. A human watches dashboards, notices a problem, and issues commands. The engineer observes that pods are pending. The engineer runs kubectl commands to scale the deployment or provision nodes. All decision and action belong to the engineer.
Level 0 does not scale with cluster complexity. As namespaces, workload types, and cloud regions multiply, cognitive load grows faster than any team can absorb. That pressure drives teams toward Level 1.
Level 1, automated: a human writes the rule, the system executes it
At Level 1, a human encodes a decision as a rule. The system executes the rule. If CPU utilization exceeds 70%, add a replica. If the node pool drops below five nodes, provision another. The system acts faster than a human can. But the system has no opinion about whether the rule is correct.
This distinction is critical. The decision was made when the human wrote the rule. The system carries it out. When conditions change enough that the rule is wrong, the system still executes it faithfully. Nothing in the automation loop catches that error.
Cluster Autoscaler and HPA live here
The Horizontal Pod Autoscaler runs its control loop every 15 seconds. It computes desired replicas against current CPU utilization. Critically, it measures utilization against CPU requests, not against actual node capacity. If a developer padded a request from 100m to 200m to avoid throttling, HPA sees the workload as less utilized than it is. HPA cannot detect that the request itself is inflated. That is the flaw the loop never corrects.
HPA can also target custom and external metrics: queue depth, request rate, or any metric you instrument. When configured with external metrics, HPA bypasses the CPU request problem entirely. Most teams do not do this, which is why the request-based utilization trap remains the dominant failure mode.
Cluster Autoscaler compounds the problem. It checks for pending pods every 10 seconds and responds to pending pods that HPA created. Scale-down triggers when requested resources on a node fall below 50%, not when actual usage does. The cascade follows: padded requests make the cluster look underloaded, more nodes are provisioned, costs rise, and the loop never self-corrects. By default, CA waits 10 minutes before declaring a low-utilization node unneeded, and another 10 minutes after any scale-up before it will scale down again.
Karpenter also sits at Level 1. Its NodePools and NodeClasses are rules you configure. It executes them. Karpenter responds to pending pods with instance selection logic you defined; it does not optimize across your objective function. One exception: Karpenter’s consolidation mode (consolidationPolicy: WhenUnderutilized) proactively identifies and drains underloaded nodes, this behaviour sits at the boundary between Level 1 and Level 2 and warrants separate evaluation.
Vertical Pod Autoscaler (VPA) also operates at Level 1 in recommendation mode: it observes actual usage and suggests new CPU and memory requests. Applying those recommendations still requires human or automation approval.
For deeper coverage of autoscaler mechanics and cost optimization, see the guide to Kubernetes autoscaling for cloud cost optimization.
Level 2, autonomous: a human sets the objective and the guardrails, the system decides continuously
Level 2 changes who makes the decision. A human sets an objective: minimize cost, maintain a latency target, keep Spot interruptions below a threshold. A human also sets guardrails: do not touch namespace X, keep at least N on-demand nodes, roll back if error rate spikes. Within those boundaries, the system decides what action to take and when, continuously, without a pre-written rule for each case.
The difference from Level 1 is not speed. It is adaptability. A Level 2 system responds to a workload pattern it has never seen before, because it optimizes against an objective rather than executing a predetermined rule. When conditions drift, the system recalibrates. The human does not need to schedule a rule review.
Automated rightsizing and node provisioning live here
Rightsizing at Level 2 means the system observes actual CPU and memory usage over time and adjusts pod requests accordingly. No engineer sets a request value. The system continuously refines its view of what each workload actually needs and applies adjustments within guardrails the engineer controls.
Node provisioning at Level 2 means the system selects instance types based on current workload requirements, availability, and cost signals. It manages Spot instance selection and handles interruptions. The engineer sets the objective; the system handles the implementation continuously. A Level 2 system is distinct from Karpenter’s Level 1 mechanism: it continuously adjusts which instance types, sizes, and pricing models to use against a cost objective you set, without requiring you to maintain NodePool definitions for every scenario. For a broader view of what this level of optimization covers across cloud infrastructure, see what is autonomous cloud cost optimization and what you can gain from it.
Level 3, agentic: a human sets a goal, the system plans, selects tools and acts across systems
Level 3 adds a reasoning layer above decision-making. A human sets a goal: resolve this class of incidents, diagnose this performance degradation, remediate OOMKill failures in service X. The system then decomposes that goal into steps, selects which tools to use at each step, and acts across multiple systems to reach it.
This is qualitatively different from Levels 1 and 2. Level 1 – the human wrote a rule for each case. At Level 2, the human set an objective and the system optimized. At Level 3, the system plans its own sequence of actions and selects its own tools. The human defined the goal and the scope, not the method.
Where this is real today and where it is a roadmap
Bounded failure class remediation is real today. An agentic system can identify an OOMKill pattern, correlate it with resource history, and apply a remediation within defined scope. CrashLoopBackOff diagnosis and incident analysis for known failure classes are tractable for current agentic tooling.
Novel incident diagnosis remains a roadmap item for most vendors, including Cast AI. General autonomous incident resolution for any incident the system has not seen before does not reliably exist in production today. Any vendor claiming otherwise deserves specific, difficult questions. The six questions later in this post will help you ask them.
What changes at each level: who holds the decision
The core variable across all four levels is not speed, capability, or cost. It is decision ownership. At Level 0, the human owns every decision. With Level 1, the human defines the decision through a rule, while the system handles execution. Level 2 shifts tactical decisions to the system, with the human retaining ownership of the objective and constraints. By Level 3, the system owns the plan, while the human sets the goal and scope.
Understanding this helps avoid a common mistake: treating level transitions as purely technical upgrades. Each level shift changes what a human is responsible for monitoring. As decision ownership moves to the system, the human’s job shifts from making decisions to verifying that the system’s decision-making stays within intended boundaries.
The trust boundary, and why it moves rather than disappears
Moving to a higher level does not eliminate the trust boundary. It relocates it. At Level 1, the boundary is defined by the rule written by the human. At Level 2, it shifts to the objective and guardrails, while Level 3 moves the boundary to the goal specification and defined scope of action.
This matters when evaluating autonomous tooling. The question is not whether the system makes decisions without you. At Level 2 and above, it does. The question is whether the boundary you set is the right one, and whether the system produces enough evidence for you to verify it stays within that boundary.
A system that moves fast but provides no decision audit trail is not safer because it is autonomous. It is harder to correct when it is wrong.
Guardrails, rollback and evidence as the price of moving it
Three things make it safe to move the trust boundary upward: guardrails, rollback, and evidence. Guardrails define what the system cannot do. Rollback defines what happens when the system makes a wrong call. Evidence is the decision log that lets you verify the system stayed within its intended scope.
Without all three, moving from Level 1 to Level 2 is not a capability gain. It is a visibility loss. You gave the system more autonomy but cannot audit what it did with it. For more on how decision evidence works in practice, see how Cast AI automation decides.
Reducing operational toil is the other side of this equation. The aim is not to remove humans from the loop entirely. The aim is to remove humans from decisions the system can make better and faster, while keeping them close to decisions where judgment and context still matter. For more on the toil reduction framing, see how to reduce Kubernetes toil.
Why level 1 stopped being enough
Level 1 automation was a meaningful improvement over manual operations. It removed the need for an on-call engineer to respond to every scaling event. Over time, though, two structural problems with Level 1 have become more visible as clusters grow in size and complexity.
Autoscalers respond to requests, not usage: the mechanism behind 69% overprovisioning
Average CPU overprovisioning across the clusters in the Cast AI 2026 fleet dataset sits at 69%, up from 40% in the 2025 report. Actual average CPU utilization is 8%. Despite years of autoscaler adoption, the gap between provisioned capacity and actual usage has widened, not narrowed.
The mechanism is not a bug in HPA or Cluster Autoscaler. It is a structural mismatch between what autoscalers measure and what engineers actually care about. HPA measures utilization against CPU requests. Engineers set requests high to avoid OOMKills and throttling. So HPA computes utilization against inflated requests, sees the cluster as underutilized, adds replicas, and Cluster Autoscaler provisions more nodes to accommodate them.
The rule (an HPA target percentage) was correct when written. The input (padded CPU requests) was always wrong. Nothing in the Level 1 automation loop detects that the input is wrong. The loop runs faithfully, compounding a flawed baseline.
A rule written once is a decision frozen at the moment it was written
The second problem is staleness. A scaling rule written during initial cluster setup reflects the workload patterns and infrastructure costs of that moment. As traffic patterns shift, as instance types change, as teams add services, the rule ages. The system, however, keeps executing it.
At Level 1, catching this requires a human to review the rules periodically and reconfigure them. In practice, most teams do not do this systematically. The rules become infrastructure debt. The automation keeps running, costs keep rising, and the only visible signal is the billing report.
Level 2 addresses this structurally. Because the system optimizes against an objective rather than executing a fixed rule, it adapts as conditions change. No rule review needs scheduling. The system continuously recalibrates against what you told it to achieve.
How to start
If you are on Level 1 today, start by mapping your current HPA targets. Ask: do these thresholds still reflect how the workload actually runs, or were they set once and never revisited? Run one week of actual CPU utilization data against your HPA CPU request. Use kubectl top pods -A for a quick snapshot, or run this PromQL in Prometheus to see utilization as a percentage of requested CPU across all workloads over 7 days:
100 * sum by (namespace, pod) (rate(container_cpu_usage_seconds_total{container!=''}[5m])) / sum by (namespace, pod) (kube_pod_container_resource_requests{resource='cpu'})Pods consistently below 30% utilization of their request are good candidates for rightsizing. If the gap between requested and actual is larger than 50%, that is your first argument for moving to Level 2.
What to ask a vendor
Most vendor demos show the system working under favorable conditions with pre-tuned inputs. The six questions below surface which level a product actually operates at. Ask them directly. A useful product will have direct answers. A product that deflects them is probably one level lower than advertised.
Six questions that separate the levels, phrased so the answer cannot be marketing
- Who writes the rule: you, or the system? If your team sets the threshold values, that is Level 1. If the system derives thresholds from observed behavior, ask specifically how and what evidence it produces.
- What happens when conditions change significantly? Does the system adapt without intervention, or does someone need to reconfigure it? If reconfiguration is the answer, that is Level 1, regardless of how the vendor describes it.
- How does it handle an exception it has never seen before? A Level 1 system follows the nearest matching rule or takes no action. A Level 2 system optimizes against the objective. A Level 3 system attempts to plan. Know which behavior you are buying before you sign.
- Show me the rollback. What happens when the system makes a wrong call? Is rollback automatic, manual, or partial? Can you see exactly what the system changed and restore to a prior state cleanly?
- What evidence does it produce for each decision? Can you audit every action the system took and the reasoning behind it? A dashboard summary is not the same as a decision event log. Push for the underlying data.
- What decisions can the system explicitly not make without a human? This is the most revealing question. A vendor that cannot name specific exclusions has not drawn a trust boundary. That means you have not drawn one either, even if you think you have.
Where Cast AI sits, and where it does not
Cast AI operates primarily at Level 2 for infrastructure decisions, with early Level 3 capability in incident analysis. This placement is honest, not marketing. Understanding where the boundary between them sits matters for deploying it correctly.
An honest placement, with the parts that are still level 1 named
Level 2 in Cast AI: Rightsizing adjusts pod CPU and memory requests based on observed usage, continuously. Node provisioning selects instance types based on workload requirements, cost, and availability signals. Spot instance management handles selection and interruption response. Bin-packing and rebalancing run against cost and availability objectives. The engineer sets the objective and guardrails; Cast AI decides the tactical actions within them.
Still Level 1 in Cast AI: PDB configurations, namespace exclusions, and guardrail policies are rules the engineer writes. Cast AI executes them. If you exclude a namespace from rightsizing, that exclusion is a rule you set. Cast AI does not question whether the exclusion is still correct. That is a Level 1 boundary the engineer controls and remains responsible for reviewing.
Early Level 3 in Cast AI: The AI SRE product handles bounded failure class remediation. OOMKill patterns and CrashLoopBackOff incidents within a defined scope are addressable today. General autonomous incident resolution for novel, previously unseen incident types is a development area, not current capability. Cast AI will state this directly. Any vendor that will not should be asked why.
For teams evaluating Cast AI against these criteria, the most useful starting point is the Kubernetes cost optimization overview. For a closer look at how the AI SRE product handles incident remediation, see AI SRE and cost automation.
Conclusion
Four levels. Four different answers to the question of who holds the decision. Level 0 puts both decisions and actions in human hands. At Level 1, the human writes the rule while the system handles execution. Level 2 shifts continuous decision-making to the system, with the human setting the objective. By Level 3, the human defines the goal, while the system plans and acts across systems.
Most Kubernetes tooling marketed as autonomous operates at Level 1. The 69% average CPU overprovisioning found in the Cast AI 2026 fleet dataset is, in part, a Level 1 problem: rules measuring the wrong input, running faithfully, compounding waste year over year. Moving to Level 2 does not remove the human from the loop. It moves the human’s responsibility from writing rules to setting objectives and monitoring boundaries.
For teams exploring what the AI SRE layer adds at Level 3, see AI SRE and cost automation. When you are ready to see Level 2 autonomous operations running in a production cluster, request a demo.
Frequently Asked Questions
Automated means a system executes a rule a human wrote. The decision was made by the human; the system only carries it out. Autonomous means the system makes the decision itself, against an objective a human set, without a pre-written rule for each case. The key distinction is decision ownership. Automated systems faithfully execute decisions that may have become wrong over time. Autonomous systems adapt continuously within the boundaries you define.
Agentic means a system can decompose a goal into steps, select which tools to use at each step, and act across multiple systems to reach the goal. In infrastructure, this means setting a goal like “remediate OOMKill incidents in service X” and having the system plan and execute the remediation without step-by-step instructions from a human. Agentic systems operate at Level 3 of the decision model. They exist in limited, bounded forms today. General agentic incident resolution for novel situations remains a development area for most vendors.
No. Standard Kubernetes autoscalers, specifically HPA and Cluster Autoscaler, operate at Level 1: automated. They execute rules a human wrote. HPA scales replicas based on a threshold you set, measured against CPU requests. Cluster Autoscaler provisions nodes in response to pending pods. Neither tool adapts when the rules themselves become wrong. Autonomous Kubernetes operations, at Level 2, means the system continuously adjusts based on actual objectives rather than fixed thresholds written at setup time.
Autonomous Kubernetes operations means the system makes infrastructure decisions continuously against objectives a human set, without a pre-written rule for each case. Examples include rightsizing pod requests based on observed usage, selecting instance types based on current cost and availability signals, and managing Spot interruptions. The human sets the objective and guardrails. The system handles the tactical decisions. This is distinct from automated operations, where the human also writes every decision rule in advance.
For bounded, well-defined failure classes, yes. Agentic systems handle OOMKill remediation, CrashLoopBackOff diagnosis, and incident analysis for known failure patterns in production today. For novel, previously unseen incidents requiring open-ended reasoning, current agentic tooling is not reliably production-ready. Most vendors, including Cast AI, treat general autonomous incident resolution for novel situations as an active development area. Evaluate vendor claims using the six questions in this post before deploying in production.
Ask who writes the rules. If your team sets threshold values, that is Level 1: automated. Ask what happens when conditions change significantly: if the answer is reconfiguration, that is Level 1, regardless of the product name. Ask for the rollback mechanism and the decision audit log. A genuinely autonomous tool adapts to new conditions without reconfiguration, produces evidence for each decision it makes, and has a clearly defined set of decisions it will not make without human approval.
