Maturity ladders for agent setups are everywhere now, and they follow a pattern. Level one is a one-shot prompt. Somewhere in the middle you get skills, tool servers, parallel subagents, scheduled runs. By the top you have voice input, an IDE plugin, an HTTP endpoint, and the whole configuration packaged as a repository you could hand to a new hire or sell.
They are useful as inventories. As ladders they are misleading, because a numbered list implies you climb it, and climbing implies each rung sits above the last on the same dimension.
These rungs do not. Sort fifteen of them by what they actually change and they fall into three separate stacks, only one of which has anything to do with autonomy.
Three axes wearing one set of numbers
| Axis | What it changes | Typical rungs |
|---|---|---|
| Capability | What the agent can do at all | Memory, skills, tool servers, browser control |
| Autonomy | How much happens without you present | Background runs, schedules, parallel subagents, dependency-driven task boards |
| Reach | How you and others get to it | Voice messages, IDE plugin, HTTP endpoint, packaged repo |
Read the usual list against that table and the numbering stops making sense.
Voice input is a reach change. It is genuinely nice to ask a question from the car and hear a thirty-second answer, and it adds precisely zero autonomy — the agent does exactly what it did before, and you are more present, not less. An IDE plugin is the same: convenience, not capability, not independence. Packaging the whole setup as an installable repository is a distribution decision that belongs to a different conversation entirely.
Meanwhile browser control, which sits high on most lists, is a capability rung with a caveat the lists usually admit in passing: it is slower and more fragile than an API call, and it exists only because some site has no API. That is not a graduation. That is a workaround you take on when you have no choice.
None of these three axes bounds the others. You can run a fully scheduled, unattended agent with no voice, no plugin and no package. You can have voice, an IDE integration and a public endpoint wrapped around something that does nothing unless you ask. Presenting them as one sequence suggests a progression that does not exist, and it obscures the one distinction that carries real consequences.
Only one axis carries risk
Capability failures are visible and immediate: the agent cannot do the thing, and you find out within a minute. Reach failures are cosmetic: the plugin breaks and you open a terminal.
Autonomy is different in kind, because autonomy is the axis where the gap between an action and someone noticing it grows. That gap is the entire risk profile.
An agent you prompt and watch has a review step built in — you. An agent that runs at 3am has none, and every property you were relying on your own attention for now has to be a property of the system. Which is a different engineering problem, not a bigger version of the same one.
The three things that stop being free the moment you move up this axis:
Permissions become the whole safety story. While you are watching, an over-broad tool grant is contained by the fact that you would notice. Unattended, it is not contained by anything. This is where the least-privilege reading of agent configuration stops being tidy practice and becomes the actual control.
Termination has to be guaranteed rather than typical. You are not there to stop it. An agent without a turn cap and a wall-clock bound is an unbounded loop with a credit card attached, and “it usually finishes” describes a system, not a guarantee.
Failure has to be reported, not merely handled. A scheduled agent that silently does nothing for two weeks looks identical to a scheduled agent that is working. Absence of complaint is not evidence, and this is the failure mode that actually happens.
None of that is required at the levels below. All of it is required at the first level where the agent acts while you sleep, and it is required in full — there is no partial version of “nobody is watching”.
The value curve is not the level number
The other thing a numbered list hides is that the returns are wildly uneven.
The steep part is early. Persistent memory so it stops re-learning your context, a few well-scoped skills, connections to the two or three systems where your actual work lives. That handful of changes converts a chat window into something useful, and everything after it is refinement.
Parallel subagents illustrate the flattening well. They read as a clear step up — more agents, more throughput — and they carry a cost that the level number does not mention: each delegation is a fresh context that must re-establish what it needs, do the work, and return a summary the parent then has to comprehend. Worth it when a subagent consumes a lot and returns a little. A straightforward loss when it does not, which is the same arithmetic as any supervisor pattern.
The dependency-driven task board is the clearest case of a rung that is right for some people and wrong for most. Cards that unblock other cards is real coordination machinery, and it earns its keep on a quarterly project with a dozen branching tasks. On a three-step pipeline it is overhead with a dashboard.
What actually decides where you stop
Not the level number. Two questions, and neither appears on any ladder.
Who debugs this on a Tuesday? Every rung is a component that fails. A scheduled job whose credentials expire. A tool server whose upstream API changed shape. A browser automation that broke because a page was redesigned. The realistic ceiling for any setup is the highest rung whose failures somebody is willing to sit down and fix, and for a one-person setup that number is small and honest.
What does a silent failure cost here? Below the autonomy line, near zero — you were watching. Above it, the cost is whatever accrues between the failure and the discovery, which for a nightly job is at least a day and in practice is however long until someone happens to look.
That second question is the one that should gate movement up the autonomy axis, one rung at a time, with the reporting built before the automation rather than after the first quiet week.
A better shape than a ladder
Three separate decisions, made independently:
- Capability: add what your actual work needs. Memory and two or three real integrations cover most of the value. Browser control only when there is genuinely no API.
- Autonomy: advance one rung at a time, and pay the tax first. Turn caps, narrow permissions, and a failure report that reaches a human. Then schedule it. Not the other way round.
- Reach: pure convenience, order it by taste. Voice, plugins and endpoints do not require the other two to be mature and do not make them so.
The ladder framing quietly suggests that stopping at level six is settling for less. It is not. Level six on the capability axis with level two on the autonomy axis is a coherent, maintainable position, and it is where most working setups belong — including ones that would look unambitious on somebody’s numbered chart.