Understanding AI Agent Autonomy Levels: From Prompting to Managing Persistent Agents

Table of Contents

1. Climbing: Three eras and a stack

2. Six levels

3. Risks and reversibility set the ceiling

4. Metrics make autonomy a bit more reliable

5. Readiness thinking

6. Four anti‑patterns

7. Calibration exercise

8. How to climb safely

Most discussions about agent engineering have shifted from "how to prompt a model" to "how to operate and manage continuously running agents." Emerging concepts such as software factories, goals, loops, background sessions, sub‑agents, hooks, sandboxes, and approval agents are still forming, and many future products will embed these capabilities from day one. Claude Code and Codex already expose this shift.

From an engineer’s perspective, low autonomy favors risk control and rollback, while higher autonomy suits well‑defined goals and enables parallel agents to safely refactor large codebases. Every time an agent is asked to act, the same question arises: which autonomy level should the task occupy, and what verification is needed for that level to be defensible?

The most forward‑looking form is a management‑type agent that wakes on trigger conditions, dispatches helper agents, continuously validates their output, and only escalates the human‑decision parts. Teams already running hundreds or thousands of agents on evolving codebases experience this, though perceptions of scale differ.

The most cited scale comes from Steve Yegge’s "Welcome to Gas Town" and The Pragmatic Engineer’s single‑dimensional level table. It provides a numeric reference for how much an engineer trusts a single agent. Below is one version of that table.

At the start of 2026, even as work moves from delegation to orchestration, the level table remains a useful proxy for risk. However, when multiple agents run concurrently, many skills become more important and the single‑dimensional table cannot describe multi‑agent collaboration capability.

All autonomy debates mix two questions that should be separated: how far can a single agent operate independently, and how strong is our ability to coordinate multiple agents. These correspond to two axes: autonomous execution ability and orchestration ability.

On the autonomous execution axis, the low end is proposing candidate actions and waiting for human decision. The middle ground lets the agent handle a specific task within a bounded scope while reporting evidence so the human can still guide it. The high end has the agent work toward a goal, iterating, testing, and asking questions when blocked, returning evidence for any human‑required decisions.

On the orchestration axis, the low end is a single agent on a single thread. The middle ground involves multiple agents each working in their own worktree, possibly pursuing different goals but isolated from each other. The high end is an orchestrator that consumes backlogs, issue trackers, or schedules, turning them into continuous workflows and intervening only on failures or decisions (exception management). Products and capabilities that embody these ideas include:

Claude Code’s /plan, /goal, /loop, /background, /batch, /code‑review, /security‑review modes, sub‑agents, hooks, checkpoints, delegation, background sessions, team mode, /schedule parameter.

Codex’s local/cloud threads, Goal mode, worktree, Automations, sub‑agents, review pane, GitHub code review, hooks, sandbox, Auto‑review and rerun.

These capabilities cannot fit into a single‑dimensional level table.

1. Climbing: Three eras and a stack

Reading the level table from bottom to top, you can imagine autonomous execution and orchestration climbing together. The six levels represent three stages most teams experience:

First, you sit in the driver’s seat while the agent provides assistance and you steer.

Second, the agent takes a bounded task or goal, but you stay nearby to guide and verify its work.

Third, in the orchestration era, the system runs globally, dispatching work to multiple agents while you intervene only on exceptions.

This view simplifies the climb as a steady progression, which mirrors the ongoing change.

On a good engineering day, several levels are touched, and switching between stages during a task is normal.

2. Six Levels

2.1 Level 0: Assistant

The agent suggests actions that are often good or perfect, but execution and judgment remain with the human. Examples include autocomplete, inline edit suggestions, or chat‑based discussions around a change that has not yet been taken. Suitable when error cost is high, changes are small, or the human is still forming a judgment. Verification happens locally.

2.2 Level 1: Supervised Execution

The agent edits or runs commands on behalf of the human but asks for permission before any consequential action. This is the default posture for most people. It can happen in a local sandbox with per‑change approvals, each approval serving as an independent verification. In interactive sessions, approval fatigue can arise when many approvals look alike despite differing content. Codex Auto‑review delegates final boundary‑condition approvals to another reviewer agent, mitigating this issue.

2.3 Level 2: Bounded Task Delegation

A task with a clear goal, constraints, and definition of "done" is handed to the agent. The human stays nearby and can interrupt, but most of the time does not participate. Verification must rely on evidence the agent produces—automated test passes, type correctness, lint suggestions, screenshots, reproducible steps, source citations, etc.—rather than the human’s constant presence.

2.4 Level 3: Goal‑Driven Autonomy

The agent takes necessary actions to achieve a goal and stops when a condition is met. In prompt mode, the prompt itself is the goal (e.g., "reduce page time‑to‑interactive to under 1 s"). In Codex this is Goal mode, looping through plan → act → test → review until success. In Claude Code the equivalents are /goal, /loop, and /schedule commands. The level is useful only when stop conditions are automatically measurable.

Ambiguous goals like "improve overall user experience" should be avoided. Prefer concrete, measurable, automatable goals such as finding production bugs missed by static analysis, lowering load time, ensuring strict TypeScript builds without any, or pruning dependencies to those that are understood and testable. For production bugs, the agent must operate close to production.

2.5 Level 4: Parallel Delegation

Multiple agents work in parallel, each handling an isolated slice of the task. The main bottleneck is decomposition: defining slices suitable for delegation. Supporting mechanisms include sub‑agents, background sessions, /batch, worktree, agent teams, etc. Failure mode: false parallelism—many agents handling overlapping slices, yielding no extra work but merge conflicts and duplicate decisions. To avoid this, agents must be isolated with separate files, state, and review queues. Each additional agent adds token cost, and orchestration cost rises sharply after the first few agents.

2.6 Level 5: Exception‑Management Orchestration

Define success criteria and applicable strategies. A management‑type agent wakes on triggers (new issue, task, or timer), dispatches worker agents, monitors progress, validates output, retries on failure, escalates to stronger agents or humans when conditions are met, aggregates results (e.g., PRs), and returns evidence to external systems. This resembles a factory where the issue tracker or backlog is input and the factory’s output is a set of fixed issues and bugs. Agents run in isolated, bounded environments with escape hatches. The factory’s operating system, defined by the management agent, constrains behavior.

OpenAI’s Symphony specification illustrates this with a Linear board where each issue has its own agent work area, and agents continuously advance toward the spec‑defined goal, while human review focuses on the generated evidence. In orchestration, stronger approaches build a continuously running agent factory with hundreds or thousands of agents, making independent verification even more critical.

3. Risks and Reversibility Set the Ceiling

Anthropic’s early research on Claude Code found that clarification requests were more than twice the number of user interruptions. Users with ~750 conversations were more likely to auto‑approve and to interrupt when monitoring progress.

A broader Claude Code usage analysis (≈ 40 × 10⁴ conversations from ~23.5 k users between Oct 2025 and Apr 2026) showed that humans made about 70 % of planning decisions while Claude performed about 80 % of execution. High autonomy still requires humans in the loop to decide the next direction.

To judge whether a large AI system is in a high‑autonomy state, ask three questions:

How quickly can we know it made a mistake?

How cleanly can we roll back what it did?

What evidence proves it did the right thing?

If the answers are “cannot know quickly,” “rollback is very hard,” and “only trust a summary,” the system is not high‑autonomy.

Before each run, a contract should define the agent’s purpose, scope, non‑goals, tools and permissions, stop conditions, evidence required, escalation path, and budget (time, effort, token limits, retry limits, parallelism limits).

4. Metrics Make Autonomy a Bit More Reliable

Post‑hoc metrics are insufficient; they should be written into a concise document beforehand. Each autonomy level can track a set of metrics, such as:

Average interval between human interventions

Longest uninterrupted successful run time

Proportion of actions run in sandbox vs. requiring privilege escalation

Ratio of auto‑approved to rejected actions

Average number of agent actions per human command

Clarification request rate and interruption rate

Review time per accepted change

Rework rate per confidence tier

Defect escape rate per confidence tier

Token cost per accepted change

These metrics tell a story: a single agent with a dashboard resembles Level 4, while a conservative agent that refuses to proceed without automation entry points, retry mechanisms, and sufficient evidence resembles Level 5 with real gatekeeping.

5. Readiness Thinking

Classify work by risk and reversibility. Apply autonomy conservatively and only move up when evidence supporting a higher level accumulates. A payment‑engine refactor with strong test protection, reviewer agents, and clean rollback paths can support a higher autonomy level than a purely documentation‑automation task that lacks authoritative facts. Autonomy level should follow the verification process, not the task name.

6. Four Anti‑Patterns

Any system can fall into these four autonomy anti‑patterns:

Identity‑driven autonomy: treating the autonomy score as a badge rather than a safety proof, leading agents to operate beyond verified capability.

Permission washing: approval fatigue pushes us to grant agents overly broad access; tighten boundaries with sandbox profiles, write‑only root directories, command whitelists, hooks, and Auto‑review.

Summary substitution: replacing human review with an agent‑generated summary without the full evidence package (diffs, tests, logs, screenshots, risk analysis).

Fake fleet: running dozens of agents in parallel while still manually orchestrating each dependency; shared state, ownership rules, and dependency tracking must be codified to reduce manual coordination.

7. Calibration Exercise

Review the last ten tasks you completed with agent assistance. For each task, record the actual autonomy level used, associated risks, rollback difficulty, evidence produced for verification, review time, any rework, and whether the same level would still be appropriate for a similar future task.

8. How to Climb Safely

Advance along one axis at a time. Start with a supervised single agent handling a bounded task and producing defensible evidence (Level 1). Then expand in three orthogonal directions: parallelize read‑heavy exploratory tasks (Level 4), add write‑capable agents in separate worktrees with file‑ownership rules (Level 4), and finally introduce periodic automation that the agent orchestrates based on issues or voice input. Each step requires new safety mechanisms because new failure modes appear.

Named failure modes include drift, context decay, communication loss, or goal drift for longer‑running single agents; stale assumptions and fragile handoffs for background work; merge conflicts or duplicate decisions for excessive parallelism; silent token consumption or prompt expiration for too many periodic automations; and long review queues or alert fatigue for exception‑management. Mitigations involve narrowing scope, providing independent evidence, cheap rollback paths, hardened gatekeeping, and clearer ownership rules—not merely increasing trust.

Use the autonomy levels as guidance:

Level 0 – best for fine‑grained work and when judgment is still forming.

Level 1 – fits most exploratory work near well‑understood boundaries.

Level 2 – suits most bounded tasks, acknowledging unknown dependencies and surprises.

Level 3 – appropriate when success conditions are clearly expressible.

Level 4 – fits work that can be cleanly split around those success conditions.

Level 5 – fits when coordination and communication across multiple success conditions are fully codified.

Verification will always be the bottleneck. Although tools evolve rapidly and hype abounds, the mature stance for engineering teams collaborating with AI agents remains calibrated autonomy.

In the near future we hope to design loops that know when to work, when to verify, and when to ask questions. For now, engineers’ skill lies in choosing the correct autonomy level, building patterns, and producing defensible evidence to keep autonomy from slipping into dark corners.