Autonomy Is Priced in Reversibility

Nobody in your organization formally decided to increase the authority of its AI agents.

It may be happening anyway.

Anthropic’s study of agent use in practice found that, between late September 2025 and early January 2026, the longest Claude Code turns became substantially longer. At the 99.9th percentile, the time agents worked between human interventions rose from under 25 minutes to more than 45 minutes. Over the same period, human interventions per session declined.

The study also found that approximately 20% of new users enabled full auto-approval. Among experienced users, the figure exceeded 40%.

These measurements do not prove that agents as a whole “doubled in autonomy.” They reveal something more useful: the autonomy agents exercise in practice can expand through accumulated product and user decisions, without a corresponding organizational decision.

Trust grows with familiarity. A user approves the same action repeatedly, sees it succeed, and eventually clicks “always allow.” The next time, the agent proceeds without interruption. Nothing dramatic happens. No policy is amended. No executive signs a delegation of authority.

But the operating boundary has changed.

A personal setting can create an organizational risk

Auto-approve feels like a productivity preference.

In a local development environment, it often is. The user owns the work, the consequences are limited, and mistakes are usually easy to contain.

That changes when an agent can affect shared infrastructure, production data, customer-facing services, security controls, or cloud resources paid for and relied upon by the organization.

At that point, auto-approve is no longer merely a user-interface setting. It is a decision about delegated authority.

The person clicking the button may not own the affected system. They may not carry the financial consequences of an outage, answer to customers, manage the incident, or explain the control failure to an auditor.

Yet one click can determine how much authority an automated system exercises on everyone else’s behalf.

Organizations already understand this problem in other domains. An employee cannot increase their own purchasing authority simply because previous purchases went well. Familiarity with a process does not expand signing authority. Delegation is explicit because the consequences belong to the organization, not only to the person acting.

Production automation should follow the same principle.

Trust is not authorization

A user may have good reasons to trust an agent.

The agent may have completed hundreds of tasks correctly. The model may have improved. The user may understand its behavior and know how to guide it effectively.

None of that answers the organizational question.

Authorization is not a prediction that the agent will probably be right. It is a decision about what the organization is prepared to let happen when the agent is wrong.

That distinction matters because confidence and consequence do not move together. Familiarity can increase quickly; the recoverability of a production system does not improve merely because its operator has become comfortable with the tool.

An agent can be highly reliable and still propose one consequential action. A user can be highly experienced and still overlook one dependency. A familiar workflow can still reach an unfamiliar system state.

The relevant boundary is therefore not simply:

How much do we trust this agent?

It is:

What consequences has the organization explicitly authorized this agent to create?

Those are different questions. Only the second can support accountable production use.

Autonomy does not belong to the agent

Organizations often talk about an agent as though it has one level of autonomy: supervised, semi-autonomous, or fully autonomous.

In reality, the consequences come from individual actions.

The same agent may inspect logs, summarize an incident, recommend a configuration change, modify a shared resource, or delete production data. Treating all of those actions as equivalent because they came from the same agent hides the distinction that matters most.

Some actions have little lasting effect. Others can be recovered from quickly. Some require preparation before they can be reversed. A small number can create consequences that are difficult or impossible to undo.

The authority granted should reflect those differences.

This does not mean placing a human approval step in front of everything. Excessive approval creates its own failure mode: when people are asked to approve hundreds of routine actions, approval stops being judgment and becomes repetition.

The objective is not maximum friction. It is deliberate authority.

Routine, low-consequence work should remain fast. Human attention should be preserved for decisions whose impact justifies it. And the organization—not an accumulated collection of personal settings—should determine where that boundary sits.

Effective autonomy can drift

Organizations usually imagine changes in autonomy as deliberate events: a policy is reviewed, a pilot succeeds, and a wider deployment is approved.

In practice, autonomy can grow through small decisions:

• A user stops reviewing familiar commands closely.

• Repeated approvals become automatic.

• A local development setting is carried into a shared environment.

• Temporary elevated access remains available.

• A successful experiment becomes an unofficial production workflow.

No single step feels like a major expansion of authority. Together, they can produce one.

This is autonomy drift: the gap between the authority an organization believes it has granted and the authority its agents actually exercise.

The danger is not only that an agent might make a mistake. It is that, after the mistake, nobody can identify when the relevant authority was granted, who accepted the consequences, or whether that person was entitled to make the decision.

A setting exists. A record of accountable delegation does not.

Expanding autonomy is itself a consequential change

If a class of actions moves from reviewed to automatic, the organization’s risk has changed—even if no application code or infrastructure configuration changed at that moment.

That boundary change deserves to be treated as a real production decision.

Who owns it? What systems does it affect? What happens if the agent is wrong? Has the organization accepted that outcome? When should the decision be reviewed again?

The answers do not need to create a bureaucracy around every agent interaction. But they do need to exist outside the memory of the person who clicked the setting.

Otherwise, autonomy is not being governed. It is accumulating.

The real question behind auto-approve

Auto-approve is useful. In the right context, it removes unnecessary interruption and allows agents to deliver the speed they promise.

The problem is not the feature. It is the assumption that enabling it is always a personal choice.

Once an agent can act on shared or production systems, the decision belongs to the organization because the consequences do too.

The question is not simply whether you trust the agent.

It is whether you have the authority to make everyone else absorb the consequences when it is wrong—and whether the organization has explicitly agreed to do so.

If nobody can identify who granted that authority, where the decision is recorded, or what limits apply, then the organization does not have an autonomy policy.

It has an auto-approve setting.

Aokumo helps enterprises govern AI agents operating cloud infrastructure, so production automation can expand without organizational control quietly shrinking.

Sources: Anthropic, “Measuring AI Agent Autonomy in Practice” · Feng, McDonald & Zhang, “Levels of Autonomy for AI Agents”