AI Agent Autonomy Levels: Grant Each Step Only After Evidence

An AI agent autonomy level is the set of actions it may take without a person approving each one first. A sound ladder starts at suggest-only, moves to prepared actions that wait for approval, and only then allows limited action inside a narrow, reversible lane. Each step up should rest on measured reliability on real work, not on a demo or on how capable the underlying model appears.

Key takeaways

• Autonomy is a permission granted per action type, not a property of the model.
• Start every new agent at suggest-only, even when the model looks strong in testing.
• Move up one level at a time, and only after written thresholds are met on real tasks.
• Limit autonomous action to a short list of reversible actions with logging and a rollback path.
• Lower the level quickly after a serious error, then rebuild the evidence before raising it again.

What do the autonomy levels actually control?

Autonomy decides who makes the final call on an action. It has little to do with how clever the agent is, and that distinction matters more as agents become more capable, because capability and reliability on your own work are different measures. A practical ladder for business agents has four levels:

• Level 0, observe: the agent reads approved sources and records what it finds. It sends nothing and changes nothing.
• Level 1, suggest: the agent proposes answers, drafts or next steps. A person decides and performs the action.
• Level 2, prepare: the agent completes the full action in a staging form, such as a drafted reply, a filled record or a queued update, with its sources attached. A person approves each one before it runs.
• Level 3, limited action: the agent carries out a short, fixed list of reversible actions on its own, logs each one, and routes everything else to a person.

Anything beyond level 3 is a separate decision with its own review. It should never be reached by accident through a tool update or a broader permission that was granted for another purpose.

How do you choose the starting level?

Start from consequences, not enthusiasm. Before the agent touches anything, answer three questions: what happens if it is wrong, can the action be reversed, and how quickly would someone notice. Those answers point to a starting level more reliably than a benchmark score or a vendor presentation.

• If an error could reach a customer, a payment, a contract or a regulator, start at level 1 and stay there until the review described below is complete.
• If an action is reversible within a short window and visible internally, level 2 is a reasonable first step.
• If the agent only reads data or writes to a private draft, level 0 or level 1 is enough for the first period.
• Never grant a tool before its level is reached. Access should match the current level, not the level the agent might reach later.

The last point follows the deny-by-default and least-privilege principles in the OWASP authorization guidance. An agent that holds write access in case it is needed later has a larger blast radius than its current role requires. For how to structure those trust tiers, see Superintelligent Agent Authorization: Growing Trust Tiers.

What evidence should move an agent up a level?

Thresholds must be written before the agent starts, not chosen after the results come in. The owner of the process should set the minimum number of reviewed runs, the acceptance rate, the length of the observation window and the rule for serious errors. Those values belong in the agent's definition next to its success criterion, so everyone reads the same test.

Useful evidence usually has six parts:

• A task set drawn from real past work, with expected outcomes agreed by the people who do that work today.
• Repeated runs on that set. Evaluation practice treats agent outputs as variable, so one clean run tells you very little.
• Reviewer acceptance at level 2, measured per task type, with the share of approvals that needed edits recorded.
• Serious errors counted separately from minor ones. A single serious error in the window should stop the upward move.
• Escalation quality: does the agent route the cases it should not handle, including the unusual ones that look routine?
• Stability: results hold after tool changes, model updates or new data sources.

Anthropic's guidance on evals for agents makes a similar point: tasks, graders and repeated trials need to be designed together, or the scores will not mean what you think they mean. For the design of a pilot test, see How to define success criteria for an AI agent pilot and How to evaluate AI agents on real business tasks.

How do you move up one level, step by step?

A promotion should be a small, documented change. The following sequence keeps it that way:

• Record the current evidence in a written log: what the agent did, who reviewed it, and which thresholds were met.
• Define the next level's scope in plain terms: the exact action types, the exact tools and the exact limits.
• Review the permission change with the owner of each system involved, and remove any access the new scope does not need.
• Run the agent in shadow mode at the new scope. It produces the action it would take, that action is compared with what a person actually did, and nothing executes.
• Hold a short decision meeting with the process owner and a reviewer, and decide against the written thresholds rather than against impressions.
• Promote one action type at a time, and keep the rest of the agent's scope where it was.
• Keep monitoring on, and schedule the next recurring evaluation before the promotion goes live.

Illustrative scenario: an operations lead wants an agent to record supplier delivery confirmations in the order system. At level 2, a person approves each entry for an agreed period. Reviewers find that most entries need only a status change, so the team proposes level 3 for that action alone, with a rule that any entry touching quantity or price goes to a person. In shadow mode, the agent records a partial delivery as a complete one, so the team tightens the rule and repeats the shadow run before any live action happens.

That scenario shows why the shadow step matters. The error was caught before it changed a record, and the response was a narrower rule, not a broader trust.

When should an agent lose autonomy?

Downward moves should be fast and upward moves should be slow. Lower the level immediately when one of these happens:

• A serious error reaches a customer, a supplier, a payment or the books.
• The model, a connected tool or a data source changes, and the agent has not been re-evaluated.
• Reviewers start editing more of the agent's work, even when no single failure is visible.
• The agent's logs show actions outside its scope, even when the outcome happened to be correct.
• A permission the agent holds is no longer needed for its current level.

After a step down, do not restore the previous level until the cause is recorded and new evidence has been collected against the same thresholds. Questions of ownership also need answers before an incident is closed, and Who Is Accountable When an AI Agent Makes a Mistake? covers how to assign them. The NIST AI Risk Management Framework treats responding to and recovering from risks as part of managing AI systems. Logs and traces make this possible: the OpenTelemetry observability primer describes telemetry such as logs, metrics and traces as the way to understand what a system did and why. Without that record, a step down is a guess.

How does Be Human handle autonomy levels in practice?

Be Human designs and operates personalized AI infrastructure in which an agent keeps its identity, memory, channels, tools, permissions and operating context under human control. The first engagement defines one useful role, the memory and tools it needs, its approval boundaries and an observable success criterion, and the starting level and promotion thresholds are written into that same definition. Managed operations then carry the work the ladder depends on: monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, with each change promoted one level at a time. Be Human does not promise that any agent will reach a particular level, since that depends on the work, the data and the reviewers involved. If you are unsure which task should start the ladder, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Can an agent skip a level if it performs well in testing? No. Testing shows how the agent behaves on the tasks you chose, not on the full range of cases it will meet in production. Skipping a level removes the review step that would catch the cases your test set missed, so promotions should follow the ladder even when results look strong.

How long should an agent stay at suggest-only? Long enough to produce a reviewed body of work that meets the thresholds agreed in advance, not a fixed calendar period. Simple, low-risk tasks may clear the bar quickly, while tasks with customer or financial consequences usually need more runs and more varied cases. The process owner makes the decision, and the decision is recorded.

Does a higher autonomy level remove the need for human review? No. At level 3, human review moves from each action to sampled actions, exceptions and periodic evaluations. Reviewing less often is a design choice that depends on how reversible the action is and on the monitoring that supports it.

Who decides when an agent moves up a level? The owner of the business process decides, with a reviewer who did not build the agent, and the owner of any system whose permissions change must agree. The decision should be measured against the written thresholds and recorded with its evidence. Someone outside the build team should be able to see why the move was made.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.