A useful autonomy classification starts with consequences

“How autonomous is the agent?” sounds like a technical question. In practice, it is a governance question with an incomplete premise. An agent that independently rearranges a personal task list and an agent that independently changes customer entitlements may perform a similar number of steps, yet create radically different obligations.

A useful classification starts with what can happen if the system is wrong. It then asks how much authority the system has, whether a person can intervene in time, how reversible the action is and how uncertain the operating environment remains. The result should select controls and evidence—not award the product a futuristic label.

The OECD Framework for the Classification of AI Systems separates context, data, model, task and output characteristics and links them to impacts. That multidimensional approach is more useful than a single autonomy score because the same behaviour can be benign or consequential depending on where it occurs and whom it affects.

Begin with the consequence radius

Describe the most credible effect of a wrong or manipulated action before discussing model capability. Consider five forms of consequence:

1. Information: incorrect, confidential or misleading content reaches someone.
2. Access: permissions, identities or data visibility change.
3. Transaction: money, inventory, bookings or contractual steps change.
4. Decision: a person or organisation is ranked, accepted, rejected or treated differently.
5. Physical or operational state: equipment, infrastructure or a time-sensitive process changes.

For each, estimate scope, duration and recoverability. A wrong draft seen by one trained operator has a smaller radius than a wrong instruction sent to thousands of customers. A reversible sandbox update differs from deleting a production resource. A ten-minute delay differs from a missed clinical escalation.

This is not a demand for precise monetary risk where evidence does not support it. It is a disciplined comparison that prevents “human in the loop” or “read only” from substituting for analysis.

Classify authority at the action level

Do not assign one autonomy level to the whole application. Break the workflow into action classes because the boundaries often differ:

Action class	Example	Governance question
Observe	Read a ticket or retrieve a policy	Which identity and data scope apply?
Interpret	Classify intent or estimate urgency	How will errors affect routing or attention?
Recommend	Propose a response or next step	What evidence and uncertainty reach the decider?
Prepare	Draft a message or stage a transaction	Can a person inspect the material facts before release?
Execute	Send, purchase, change or delete	Which mandate permits the action and what limits it?
Delegate	Create work for another agent or tool	Does authority narrow, persist or expand downstream?

An agent may autonomously observe and interpret, prepare under review, and execute only pre-approved low-value operations. This “authority envelope” is more actionable than calling the entire system semi-autonomous.

Record whose authority the agent uses. A service credential with broad privileges can make a nominally narrow agent operationally powerful. The relevant limit is the intersection of policy, identity, tool capability and runtime enforcement—not the instruction written in a prompt.

Add reversibility and time to intervene

Two actions with similar nominal impact may need different controls because one can be undone. Classify recovery using concrete questions:

• Is the action detectable in time to prevent its effect?
• Can it be cancelled or rolled back without creating another harm?
• Is there an authoritative record of the previous state?
• How long does recovery take, and who can initiate it?
• Does reversal also retract copies, messages or downstream actions?

A person “on the loop” is useful only if monitoring can surface an actionable signal before the consequence becomes irreversible. A queue reviewed the next morning does not oversee an immediate funds transfer. Conversely, a bounded batch action with a tested rollback may safely tolerate less synchronous review than a lower-value but irreversible disclosure.

The NIST AI RMF recommends mapping both likelihood and magnitude of impacts in context and defining human oversight processes. That supports a practical rule: intervention design should follow the consequence window, not a generic preference for more humans.

Distinguish approval from effective oversight

“Human approval required” can describe several different controls:

• a meaningful decision with the right evidence and enough time;
• a confirmation click after the action is already effectively committed;
• a high-volume queue where reviewers cannot investigate;
• a notification that nobody is assigned to monitor;
• a nominal override that does not stop downstream execution.

Classify the oversight mechanism by its control strength. Can the person understand what the system proposes, compare it with relevant source material, identify uncertainty, refuse without penalty and actually prevent or reverse the action?

For high-risk AI systems within its scope, Article 14 of the EU AI Act requires human oversight measures proportionate to risks, autonomy and context, and identifies capabilities such as understanding limitations, remaining alert to automation bias and intervening or stopping a system. Applicability is a legal question for the relevant facts; operationally, the article is a useful reminder that the presence of a person is not the same as an effective control.

Use a multidimensional decision profile

A compact classification can use five dimensions, each recorded with a short rationale:

Dimension	Lower-control condition	Higher-control condition
Consequence	Local, low-impact inconvenience	Rights, safety, money, access or broad external effect
Authority	Advice only	Direct action or delegation across systems
Reversibility	Quickly detected and completely reversible	Delayed detection or irreversible propagation
Intervention	Informed person can stop in time	Human cannot inspect, understand or interrupt
Environment	Stable inputs and bounded users	Open-ended users, untrusted content or changing conditions

Do not simply add the columns into a score and discard the rationale. A single extreme can dominate. For example, irreversible disclosure of sensitive data should not become “medium” because the workflow is otherwise stable.

Translate the profile into an operating class:

• Advisory: produces information for a person; no direct state change.
• Supervised preparation: stages an action; a meaningful approval is required.
• Bounded execution: performs enumerated, reversible actions within enforced limits.
• Conditional execution: acts within a wider domain but stops or escalates on defined conditions.
• Extended delegation: plans or delegates multi-step work across tools or agents, demanding the strongest evidence, containment and monitoring.

These names are organisational tools, not universal standards or legal categories.

Let classification select controls

Each class should lead to a pre-agreed control set. As consequence and authority increase, consider stronger identity binding, narrower permissions, transaction limits, independent policy enforcement, confirmation for irreversible actions, better action traces, scenario testing, runtime anomaly detection, fast suspension and a shorter review interval.

The evidence burden should rise too. An advisory system may need evaluation of accuracy, grounding and disclosure. A bounded executor needs tests of authorisation, side effects, idempotency, recovery and adversarial instructions. Extended delegation adds handoff, accumulated error, authority propagation and long-horizon state.

The OECD AI Principles call for human agency and oversight appropriate to context and for robustness, security and safety across the lifecycle. Classification operationalises that proportionality: it connects context to a specific control and a specific decision owner.

Reclassify when the operating reality changes

Autonomy is not fixed at procurement. Revisit the profile when a new tool is added, a permission expands, review volume rises, users change, retrieval reaches new data, a model behaves differently or an incident reveals a larger consequence radius.

Watch for “autonomy drift”: a draft assistant gains a send button; a recommender’s output becomes the default decision; a supervisor reviews so many cases that approval becomes ceremonial; an agent begins calling another agent whose permissions are broader. None may look like a major model change, yet each changes effective authority.

The classification earns its place only if it can stop such drift from inheriting yesterday’s controls. Put the action classes, consequence rationale, control set, owner and triggers into the system record. Then test the boundaries in the environment where they matter.

The right question is not whether the agent deserves a level-three or level-four label. It is whether the organisation can explain, enforce and review what the system may affect before granting it more room to act.