Autonomy is a spectrum of actions, not a product label

“This is a level-three autonomous agent” sounds precise. Unless the level is tied to specific actions, permissions and intervention points, it is not. One system can autonomously search public information, require approval before drafting a contract clause, and be prohibited from sending the document. A single label averages away the controls that matter.

Autonomy is best understood as delegated room to act. That room varies by operation and by moment: who starts the work, what the system may decide, which resources it may access, how long it may continue, which effects it may create and when a person can intervene.

The release decision should therefore be expressed as an autonomy map, not a product adjective.

Separate action autonomy from intelligence

The OECD’s explanation of AI autonomy defines it as the degree to which a system can learn or act without human involvement following human delegation and automation. This is an important separation. A model may be highly capable at reasoning yet have no authority to change external state. A narrow model may have substantial operational autonomy if it controls a repeatable physical or digital process.

Capability asks, “What can the system work out?” Autonomy asks, “What may the system initiate or execute without another decision?” Consequence asks, “What happens if that action is wrong or abused?” These dimensions interact but should not be collapsed.

For example, a sophisticated research model operating in an isolated read-only environment can have broad reasoning capability with limited external effect. A simple rules-plus-model workflow that automatically cancels customer accounts may have modest intelligence and high consequence. Governance needs to see both.

Map autonomy across six dimensions

A useful classification describes every material action class across six dimensions:

Dimension	Lower delegation	Higher delegation
Initiative	Runs only on an explicit request	Starts from events, schedules or self-generated subgoals
Discretion	Follows a fixed sequence	Chooses tools, order, parameters or strategy
Permission	Reads a narrow, scoped resource	Writes across systems or acts with broad credentials
Reversibility	Produces a draft or disposable result	Creates persistent, costly or irreversible effects
Duration	Completes one bounded step	Continues across hours, sessions or changing conditions
Supervision	Every effect receives informed approval	Work is sampled, monitored or reviewed after execution

NIST’s tool-use taxonomy similarly treats autonomy as one of several useful lenses, alongside function, access pattern, risk, reliability and monitoring. It also distinguishes read-only, constrained-write and write permissions, and trusted from untrusted environments. The implication is clear: “autonomous” is not one property of the model. It emerges from how the runtime connects model decisions to tools and environments.

Earlier OECD and CSET testing of AI classification frameworks also paired autonomy with impact rather than treating autonomy as a complete risk judgement. A usable enterprise scheme should preserve that multidimensional view.

Classify the smallest consequential action

Product-level classification can be too coarse. Start with verbs that create a business effect: read, infer, recommend, create, modify, approve, send, pay, delete, deploy, delegate. Then define the object and boundary.

“Send email” is still too broad. Sending a draft to an internal test inbox, replying to an existing customer ticket and initiating a new message to an external regulator carry different recipients, permissions and consequences. “Modify code” could mean editing a branch in a sandbox or merging to a production repository.

For each action, record:

• the initiating event and requesting principal;
• the resource and allowed operation;
• the parameter, value, volume and time limits;
• the decision the agent may make;
• the approval required, if any;
• the authoritative confirmation of the effect;
• the available reversal or compensation; and
• the condition that stops or escalates the work.

This produces a control inventory that can be implemented and tested. It also reveals asymmetry. An agent may be allowed to create a purchase request autonomously but not approve it; update a calendar but not invite an external attendee; draft code but not change protected branches.

Human oversight must change the action path

A visible “human in the loop” box does not prove effective oversight. The person must receive the right information at the right time and have an enforceable way to stop or alter the effect.

Test an approval gate with five questions:

1. Does it identify the exact target, parameters and consequence being approved?
2. Does the approver see the evidence and uncertainty behind the proposal?
3. Can the agent revise the plan after approval without seeking approval again?
4. Does the execution layer verify the approval, or only the model’s statement that approval occurred?
5. Is refusal operationally safe, or does workload pressure make approval routine?

The UK National Cyber Security Centre’s agentic AI guidance emphasizes maintaining visibility and meaningful human oversight and control. “Meaningful” is the key operational word. Oversight that cannot affect execution is observation, not control.

Autonomy can rise through configuration drift

Teams often focus on model upgrades while overlooking quieter changes that expand delegation. Connecting a new tool, increasing an OAuth scope, allowing background triggers, lengthening the step budget, adding persistent memory or removing a confirmation dialog can all raise practical autonomy.

That means autonomy classification belongs in change management. A deployment record should compare the proposed and current action maps. Trigger a renewed review when any change:

• adds a write-capable tool or untrusted input source;
• widens a credential, data domain, recipient group or spending limit;
• permits the agent to create sub-agents or delegate work;
• changes approval timing or the evidence shown to approvers;
• extends runtime duration, retries or unattended execution; or
• makes an effect harder to reverse or detect.

The model version belongs in the manifest, but it is only one dependency. An unchanged model with a new production credential is a materially different system.

Use consequence to set control depth

An autonomy map describes delegation; it does not decide whether the delegation is acceptable. Combine it with a consequence assessment: affected people, financial exposure, security impact, legal significance, recoverability, scale and time to detect.

The same action may warrant different controls in different settings. Automatically rescheduling an internal meeting is not equivalent to rescheduling clinical care. Reading public product documentation is not equivalent to retrieving employee records. The action grammar may match while the risk tolerance does not.

The NIST AI RMF Core calls for documented risk tolerances, ongoing monitoring, testing in conditions similar to deployment and post-deployment plans for appeal, override, incident response, recovery and change management. The autonomy map makes those expectations concrete: the higher the consequence and delegation, the stronger the preventive control, verification and recovery evidence should be.

Make a release decision action by action

For each consequential action, choose one disposition:

• Prohibited: the agent cannot request or execute it.
• Recommend only: the agent may analyse and propose; a person performs the operation independently.
• Approve before execution: the agent prepares a specific action that an authorised person approves.
• Constrained execution: the agent acts within enforced limits, with verification and monitoring.
• Supervised autonomy: the agent operates across a bounded workflow, with tested stop conditions and accountable operational review.

These are design choices, not a universal maturity sequence. An organisation may intentionally keep irreversible actions at “recommend only” while allowing high-volume, reversible actions to run under constraints.

The result is more honest than calling the product autonomous or non-autonomous. It tells an executive what has actually been delegated, an engineer where controls must sit, an evaluator what to test and an operator when to intervene.

Autonomy is not the personality of a product. It is the sum of permissions and decisions attached to particular actions. Describe those actions precisely, and the label becomes unnecessary.