Autonomy Is Earned One Decision Class at a Time

An agent taking orders for an IT hardware provider makes about a dozen kinds of decision. It reads the customer's purchase order. It checks the requested configuration against what can actually be built and shipped: the docking station that fits that laptop model, the memory the chassis accepts. It runs the credit check against the customer's limit and open items. It decides whether to split a delivery when the monitors are in stock and the laptops arrive in two weeks. It applies the terms agreed with that customer. A few weeks into validating one against live orders, the head of sales operations asked the question every sponsor eventually asks: the agent is nearly always right, the approvals are slowing the desk down, so when can we switch them off?

The question treats autonomy as a setting on the agent. Some of those decisions had been right on every reviewed case for weeks and could be undone in seconds. Others had been right just as often, but committed the company to something a customer would hold it to. One switch would have treated them the same.

The head of credit control was in the room, and her own job was a better model for this. So is every company that sells on account. Credit control does not decide whether customers in general may buy on credit. It sets a limit per customer, based on payment history, reviews it on a date, and blocks the account automatically when an invoice goes unpaid. Nobody finds that bureaucratic. It is how a business extends trust it can defend. Autonomy for an agent works the same way, and the rest of this piece is the mechanics.

Autonomy belongs to a decision class

A decision class is a kind of decision defined narrowly enough that its cases share both their difficulty and their consequence. "Check a configuration against the build rules" is one class. "Split a delivery" is another. Classes are listed in the process map before the build, and every decision the agent takes is tagged with its class in the case record.

Autonomy is a property of each class, recorded with the date it was granted, the evidence behind it and the person who agreed it. The agent as a whole has no autonomy level. Asking whether the agent can run unsupervised is like asking whether the order desk can accept orders. Which orders?

The ladder has five rungs

1. Suggest. The agent proposes; a person does the work. For new classes, and for decisions where the agent's job is to save reading time.
2. Draft. The agent prepares the change in the target system as a draft; a person reviews and releases it.
3. Act with approval. The agent executes after a person approves a decision card. The approval is a decision, not a rework, which is what makes it faster than a draft.
4. Act and report. The agent executes; a named person reviews a daily report of its actions and can reverse any of them.
5. Act silently. The agent executes and nobody looks, except through sampling and monitoring.

Feng, McDonald and Zhang's "Levels of Autonomy for AI Agents" (Knight First Amendment Institute, July 2025) gives a careful five-level scale defined by the role the user plays, from operator to observer, and assigns a level to an agent. Inside an operation that is one level too high. The same agent needs several rungs at once, and the ladder turns the question of how much autonomy into a decision a business owner can take and defend, class by class.

The rung lives in the architecture, not the prompt

A rung that the agent reads from its instructions is a suggestion. A rung the architecture enforces is a control. So the rung of each class is a configuration record outside the agent, and it decides which tools the agent is offered for that class. On suggest, the agent gets read tools only. On draft, it gets a tool that writes drafts and nothing that releases them. On act with approval, the committing tool demands an approval token that only the decision card can issue, tied to that case and that version of the proposal. Only from act and report upwards is the committing tool callable directly.

Moving a class up the ladder is therefore a change to that record, made through the client's change process, and visible in the history. Nobody can promote a class by editing a prompt, and the agent cannot talk its way up a rung, because the tool it would need is not there.

Promotion needs four kinds of evidence

A class moves up one rung when four conditions hold and the process owner signs off in writing.

• Accuracy on current cases. Measured on recently reviewed cases. Necessary, and the least of the four.
• Bounded consequence. The worst plausible error has a known cost and a known reversal. A class whose errors cannot be reversed, such as goods released on credit and already on a truck, stops at act with approval.
• A detection signal. Something after the fact would catch an error the reviewer no longer sees: a reconciliation, a customer confirmation, a daily report. Without one, promotion simply makes errors invisible.
• An owner. A named person accepts responsibility for the class on its new rung.

The evidence can be gathered automatically. The decision cannot, and the agent never proposes its own promotions.

How many clean cases are enough

"Right on every case for six weeks" sounds conclusive. It is weaker than it sounds. Statisticians have a shortcut for exactly this situation, set out by Hanley and Lippman-Hand in the Journal of the American Medical Association in 1983 under the title "If nothing goes wrong, is everything all right?": when you have seen zero errors in n cases, you can say with 95% confidence only that the true error rate is below about 3 divided by n. Three hundred clean cases rule out an error rate above one in a hundred. They say nothing about one in five hundred.

That turns promotion into arithmetic a process owner can do. Start from the consequence: what one error costs, and how many cases a month the class handles. Decide what error rate the business can carry on that rung. Then the class needs roughly three divided by that rate in clean, current cases before it moves. A class that checks a configuration against the build rules, where an error is caught at picking and costs minutes, can promote after a few hundred. A class that releases orders held on credit may never collect enough cases in a year to justify going past act with approval, and that is the correct answer, not a failure of the agent.

Take the hardware orders. The delivery split class handled about 400 cases a month. A wrong split that slipped through cost a second shipment and a call to the customer's buyer, and the sponsor put the tolerable rate on act and report at one in two hundred. Three divided by one in two hundred is 600 clean, current cases: about six weeks at that volume, if nothing changed in the meantime. The special terms class, orders carrying a payment term or delivery condition agreed with that one customer, handled more cases, but an error there gave a customer a term it would hold the company to for the rest of the agreement year. Its tolerable rate was one in five thousand, which meant 15,000 clean cases, more than two years of volume. The design kept it on act with approval, and nobody argued, because the arithmetic fitted on one page.

Agreement with a reviewer is not accuracy

There is a second trap in the evidence, and it is the one that catches careful teams. On act with approval, the reviewer sees the agent's proposal before deciding. People anchor. A reviewer who approves a proposal that looks reasonable has agreed with it, which is not the same as having reached the same answer independently. Agreement rates on reviewed cases therefore overstate accuracy, most of all on the ambiguous cases that matter.

So before a class is promoted, a small sample of its cases is reviewed blind: the reviewer decides from the evidence alone, without seeing what the agent proposed, and the two answers are compared afterwards. That number, not the approval rate, is the accuracy figure in the promotion record. It usually comes out a little lower. Occasionally it comes out much lower, and that is the class we are glad we did not promote.

Demotion is a rule, not a meeting

A class drops one rung automatically when a confirmed error appears after the reviewer stopped seeing it, when its inputs change shape (a new order format from a large customer, a new product line, a new market), or when its detection signal breaks.

A model upgrade, or a change to the rules, drops every class to act with approval until it re-qualifies. Sponsors like this rule least and value it most. Evidence belongs to the system that earned it. A new model is a new customer with no payment history, however good its references.

Evidence also ages when nothing changes at all. Every rung above draft carries a review date, and a class whose review lapses drops a rung, exactly as a credit limit lapses without a review. Autonomy that nobody has looked at for a year was granted to a business that no longer exists in quite that form.

Promotion starves the evidence

Every promotion removes some of the human review that produced the evidence for it. On act and report, fewer cases are looked at closely; on act silently, only the sample is. The class then keeps its rung on a thinner stream of evidence than the one that earned it, which is backwards. So the sampling rate on the upper rungs is set by arithmetic, not by habit: large enough that a doubling of the error rate would show up within a month. For a low-volume class that can mean sampling a third of its cases, at which point the promotion saves little, and the honest conclusion is to leave it where it was.

A demotion needs people waiting for it

A rule that drops a class a rung is only real if someone can absorb the work that comes back. When the delivery split class drops from act and report to act with approval, 400 cases a month return to a queue. If nobody has the time, the team will quietly resist the demotion, or approve the returned cases without reading them, and the rule becomes theatre. So every promotion records who takes the work back if the class is demoted, and roughly how many hours a week that would cost. Sponsors find this the most useful line in the promotion record, because it is the real price of the autonomy they asked for.

Most classes settle in the middle

In the operations we work in, most classes end up on draft, act with approval, or act and report. Act silently is rare: we reserve it for classes that are reversible and continuously reconciled, such as matching a bank line to an open item, where any mistake surfaces in the next reconciliation run.

That is not timidity. An agent seldom pays for itself by removing the last second of human attention. It pays for itself by doing the reading, checking and preparation so the attention that remains is short and well spent. A class on act with approval, with a good decision card, costs a reviewer seconds per case. Moving it to act silently saves those seconds and removes the one place where someone would notice the world changing.

One thing we decline: a global autonomy switch, even for a pilot, because it ends with the most consequential decisions promoted alongside the easiest.

What to put in place before the sponsor asks

• A list of decision classes, each tagged on every case record.
• A rung per class, held in configuration outside the agent and changed only through change control.
• A tolerable error rate per class, agreed with its owner, and the number of clean cases that follows from it.
• A blind review sample for any class being considered for promotion.
• Automatic demotion on a confirmed late error, a change in inputs, a broken detection signal, a model or rule change, or a lapsed review date.

The sponsor's question, answered

When can we switch off the approvals? For some decisions, now, and here is the evidence. For some, after another few hundred cases. For some, never, and here is the arithmetic. Autonomy granted this way is a credit limit: it grows with a record, and it is cut the day the record stops meaning what it did.