How it works
An autonomy level is an operating policy for a specific scope of work. It answers where an agent may proceed alone, where it must stop, and what evidence it must produce along the way. The level should attach to an action or workflow, not to the agent as a whole. The same agent might inspect logs autonomously, propose a configuration change with review, and require explicit approval before deploying it.
A useful policy resolves four decisions:
- Observe: Can the agent read state, gather evidence, and form a recommendation?
- Prepare: Can it create plans, patches, drafts, or tool arguments without changing authoritative state?
- Execute: Which changes can it apply, within what permission scope and execution limits?
- Escalate or recover: Which conditions require approval, interruption, rollback, or a compensating action?
The harness enforces these decisions at control boundaries such as tool calls, state transitions, credential issuance, and external writes. It also records enough context to explain which policy allowed each action. Higher autonomy therefore means fewer required interventions inside a defined boundary. It should not mean broader permissions, missing checkpoints, or unlimited execution.
Autonomy can change during a run, but only through an explicit policy decision. For example, repeated verifier failures can reduce an agent from execution to proposal-only mode. A passing evaluation may justify expansion later, outside the active run.
Why it matters in an agent harness
Without an explicit autonomy level, intervention tends to become accidental. Some workflows pause for harmless reads while others perform consequential writes because a tool happened to be available. Operators cannot tell whether the system is conservative by design or merely inconsistent.
A defined level makes delegated authority legible. The operator can see which decisions remain human, which decisions have been encoded into deterministic checks, and which judgments are intentionally delegated to the model. That distinction matters because model confidence is not authorization. A plausible action can still exceed the workflow's control contract.
Autonomy levels also shape failure containment. A proposal-only agent can generate a bad patch without changing production state. An execution-capable agent needs narrower credentials, stronger preconditions, bounded retries, idempotency where possible, and a recovery contract for partial completion. The higher the permitted level, the more important it becomes to distinguish a confirmed failure from an unknown outcome. Retrying an unconfirmed external write can duplicate the effect.
Observability must rise with autonomy. An agent that acts without immediate review needs an execution trace showing its inputs, selected tools, policy decisions, state changes, and stop conditions. The trace is not a substitute for control, but it lets operators evaluate whether the control policy worked and reconstruct what happened when it did not.
The level should also reflect reversibility. Low-blast-radius, reversible actions can often run with less intervention than irreversible or externally visible actions. Deleting data, publishing content, spending money, rotating credentials, and communicating as the operator deserve separate boundaries even when they occur inside an otherwise autonomous workflow.
Finally, autonomy is an evaluation claim. Granting more latitude asserts that the harness can keep behavior within acceptable bounds. That claim should be tested against realistic failures, including malformed inputs, unavailable tools, stale state, repeated actions, permission denials, and interruption during a write.
Autonomy level vs permission scope
Autonomy level and permission scope constrain different parts of execution. They should be designed together, but one cannot stand in for the other.
| Control | Question it answers | Example |
|---|---|---|
| Autonomy level | When may the agent proceed without intervention? | Apply a verified patch without approval, but stop before deployment. |
| Permission scope | What resources and operations can the agent access? | Write only to a named repository branch and read only the required logs. |
An agent can have broad read permissions but a low autonomy level that requires approval before acting on its findings. It can also have a high autonomy level inside a very narrow permission scope, such as autonomously updating generated files in one workspace.
Confusing the controls creates two common errors. Broad permissions are treated as permission to act, or frequent approval gates are treated as protection against excessive access. The first enables unintended execution. The second leaves dangerous credentials exposed even when the current workflow appears supervised.
The Rifty take
We treat autonomy as a scoped policy decision, not a personality trait or maturity label for an agent. We optimize for the highest level that remains observable, interruptible, and recoverable inside a narrow control boundary. If an action cannot be bounded or its outcome cannot be established, we accept the intervention cost.
Implementation checks
- Define the level per action or workflow rather than assigning one global level to an agent.
- Separate observation, preparation, execution, and external publication permissions.
- Put approval checks at state-changing boundaries, not only at the beginning of a run.
- Record which policy, identity, and evidence authorized every consequential action.
- Pair higher autonomy with narrower credentials, explicit execution limits, and tested stop conditions.
- Specify what happens after interruption, partial completion, verifier failure, or an unknown outcome.
- Test whether retries are safe before allowing the harness to repeat a state-changing call.
- Reduce autonomy when required evidence, provider readiness, or authoritative workflow state is missing.
- Review autonomy separately from permission scope so that supervision does not conceal excessive access.
- Re-evaluate the level after tool, workflow, model, or recovery behavior changes.
Frequently asked questions
Should an autonomy level apply to an entire agent?
Usually no. Assign autonomy at the action or workflow boundary because consequences vary within one run. An agent may inspect state and prepare changes independently while still requiring approval to publish, deploy, spend money, delete data, or communicate under the operator's identity.
How is a higher autonomy level made safe?
Higher autonomy becomes defensible through narrow permissions, explicit execution limits, deterministic preconditions, durable state, observable decisions, and tested recovery behavior. Human review can be reduced only where the harness can constrain the action and establish its outcome without relying on the model's confidence.
When should an agent's autonomy level decrease during execution?
Reduce the level when assumptions stop holding: required evidence disappears, state becomes stale, a verifier repeatedly fails, permissions differ from the plan, or an earlier action has an unknown outcome. The transition should be explicit and recorded rather than implemented as an invisible degraded mode.
Does requiring approval make a workflow low autonomy?
Only at the boundary covered by that approval. A workflow may autonomously research, compare options, prepare an artifact, and run checks before pausing for one consequential decision. Measure autonomy by how much scoped work proceeds independently, not simply by whether any human approval exists.
How should teams choose an initial autonomy level?
Start from consequence and recoverability. Grant more independent execution to actions that are narrow, observable, reversible, and safe to retry. Require intervention where permissions are broad, effects are external or irreversible, outcomes are hard to confirm, or the recovery contract has not been tested.