Agentic Autonomy Levels - by Addy Osmani - Elevate
SubscribeSign in
Agentic Autonomy Levels<br>A working model of autonomy for agentic engineering
Addy Osmani<br>Jul 03, 2026
74
Share
In most conversations about agentic engineering, the action has changed from prompting to operating . Here’s a frontier looking into the fog: software factories, goals, loops, background sessions, subagents, hooks, sandboxes, agent-approving agents . For many creators of the future, this behavior will be baked into products day-1: Claude Code and Codex expose the shift directly.<br>From the engineer standpoint, you’ll use low autonomy to limit risk and increase reversibility, but use higher autonomy for explicit activities, and fleets of parallel agents safely refactoring massive codebases. The core question about an action is always: what level does this task deserve, and what verification makes that level defensible?<br>The edge of the frontier is the manager agent that wakes on its trigger, delegating to its helpers while continuously verifying their output , and returning with only the decisions that must be made by a human . Folks using this kind of setup may indeed already be running hundreds or thousands of agents, largely on evergreen codebases. Like most all thinking about autonomy, how you perceive the scale is still different for everyone .<br>The scale most often mentioned is from Steve Yegge’s single-axis ladder mentioned in “Welcome to Gas Town” and in The Pragmatic Engineer. It’s a good reference if you want a number that tells you how AI-native you are: the ladder gives you a single number to measure if you know your trust in a single agent. Here’s one version of it:
In early 2026, even while work began to shift from delegation to orchestration, this was a fairly good proxy for measuring risk. Today, however, many skill sets may have increased significance and leverage when you can run many agents at once. A single rung cannot help you place multi-agent skill.<br>Instead, almost every autonomy debate I’ve seen conflates two questions that should be separated: how far away from yourself are we letting this single agent go, and what is our skill at coordinating many agents?<br>To capture these two dimensions separately, we’ll use two axes: agency and orchestration.
On the agency axis, low includes suggesting candidate actions and waiting for a decision .<br>Mid means that the agent is working on a particular task, but scopes what it does , and constantly reports back what it does along with evidence, so you can keep steering it.<br>At the high agency end, the agent is working towards a goal , experimenting, learning, testing, finding ways to solve a problem, getting blocked, asking questions, trying different approaches, and returns all of this work in evidence .<br>On the orchestration axis, low means one agent, one thread. At mid, you’ve got several agents, each working in its own worktree, possibly working towards different goals, but isolated. At the high end, you’ve got an orchestrator that can take a backlog, issue tracker, schedule, or other queue, and turn it into continuous work, and you only need to step in when things fail: “management by exception.” Products and features incorporating these ideas include:<br>Claude Code’s /plan, /goal, /loop, /background, /batch, /code-review, /security-review modes, subagents, hooks, checkpointing, agent delegation and management practices, background sessions, agent-team patterns, /schedule arguments
Codex’s local/cloud threads, Goal mode, worktrees, Automations, subagents, review panes, GitHub code review, hooks, sandboxing, Auto-review, and rerun
These capabilities don’t fit onto a single ladder.<br>The climb: three eras and a single stack
If you read the ladder bottom-up, you’re imagining climbing both agency and orchestration at the same time. In effect, the six levels represent three separate eras that we all pass through:<br>First, you’re in the driver’s seat, and an agent mostly just helps, waiting for you to steer it.<br>Second, the agent takes charge of a bounded task or goal, but you’re still around to steer it and verify what it does.<br>And third, in the era of orchestration, the system is capable of running the show, dispatching work across many agents, and you mostly need to step in when things go wrong: “management by exception.”<br>This makes things simpler, because the vertical position on the ladder neatly captures the two axes (orchestration only kicks in near the top), leaving it as a single steady climb through the rungs. And yet, the climb is still part of a shift that we’re all going through.
A good day doing engineering includes touching several rungs, sometimes more: it’s normal to switch between the eras a few times in the course of a task.<br>The six levels in detail
Level 0: Assist<br>The agent makes suggestions that are mostly good and often perfect, but you will always decide whether they’re good enough to act on. Think autocomplete, inline edit suggestions, or hanging...