Autonomy Is a Range You Earn

An agent can be excellent at drafting routine dependency updates and still be a poor candidate for running a database migration without review. Calling it “autonomous” hides the difference. The useful question is what this agent may do, on which tasks, under which conditions, before another check is needed.

Autonomy becomes easier to govern when it is treated as a range of permitted work. A team grants that range on evidence, watches whether the evidence continues to hold, and narrows it when the task or operating conditions change. This is a proposed operating discipline, not a certification scheme or a claim that a fixed number of successful runs proves safety.

Start with the task and the consequential action

Separate the work an agent can prepare from the effects it can commit. Reading a repository, drafting a patch, creating a pull request, merging that request, and deploying it carry different consequences. Read-only output can still influence people, so it deserves appropriate review; it simply has a different control boundary from an action that changes a system.

Define the initial permission in operational terms. For an illustrative dependency-update workflow, the agent may prepare updates to an approved set of libraries, run the required checks, and open a pull request. A maintainer decides whether to merge. Changes to data storage, authentication, or deployment configuration are outside that permission.

This is more useful than a general instruction to be careful. The agent, its reviewer, and the enforcement mechanism can all work against a stated boundary.

Earn a wider range on representative work

Review a sample that reflects the tasks the team expects to delegate, including failure cases. Did the agent detect an incompatible change? Did it preserve the intended behavior? Did it stop when a dependency fell outside the approved set? Were its test results relevant to the proposed change?

Record failures that reviewers found, not only tasks the agent reported as successful. Use independent evidence where available: a test with a meaningful assertion, a reproducible defect, or review by someone qualified to assess the result. A second model can contribute, but its agreement is not proof that both models avoided the same mistake.

The amount of evidence required depends on the consequence, the variety of tasks, and how rarely the team needs failures to occur. A run of clean examples does not establish performance on conditions those examples never exercised. There is no universal promotion threshold.

Widen one permission at a time

Suppose the dependency workflow has demonstrated reliable preparation and appropriate escalation. The next step might be allowing it to update an existing pull request after a narrow, machine-checkable correction. That is a specific increase in authority with an observable effect.

It does not automatically justify merging, deploying, or applying the same permission to a different repository. State what has changed in the grant and what remains outside it. This makes the next review about the newly delegated work rather than about the agent's general reputation.

A useful grant records the task class, allowed resources, required checks, prohibited effects, escalation route, and the evidence that justified the decision. A date and an accountable owner make later review possible.

Keep the fallback reachable

A fallback is useful only if it can operate before the consequence outruns it. Restoring a file from version control may be straightforward. Recovering data after a destructive change can require a separate process. An outbound message cannot be made unseen by reverting the code that sent it.

An aviation-style question helps: where can this work return to a controlled state if conditions worsen? For agents, the answer may be a branch awaiting review, a paused queue, a reversible transaction, or a human decision before the action commits.

Check that the reviewer is actually available, the pause mechanism covers the relevant action, and the recovery procedure has been exercised. Human approval adds accountable judgment; it does not reduce the possibility of error to zero.

Revisit the grant when its basis changes

A new model, prompt, tool, repository, or task distribution can change the evidence behind an autonomy decision. So can a repeated failure pattern that individual successful runs conceal. Define when the team will review the permission and what should cause an immediate restriction.

For example, an agent that starts missing dependency compatibility problems may return to preparing patches without updating existing requests. Restore the wider permission only after the failure has been understood and the relevant checks repeated.

This approach is consistent with the contextual risk-management posture of the voluntary NIST AI Risk Management Framework. The specific permission design remains the deploying team's responsibility.

Decision Trace can hold the reasoning and review behind a permission decision. It should not be confused with the runtime mechanism that enforces that permission. Connecting the two gives a team a question it can answer clearly: what work did we authorize, why did we authorize it, and does the current evidence still support that choice?