How Much Autonomy Should an AI Agent Have?

One of the most important questions about AI agents is often asked too late.

People ask:

“Can the AI do this?”

Can it send the email?

Can it update the database?

Can it change the configuration?

Can it schedule the meeting?

Can it purchase the item?

Can it deploy the code?

Can it respond to the customer?

Increasingly, the technical answer may be yes.

But that is not the same question as:

Should we allow it to do those things without asking us first?

Capability and authority are different.

An AI agent may be capable of performing an action that it should not be authorized to perform autonomously.

That distinction is at the center of responsible AI orchestration.

The right amount of autonomy is not the maximum amount the AI can handle. It is the amount the task actually requires and the risk can responsibly support.

Autonomy Is Not All or Nothing

We sometimes talk about AI agents as though there are only two possibilities.

Either:

The human does the work.

Or:

The AI does the work autonomously.

Real systems do not have to operate that way.

There are many useful stages between those extremes.

An AI system may:

• read information;
• analyze it;
• draft something;
• recommend an action;
• prepare the action;
• wait for approval;
• execute after approval;
• or execute certain predefined actions without asking.

Each step grants the system more authority.

And each step deserves a different governance decision.

Current industry frameworks are increasingly recognizing this.

Gartner's 2026 model, for example, distinguishes agents that observe, advise, act with human approval, and act autonomously within defined guardrails.

That is a useful way to think.

Not every agent needs the same freedom.

Start With the Least Authority Necessary

There is an established security idea that applies very well to AI:

Do not grant more access than necessary.

If an agent only needs to summarize a report, why should it have permission to edit the report?

If it only needs to draft an email, why should it be able to send the email?

If it only needs to analyze server status, why should it be able to restart the server?

If it only needs to compare prices, why should it have purchasing authority?

AI capability can tempt us to collapse several different permissions into one.

The agent can research.

Therefore let it recommend.

It can recommend.

Therefore let it execute.

It can execute successfully most of the time.

Therefore let it act autonomously.

That progression should not be automatic.

Every expansion of authority should have a reason.

Think in Terms of an Autonomy Ladder

A practical way to design AI-assisted work is to think of autonomy as a ladder.

Level 1: Read

The AI can access only the information needed for the task.

It cannot change anything.

Examples:

• reading documentation;
• retrieving records;
• examining logs;
• reviewing a calendar;
• searching an approved knowledge base.

The primary risks are inappropriate data access and incorrect interpretation.

Even this level needs boundaries.

Read-only does not mean risk-free.

Level 2: Analyze

Now the AI interprets what it reads.

It may:

• summarize;
• compare;
• classify;
• identify patterns;
• detect anomalies;
• or explain findings.

The system still does not change anything.

This is often a good place to begin because the AI can create significant value while humans retain execution authority.

But humans still need to remember that analysis can influence decisions.

A recommendation can be wrong even if it never directly modifies a system.

Level 3: Draft

At this level, the agent prepares something a human might eventually use.

It may draft:

• an email;
• a report;
• code;
• a support response;
• a configuration;
• a contract section;
• a purchase request;
• or a project plan.

The human reviews the work before it goes anywhere.

This is where many useful AI workflows should remain.

The system saves labor.

The human retains final control.

Level 4: Recommend

Now the AI is not merely preparing language.

It is recommending what should happen.

For example:

Restart this service.

Reject this transaction.

Approve this refund.

Escalate this customer.

Choose this vendor.

Apply this configuration.

The AI is still not acting.

But its influence has increased.

Recommendation systems deserve stronger scrutiny because humans can begin treating repeated machine recommendations as defaults.

The fact that a person still clicks a button does not guarantee independent judgment.

Level 5: Prepare the Action

Here the agent gets very close to execution.

It may:

• assemble the exact API request;
• prepare the database update;
• construct the deployment;
• populate the message recipients;
• configure the refund;
• stage the file changes;
• or build the transaction.

But it stops.

A human sees the intended action and decides whether to authorize it.

This can be a powerful model because AI performs almost all of the mechanical work while preserving a meaningful approval boundary.

Level 6: Act With Approval

Now the system may execute.

But only after explicit human authorization.

This is appropriate when:

• actions have meaningful consequences;
• mistakes would be expensive;
• decisions require judgment;
• the task involves people;
• the activity involves confidential information;
• money is being moved;
• production systems are changing;
• or the action is difficult to reverse.

The important word is not approval.

It is meaningful approval.

The human needs enough information, time, knowledge, and authority for the checkpoint to be real.

Otherwise approval becomes ceremony.

Level 7: Act Autonomously Within Limits

There are cases where asking a human every time defeats the purpose of automation.

An agent may need permission to act autonomously.

That can be appropriate.

But autonomy should have boundaries.

For example:

An agent might automatically reschedule a low-priority internal meeting within defined hours.

It might restart a noncritical service after a known health-check condition.

It might categorize routine support tickets.

It might reorder inexpensive inventory below a defined threshold.

It might archive information according to an established retention rule.

It might automatically retry a failed, reversible operation.

The important phrase is:

within defined limits.

Autonomy is not unlimited permission.

Consequence Should Determine Autonomy

A simple question helps:

What happens if the AI is wrong?

If the answer is:

“Almost nothing, and we can easily undo it,”

more autonomy may be reasonable.

If the answer is:

“A customer could lose money,”

or:

“Production could go down,”

or:

“Sensitive information could be disclosed,”

or:

“Someone could be denied an important service,”

then the autonomy boundary should be much tighter.

This is why the same AI system might safely act autonomously in one workflow and require approval in another.

The difference is not necessarily intelligence.

The difference is consequence.

Reversibility Matters

Another important factor is whether the action can be undone.

Suppose an AI agent moves a file from one internal folder to another.

If that action can be reversed instantly, the risk may be modest.

Now suppose the agent permanently deletes the file.

The same basic capability creates a different governance problem.

Or compare:

Draft a social-media post

with:

Publish a social-media post.

Or:

Prepare a financial transfer

with:

Send the money.

Or:

Generate a production configuration

with:

Apply the production configuration.

The closer an action gets to being irreversible, the stronger the case for human approval.

Scale Changes the Risk

One small error may be inconvenient.

An automated error repeated ten thousand times can become a crisis.

AI agents operate at machine speed.

That is one of their greatest advantages.

It is also one of their greatest governance challenges.

An autonomous process that works correctly 99 percent of the time may sound excellent.

But if it performs one million actions, the remaining one percent is not small.

Scale changes what reliability means.

That is why autonomous workflows may need:

• thresholds;
• transaction limits;
• rate limits;
• monitoring;
• anomaly detection;
• circuit breakers;
• and automatic escalation.

The goal is not merely to prevent every possible error.

It is to prevent one error pattern from becoming ten thousand errors before a human notices.

Autonomy Should Be Earned

There is another principle I would use:

Do not begin with full autonomy and remove permissions after failures. Begin with bounded authority and expand it when evidence justifies expansion.

That creates a safer progression.

An agent might begin in read-only mode.

Then advisory mode.

Then prepare actions for review.

Then execute low-risk actions with approval.

Then perhaps receive limited autonomy for a narrow class of well-understood actions.

Each stage produces evidence.

How reliable is it?

Where does it fail?

How often do humans reject its recommendations?

What types of exceptions occur?

Are failures detectable?

Can actions be reversed?

Only then should the next level be considered.

Autonomy should be earned through demonstrated reliability and governance maturity.

Do Not Confuse Confidence With Permission

AI systems can express confidence.

They may assign probabilities.

They may say they are certain.

That still does not determine whether they should act.

Suppose an AI system says it is 99 percent confident that a production database should be deleted.

The relevant governance question is not:

“How confident is the model?”

It is:

“Why does this system have autonomous permission to delete a production database?”

Confidence can inform a workflow.

It does not create authority.

Authority comes from the humans and organizations governing the system.

Give the Agent a Defined Identity

As AI systems become capable of acting across tools, identity matters.

NIST's current work on AI-agent authorization recognizes this.

Organizations need to know which entity performed an action.

The system should not simply appear as though the human user did everything.

A well-governed environment should be able to distinguish:

• the human;
• the agent;
• the permissions granted to that agent;
• and the actions taken under those permissions.

That creates traceability.

It also allows permissions to be limited specifically for the agent.

An AI assistant does not necessarily need every permission its human operator possesses.

Often it should have significantly fewer.

Delegation Should Be Specific

If I tell a person:

“You may spend up to $100 on office supplies,”

I have not told them:

“You may spend whatever you want on anything.”

AI delegation should work the same way.

Instead of:

“Manage purchasing.”

define:

• which vendors;
• which item categories;
• which dollar limits;
• which accounts;
• which hours;
• what requires approval;
• and what must be escalated.

Specific delegation creates bounded autonomy.

Broad delegation creates ambiguity.

And ambiguity becomes dangerous when software can act quickly.

Approval Gates Should Follow Consequence

Not every workflow needs approval at every step.

That would make AI agents unnecessarily cumbersome.

The purpose of human approval is not to create more clicking.

The purpose is to preserve meaningful authority at consequential moments.

A good workflow might allow AI to:

read automatically,

analyze automatically,

draft automatically,

and prepare the action automatically.

Then stop before:

sending,

publishing,

spending,

deleting,

deploying,

changing access,

or committing the organization to something consequential.

The exact boundary depends on the work.

That is the point.

Approval should be designed around consequence, not added mechanically everywhere.

Exceptions Matter More Than Normal Cases

Agents often perform well when the situation matches the pattern they were designed for.

The real governance test is:

What happens when the situation does not fit?

A customer request is unusual.

A system returns an unexpected error.

Two policies conflict.

The data is incomplete.

The requested action exceeds a threshold.

The agent encounters something it has never seen.

That is where escalation matters.

A well-designed agent should be able to say, in effect:

“This is outside my authority.”

and stop.

That is not failure.

That is successful governance.

The Most Capable Agent May Need the Strongest Boundaries

This can feel counterintuitive.

If an AI system becomes more capable, shouldn't we trust it with more freedom?

Sometimes.

But increased capability also increases the range of consequences it can create.

A system that can only summarize documents has limited operational power.

A system that can:

• access customer data;
• write code;
• modify infrastructure;
• send messages;
• purchase products;
• and operate other applications

is far more useful.

It is also capable of far more consequential mistakes.

Capability increases potential value.

It can also increase the need for boundaries.

A Seven-Question Autonomy Test

Before giving an AI agent permission to act autonomously, ask:

1. Does the task actually require autonomy?

Do not automate execution merely because it is technically possible.

2. What happens if the agent is wrong?

Evaluate the real-world consequence.

3. Can the action be reversed?

Irreversible actions deserve tighter control.

4. How many times can the agent perform the action?

Scale can turn small errors into large failures.

5. What exact permissions does the agent need?

Grant the minimum necessary authority.

6. When must it escalate to a human?

Exceptions should have predetermined boundaries.

7. Can a human stop it quickly?

Meaningful human authority requires the ability to intervene.

If those questions do not have good answers, the agent probably has too much autonomy.

More Autonomy Is Not Automatically More Advanced

There can be a cultural temptation to view full autonomy as the goal.

The most advanced AI system must be the one requiring the fewest humans.

I do not think that is a useful standard.

The best system is the one that accomplishes its intended work safely, efficiently, and responsibly.

Sometimes that means substantial autonomy.

Sometimes it means the AI drafts something and waits.

Sometimes the smartest architecture is deliberately less autonomous.

A human approval gate is not necessarily evidence that the AI failed.

It may be evidence that the system was designed correctly.

Practical Takeaway

When deciding how much authority to give an AI agent, do not begin by asking:

“How autonomous can we make it?”

Ask:

“How much autonomy does this task actually need?”

Start with the least authority necessary.

Then evaluate:

• consequence;
• reversibility;
• scale;
• reliability;
• permissions;
• monitoring;
• escalation;
• and human control.

Allow AI to read when reading is enough.

Allow it to draft when drafting is enough.

Require approval when consequences justify approval.

Allow bounded autonomy where the work is sufficiently low-risk, reversible, observable, and well understood.

And expand authority only when there is evidence that doing so is responsible.

The goal is not maximum autonomy.

The goal is appropriate autonomy.

AI should have enough authority to perform the work you assigned.

No more than it needs.

No less than makes it useful.

And never so much that human responsibility becomes meaningless.