Chapter 13 — The Autonomy Ladder

An autonomy level enforced by instruction is not an autonomy level. It is a hope with a number attached.

13.1 Why a ladder

Three arguments from earlier chapters converge on the need for something like this, and it is worth seeing that they are independent.

From Ashby. Chapter 8 established that variety reduction is forced: a bounded regulator cannot govern an unbounded generator, so the space of what may be produced must be narrowed. An autonomy level is variety reduction by scope of authority — the crudest and cheapest form available, because it does not require you to understand the work, only to bound it.

From governance. Chapter 11 §11.9 showed that accountability once travelled with authorship, that authorship is now machine, and that responsibility therefore defaults to approval — precisely the gate Chapter 5 demonstrated had collapsed. We have attached responsibility to the weakest remaining signal. The way out is to move accountability onto the decision that actually determines outcomes: this class of change may run at this level of authority. That is a decision someone made, can be asked about, and can revise after an incident. "The reviewer approved it" is not.

From economics. Chapter 3 established that verification capacity is the constraint. Autonomy level is the dial that sets how much verification each unit of work consumes. Setting it uniformly across all work — which is what almost every organisation does implicitly — means spending the same scarce resource on a documentation fix and a payments change.

So the ladder is not a maturity poster. It is a governance instrument, and Chapter 12's fifth prohibition is its operating rule: do not raise an autonomy level without evidence of harnessability and blast radius.

13.2 The five levels

Two clarifications that prevent the most common misreadings.

A level applies to a class of work, not to an agent, a team, or a person. The same agent may operate at A4 on dependency bumps and A0 on the payment path, in the same repository, in the same hour. Any organisation with a single answer to "what autonomy level are we at?" has misunderstood the instrument.

Higher is not better. The ladder is not a maturity progression to be climbed. A0 is the correct level for some work permanently. Chapter 8's variety-reduction framing makes this obvious: the level that reduces the most variety is the safest, and the only reason to grant more authority is that the work does not warrant the cost of withholding it.

13.3 A level is a set of revoked capabilities

This is the section that decides whether the ladder is an instrument or a poster, and it follows directly from Chapter 11.

That chapter's central finding: injection defeats every control operating on what an agent believes and cannot defeat one bounding what an agent can do. A poisoned context can make an agent want to merge without review; it cannot give the agent merge permission it does not hold.

Apply that here and a common practice collapses.

"The agent is operating at A2, so it should ask before merging" is a belief-based control. It is Chapter 10's tier four — an assertion, defeated by any injection, and defeated equally by an ordinary misunderstanding. An autonomy level implemented as an instruction in a context file is not a level. It is a hope with a number attached.

A level is real when it is implemented as capabilities the agent does not hold:

Notice what this is, structurally. It is via negativa again — defining a level by what is removed rather than what is granted. That makes four appearances now: Chapter 2's shrinking harness, Chapter 8's variety reduction, Chapter 10's unrepresentable states, and now this. The repetition is not stylistic. In a system whose failure modes are unbounded, removal is the only intervention whose effect you can be certain about, so every durable control in this book ends up being subtractive. It is worth naming the pattern rather than letting it look accidental.

Two consequences worth acting on.

The last row of Figure 13.1 is load-bearing. An agent permitted to modify the harness that governs it, or to change its own permissions, has no autonomy level — it has whatever level it can talk itself into. Chapter 8's advice to point the agent at the harness is correct and requires this separation: the agent improving the harness must be a different invocation, at a different level, with its changes reviewed as changes to a control.

Capability revocation must be scoped by effect, not by name. Chapter 11's refinement applies in full. "A2 agents may not run dangerous commands" scopes a name; a sealed sandbox with no network egress and no credentials in the environment scopes an effect. Cursor's allowlist bypass (CVE-2026-22708) is what the first looks like when it fails.

13.4 The two inputs

The rule, stated once: autonomy ceiling = f(harnessability, blast radius). Never enthusiasm, never seniority of the requester, never how well the last task went.

Harnessability is Chapter 8's definition: variety reduction already banked. How much of the work of constraining this codebase has already been done? It is an inherited asset with a balance, and it determines how much of the verification you can mechanise.

Blast radius is the scope of harm reachable from a change. Chapter 11 sharpened it: what an attacker can reach through the agent is what the agent can reach, so blast radius is a security quantity and a reliability quantity simultaneously.

The asymmetry between them matters, and it explains why the rule multiplies rather than adds. Harnessability determines how likely you are to catch a bad change. Blast radius determines what it costs if you do not. Risk is the product, and Taleb's objection to reasoning about probability alone applies with force here: in the presence of a large enough blast radius, a small failure probability is not reassuring, because the expected loss is dominated by a term you cannot estimate. Chapter 11 §11.7 made the same argument about benchmarks — you cannot sample your way to tail safety.

Hence the practical rule that follows: blast radius vetoes. A high-blast-radius change does not become eligible for high autonomy because your harness is excellent. It becomes eligible for high autonomy when the blast radius has been reduced — by feature flags, by reversibility, by removing the credential, by splitting the change.

13.5 The instrument

An honest word first. What follows is an instrument for structuring a decision, not a measurement. The dimensions are real and the weights are judgment. Its value is that it forces a team to say out loud what it currently assumes silently, and it produces an artefact someone can be accountable for — which is the whole point of §13.1.

Harnessability: score each 0, 1, or 2.

Score 0–12. Bands: 0–4 low · 5–8 medium · 9–12 high.

Two things about this table are deliberate. H2 and H4 are the two questions most organisations will score 0 on, and they are the two that matter most — H2 because it is the only defence against Chapter 8's consistency-not-correctness problem, and H4 because Chapter 7's evidence puts hook adoption at 0.9%–3.2%, meaning most teams have no blocking sensors at all. And H6 exists because a control nobody has drilled is Böckeler's silent sensor: indistinguishable from an absent one.

Blast radius: score each 0, 1, or 2, then take the maximum, not the sum.

Take the maximum, because blast radius does not average. A change that is perfectly reversible and touches nothing except that it can reach a long-lived production credential is a high-blast-radius change. Averaging would hide exactly the term that dominates the loss.

The ceiling:

That last observation is the instrument's main payoff, and it is not the one people expect. Running a uniform A2 policy is both too permissive and too conservative at once — over-exposed on the payments path and needlessly expensive on the documentation fix. The gain from scoring is not "we can go faster"; it is reallocation of a scarce resource, which is Chapter 3's constraint managed deliberately.

13.6 The ceiling is currently closed

Chapter 8 left this chapter a constraint I am obliged to honour rather than write around.

The behaviour harness — the apparatus that verifies the software does what was actually wanted — is unsolved. Böckeler's assessment: current practice pairs functional specifications with AI-generated test suites, which "puts a lot of faith into the AI-generated tests, that's not good enough yet", and "we still have a lot to do to figure out good harnesses for functional behaviour that increase our confidence enough to reduce supervision and manual testing" [D].

Read the last clause again. To reduce supervision. Reducing supervision is exactly what climbing this ladder means. So:

What follows is uncomfortable and I think correct: A3 and A4 are, today, reachable only by two routes, and neither is "our harness is good."

Route one: blast radius near zero. If being wrong costs almost nothing and is trivially reversible, you do not need to verify behaviour before the fact. You can discover the error afterwards, cheaply. This is the left-hand column of Figure 13.2, and it is legitimate.

Route two: mechanically complete acceptance. For a narrow class of work, behaviour can be verified deterministically — a pure refactor checked against a strong existing test suite, a mechanical migration with an equivalence check, a dependency bump verified by the build. Here the acceptance criteria are complete because the requirement is "behave exactly as before", which is machine-checkable in a way that "handle refunds correctly" is not.

Everything else — the ordinary business of building features against under-specified intent — has an honest ceiling of A2. Not because agents are incapable; Chapter 3's enterprise case doubled throughput at essentially A2. Because the control that would license A3 does not exist yet.

And this is where the market and the evidence diverge sharply. Tooling is sold on the promise of autonomous agents that complete work while you sleep. For near-zero-blast-radius and mechanically-verifiable work, that promise is real today. For feature work against stated intent, it is a promise about a control nobody has built. Chapter 21 will name the organisational version of believing it anyway.

13.7 What A4 is available for today

The good news, and it is better than it first appears.

Route one and route two above are not marginal. Sort the work in a typical repository by blast radius and mechanical verifiability, and a substantial band qualifies:

• Dependency updates verified by the build and test suite
• Dead-code removal, verified by reference analysis (Chapter 9's graph makes this safe)
• Formatting, linting, and mechanical style conformance
• Test-coverage backfill for existing behaviour
• Documentation regenerated from code
• Mechanical migrations with equivalence checks
• Drift detection and reporting — and this is the interesting one

Look at that list against Chapter 4 and Chapter 12 and something clicks.

Chapter 4 argued that delegation removed a homeostat — the feeling-driven correction that kept complexity bounded — and that the remedy is a sensor with a standing mandate, which nothing triggers and which therefore belongs to nobody's task list. Chapter 12 §12.7 then argued that the outer loop's sensing half must run at machine speed, because a monthly retrospective cannot regulate a machine-paced inner loop.

Both of those requirements describe an agent running unprompted on near-zero-blast-radius work with mechanically checkable success criteria. Which is to say:

A4 is available today for precisely the work the outer loop needs done. The janitorial band that qualifies for full autonomy is the same band that Chapter 12 said must be mechanised. OpenAI's reported "garbage collection" scans and Thoughtworks' "janitor army" are A4 deployments, and they are the highest-value use of the top of this ladder currently available [D].

This is not a consolation prize. It resolves a genuine organisational problem: the outer loop's work has no owner because nothing triggers it and it never competes successfully for human attention against feature delivery. Staffing it with A4 agents is the only realistic answer, and the blast radius is low enough that the ladder permits it.

13.8 The barbell, and where it fails

Taleb's barbell strategy is the recommendation to avoid medium risk entirely: hold most of your position in maximum safety and a small remainder in maximally convex bets, rather than spreading everything across a middle whose downside you cannot estimate. In fat-tailed domains it dominates naive diversification.

The temptation is to transfer it directly — put the critical decile at A0/A1, the throwaway band at A4, and avoid the mushy A2 middle. I flagged this early in the book's development as an original contribution, and testing it properly shows the transfer is partial. It is worth being precise about which half survives.

What transfers. The objection to uniformity. A single organisational autonomy level is exactly the naive-diversification error: it spreads the same medium exposure across work whose blast radii differ by orders of magnitude. And both extremes are correct where they apply — the critical decile belongs at maximum protection regardless of convenience, and the throwaway band belongs at maximum autonomy because its downside is capped by construction and its upside includes both throughput and the outer-loop work of §13.7.

What does not transfer. The claim that the middle is worthless. In Taleb's setting, medium-risk positions carry unbounded downside without proportional upside, so avoiding them is free. That is not true here: A2 is where the work is, and Chapter 3's enterprise case measured 2.09× per-capita throughput at essentially A2 [B]. The middle has real, large, measured upside.

So the honest diagnosis of A2 is different from the barbell's, and sharper:

A2 is not the riskiest level. It is the level whose risk is most misestimated, because its safety rests entirely on the gate Chapter 5 showed had collapsed. A2 says "the human reviews the diff." Chapter 5 showed that a diff's existence no longer evidences care, and Chapter 3 measured reviewers absorbing double the load while batch sizes grew by roughly a third. Everyone believes review is happening.

Which yields a prescription the barbell would not have produced: do not avoid A2 — re-found it. A2's safety must rest on controls rather than on the assumption of genuine review. Concretely, a re-founded A2 has H2 and H4 from §13.5 scored at 2: a held-out acceptance set the agent cannot see, and blocking sensors inside the edit cycle. Then "the human reviews the diff" becomes review by exception on the judgment residue, which is Chapter 12's Verify phase as written and a thing a human can actually do at volume.

13.9 Autonomy creep, and the artefact that stops it

Chapter 21 catalogues Autonomy Creep — permission scope expanding by convenience rather than by decision. The mechanism is worth stating here because the remedy belongs to this chapter.

Creep does not happen in one step. It happens because each individual expansion is small, plausible, and made under delivery pressure by whoever is blocked. This one time, let it merge without the integration suite — the pipeline is slow and the change is trivial. Nobody decides to move from A2 to A3. The boundary is simply never enforced, and after enough exceptions the exception is the configuration.

Two defences, both consequences of earlier chapters.

Enforce by capability (§13.3). An expansion that requires granting a permission is an event with a record. An expansion that requires only ignoring an instruction leaves no trace. This is the whole argument for Figure 13.1's revocation column, and it converts creep from a cultural drift into an auditable change.

Make the level a policy artefact with an owner and a review date. Chapter 11 §11.9 argued accountability follows the autonomy decision; that requires the decision to exist as a document. Appendix C provides the template; the minimum content is: the class of work, the level, the harnessability and blast-radius scores that justified it, the named owner, the review date, and the conditions that would force a downgrade.

That last field is the one everyone omits and the one that matters. A level granted with no stated conditions for revocation will never be revoked, because after an incident the conversation is about the incident rather than about whether the grant was sound. Write the downgrade trigger while you are calm.

And drills apply here too, exactly as Chapter 8 prescribed. The question "is this agent actually operating at the level we think?" is answerable only by attempting to exceed it. Ask an A2 agent to merge. If it can, it is not at A2, whatever the policy says.

13.10 What this hands to Chapter 14

The ladder produces three quantities that a lifecycle needs and that nobody currently measures.

Autonomy mix — the distribution of merged work across A0–A4. Chapter 14 makes this a first-class metric, because it is the only number that shows whether delegation is actually happening or whether an organisation has bought agents and kept its old process.

Harnessability scores over time — §13.5's instrument, re-run. Rising harnessability is the leading indicator that the ceiling is lifting; it moves before throughput does.

Ceiling violations — work that ran above its ceiling. This is Chapter 12's fifth prohibition made countable, and it is the closest thing to a safety metric this book offers.

Chapter 14 also inherits the harder problem this chapter has exposed. Everything above depends on knowing the blast radius of a change before it is made, which is a classification problem nobody has automated. Today the scoring is a conversation. It should be a query against Chapter 9's graph — does this change path reach a credential, mutate production data, or cross a bounded context? — and that is a buildable thing that does not exist.