AI Agent Autonomy Levels: How Much the Person Lets the Agent Decide
Autonomy levels describe how much an agent decides without asking permission. The five levels from the Feng, McDonald and Zhang paper and how to choose one.
Where does the scale come from?
The paper “Levels of Autonomy for AI Agents,” by Kevin Feng, David W. McDonald and Amy X. Zhang, was posted to arXiv in June 2025 and revised in July. The Knight First Amendment Institute published it as part of its “AI and Democratic Freedoms” essay series. Its contribution is not technical: it proposes a way to talk about autonomy that does not depend on the model, but on the relationship between the person and the agent.
That choice has a useful consequence for design. If autonomy is defined by the user’s role, you can design for each role instead of asking only “how ready is the model?”
What are the five levels?
From least to most agent autonomy:
| Level | The person’s role | What the agent does |
|---|---|---|
| Operator | Directs and decides | The agent helps on demand, when the person asks |
| Collaborator | Collaborates | Plans, delegates and executes alongside the person, with frequent communication |
| Consultant | Guides | Leads most tasks; the person provides preferences and asks for changes indirectly |
| Approver | Approves | Works alone and asks for intervention when blocked, when it needs a credential it lacks, or before a consequential action |
| Observer | Supervises | Plans and executes everything; the person only sees the activity logs and can switch it off, without changing its course |
The paper describes the Operator level as one where the person is in charge at all times and the agent supports on demand. Observer is the most autonomous: the person can see activity logs but cannot change the agent’s trajectory; the only control is an emergency off switch that stops all activity.
What changes in the design of each level?
- Operator and Collaborator: the interface is for response and conversation. What matters is how clear the agent’s actions are and how easy they are to correct.
- Consultant: the person gives preferences, not orders. The interface needs a way to express criteria that the agent remembers, and to see how they were applied.
- Approver: the decision point is the center of the experience. Each approval must show what changes, what it affects and what can be undone. That pattern is covered in action approval.
- Observer: the design is about supervision. What matters is the activity log, alerts and the stop button.
A frequent design mistake is putting Observer-style interfaces in products that are still at the Operator level. The person receives results they do not understand and cannot correct.
How do you choose a level?
Choose by the cost of getting it wrong, not by the confidence a demo gives:
- Decide first whether you need an agent. If an assistant or a copilot is enough, the autonomy question does not even apply.
- Classify each action by risk. Reading a file and deleting a folder are not the same case.
- Assign approval to irreversible actions. Anything that cannot be undone needs a person before it runs.
- Measure the errors. A higher level is only justified if the agent makes few mistakes on that task and the mistakes are caught in time.
- Review per task. The same agent can operate in Approver mode for publishing and in Observer mode for reviewing contrast.
Anthropic recommends starting with the simplest solution and adding autonomy only when it improves the result. That applies here too. The person’s role at those control points is explored in human-in-the-loop design.
When is it NOT a good idea to raise the level?
- When you cannot see what the agent did. Without logs, autonomy is blind.
- When the task affects third parties, such as customers or patients, and there is no review point.
- When the team does not know how to stop the agent. Before raising the level, test the stop button.
Example
Illustrative example: a design team uses an agent to maintain its component library. At first it runs at Approver: the agent proposes each change and a person approves it. After two months, the team checks that the agent gets color token changes right but makes mistakes on spacing. It raises color changes to Consultant, with written rules, and keeps approval for everything else. The level is not one setting for the whole tool: it is adjusted by type of task.
Which numbers help decide?
Before you raise a level, measure three things per task: how many actions the agent proposes that the person rejects, how many times a result had to be corrected after it was applied, and how long it took the person to detect an error. If rejection is high, the agent is not ready for more autonomy. If errors are caught late, the level of supervision is too low for that risk. The numbers do not replace judgment, but they give the team a concrete basis for discussing the level.
Common mistakes
- Choosing the level based on the impression from a demo rather than the cost of errors.
- Raising the level without activity logs.
- Thinking autonomy is binary. In practice it is combined per task.
- Designing approval as an automatic click that nobody reads.
- Forgetting the level can come back down when the agent fails.