AI Agent Autonomy Levels: A Working Taxonomy From Suggest to Unattended

Why do teams disagree about autonomy?

Because the word describes six different systems, and the argument is usually about whose example each person has in mind. An agent that drafts a reply and an agent that reorders inventory are both called autonomous. One of them cannot harm anything; the other can commit the company to a purchase.

The disagreement dissolves when the level is named, because a level is a statement with two halves: what the agent may do without a human, and which control has to exist before it may be allowed to. Once those are attached, "is this too autonomous" becomes a question with an answer — the answer is whether the required control for that level is in place.

A level is not a measure of sophistication. It is a permission with a prerequisite, and promoting an agent is a governance decision rather than a model upgrade.

Grading schemes are starting to appear in standards work and platform documentation, which is a sign the problem is real. The taxonomy below is the one I use with clients, organised so that each level is operable — you can tell which one a system is at, and what has to be true to move it.

What are the six levels?

Two things to notice. Levels L2 and L3 are the boundary that matters commercially, because that is where the system starts changing records a business depends on. And L5 is not the natural destination of the ladder: it is a rare, specific case that requires the agent to be unable to promote itself.

What actually changes between levels?

Not the model. The controls, and mostly the ones that are administrative.

Read the L2→L3 column carefully, because it is the promotion teams attempt too early. L2 has a human between the decision and the record; L3 removes that human for a class of cases and replaces them with limits, reversibility and sampling. If any of those three is missing, the promotion did not remove a review step — it removed the control and kept the confidence.

How do you choose the right level for a process?

Three inputs decide it, and none of them is the model's accuracy.

The mapping is unglamorous. Cheap and reversible with review capacity: L2 is often unnecessary and L3 by design, with sampling. Expensive and irreversible: L1 until the evaluation set proves the failure rate, then L2 with a narrow approval rule, and L3 only for the low-value slice of the same action. Expensive and reversible with no review capacity: the honest answer is L1 or L2 with a queue, because L3 would remove the only control available.

The most useful consequence of thinking this way is that the level is per action, not per system. One agent can hold L1 for a customer email, L3 for a stock adjustment below a value threshold, and L1 again for anything touching pricing. That is exactly what the action register records, which is why the register is the first control in any governance framework — the level column belongs next to the blast radius and the owner.

What is the evidence that a level can be promoted?

A promotion is a decision with an artifact, and the artifact is a period of operation rather than an opinion. The version I require before moving one level:

1. Thirty days of run records at the current level, with outcomes in four states — completed, abstained, failed, duplicate — rather than two.
2. A stable confidently-wrong rate, measured over the period and not materially worse than the rate accepted at the previous gate.
3. An evaluation set rerun after any model or prompt change during that period, with the result recorded.
4. The approval queue volume and its wait times, which tell you what the human step actually costs — and therefore what the promotion saves.
5. The cost per completed task at the current level, so the promotion's effect on the unit economics is measurable rather than assumed.
6. A rehearsed rollback, including the kill switch, pulled deliberately in staging rather than described in a document.

Those six are the promotion evidence for L2→L3 and L3→L4; the go-live version, with the artifact each gate requires, is the seven gates an agent clears before it writes to production. What matters here is the principle: promotion is argued from records, not from a successful demonstration.

Where does each promotion go wrong?

Every row is administrative rather than technical, which is the honest summary of autonomy work: the engineering determines what the agent can do, and these controls determine what it is allowed to do without anybody watching.

How do you turn these levels into a working framework?

The levels are the vocabulary; the framework is four things that make the vocabulary enforceable, and it is deliberately small enough that one person can hold it:

1. A register — one row per action an agent may take, carrying its blast radius, its level, and a named owner. Level is a property of the action, not of the system, which is why it belongs in the same table as the blast radius rather than in a design document.
2. Promotion evidence — the thirty days of run records and the evaluation rerun from the section above, kept where the promotion decision can point at them.
3. A decision record per action — the one-line statement naming the level, the limits, the evidence and the person who signed it.
4. A review that re-scores rather than re-decides — ninety minutes a quarter, using the levels to ask what moved and what was never used, rather than reopening the original argument.

Those four are the whole framework, and they are the same five controls as a governance framework seen from the autonomy side: the register, the authorisation, the evidence, the decision and the review. A framework that adds a maturity score to that list has added a number nobody can act on.

If the levels are being applied to a system that already writes to production, the useful first step is not a redesign — it is the comparison in the section above, run on your worst row, because a system operating at L3 with L2 discipline is a finding that takes an afternoon to produce and tends to move budgets.

What goes in the decision record?

One line per action, and the line is the governance artefact:

This agent may <action> at level <L> against <system>,
limited to <unit limits and thresholds>,
evidenced by <run record window, evaluation rerun>,
promoted on <date> by <name>, reviewed <date>.

The clause doing the work is "promoted on … by …". An agent whose autonomy level changed without a date and a name did not get promoted; it drifted, usually one small permission at a time, and the drift is invisible until something it was never supposed to do appears in a record.

Write the levels into the register before the next release, then pick the one action whose blast radius is external and check whether its level matches the controls actually present. That single comparison is where teams discover they are running L3 behaviour at L2 discipline — and it is discovered on a Tuesday afternoon rather than the following month, which is the entire point of naming the levels. If you want the levels applied to one system rather than the general case, send a brief with the action whose blast radius is external — the reply is a written read on which level it is at and which control is missing.