Autonomy Levels — Patterns

Grade by blast radius, not by tool

Problem. Permissions attached to tool names are too coarse at one end and too fiddly at the other. The same tool sends one message to one person and ten thousand to a mailing list, and a rule naming the tool cannot tell those apart.

Approach. Classify each attempted action by its consequence — reversibility, number of subjects affected, monetary value, whether it is externally visible — and attach the requirement to that classification. Compute the classification from the actual arguments at call time, so the same tool crosses a threshold when its arguments do.

Trade-off. Classification logic becomes security-relevant code that must be maintained per tool, and an action misclassified as low-consequence is permitted without review. Thresholds also need regular revisiting, since a limit set when the product was small becomes meaningless as it grows.

Approve a bounded session, not every action

Problem. Per-action approval produces fatigue and is the main reason oversight decays into reflexive clicking. Blanket approval removes the control. Both failures look like a working process from the outside.

Approach. Let an approver authorise a bounded envelope — these action classes, up to this value, for this period or this task — with the agent acting freely inside it and stopping at its edges. Show the approver what the envelope permits in concrete terms, and report afterwards what was actually done within it.

Trade-off. The envelope is where the risk now lives, and one drawn too generously is a blanket approval wearing a more responsible name. It also demands an after-the-fact report that someone genuinely reads, or the control is only theatre at a lower frequency.

Enforce outside the model, explain inside it

Problem. A permission expressed only in instructions is advisory and survives exactly until someone crafts an input that overrides it. A permission expressed only in enforcement code is invisible to the model, which wastes iterations attempting actions that will be refused and reports confusing failures to the user.

Approach. Hold one machine-readable policy, enforce it at the boundary that issues the credentials, and render a summary of the current envelope into the agent's context so it can plan within its limits and explain them. Refusals returned to the model should name the policy and the reason, so it can take a permitted route rather than retrying.

Trade-off. The rendered summary is a second representation that can drift from the policy if it is not generated from it. Telling the model the boundaries also tells anyone who can read the context, which occasionally reveals more about the control surface than is wise.

Promote on measured evidence, demote automatically

Problem. Autonomy ratchets upward. Levels are raised to resolve an incident or to meet a deadline and nothing ever lowers them, so the permissions in force reflect the most urgent moment the system ever had rather than any deliberate decision.

Approach. Tie each raised level to the evidence that justified it — an approval rate above a threshold, an error rate below one, a review sample passing — and re-evaluate that evidence on a schedule. Grant temporary raises with an explicit expiry, and lower the level automatically when the supporting metric degrades, notifying the owner rather than waiting to be asked.

Trade-off. Automatic demotion can withdraw autonomy during an unrelated metric blip, and a product that silently becomes more cautious confuses users who were relying on it. The supporting metrics must also be good enough to bear this weight, which is a higher standard than most teams initially apply to them.