Agent Architecture and Orchestration
Autonomy Levels — Stack
Autonomy levels › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
The mechanism has to express a permission precisely, enforce it where the model cannot reach, and leave a record that satisfies someone who was not there.
- Granularity of expression. Whether a rule can name an action class, an argument range, a record count, and a tenant, or only a tool name.
- Enforcement point. Whether the decision is made by code the model cannot influence, ideally at the same boundary that holds the credentials.
- Approval latency and reachability. How quickly a decision reaches a person who can actually make it, including out of hours, and what happens when nobody responds.
- Audit record. Whether what was requested, what was approved, by whom, and on what evidence is captured in a form that survives independently of the run.
- Reversibility support. Whether the mechanism can distinguish undoable actions from permanent ones and treat them differently.
- Progressive rollout. Whether a level can be raised for a cohort, measured, and reverted without a deployment.
- Emergency stop. Whether all autonomy can be withdrawn immediately across the fleet, and how long that takes to propagate.
- Policy legibility. Whether a non-engineer can read the current permissions and recognise them as the policy that was agreed.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Policy engines evaluated before each action (Open Policy Agent, Cedar) | Fine-grained, auditable rules that change without redeploying the agent | Policy authoring is a skill; a permissive default rule undoes everything above it |
| Scoped, short-lived credentials per run | Making the permission boundary the same boundary as the access boundary | Scope granularity is limited by what the downstream system models; coarse scopes over-grant |
| Framework approval interrupts before designated tools | Products where the approval step is part of the designed interaction | Enforced inside the agent runtime, so it protects against mistakes rather than against compromise |
| Approval queues in a product surface or chat workspace | Decisions a person must make with context, possibly out of band | Latency and fatigue are the dominant risks; queue ownership and escalation must be explicit |
| Dual control for high blast radius | Irreversible or large-scale actions where one approver is not enough | Expensive and slow; reserve it for the few actions that genuinely warrant it or it will be circumvented |
| Dry-run and simulation modes | Establishing an evidence base before granting unsupervised operation | Simulation fidelity is the whole value; a dry run that diverges from reality builds false confidence |
| Cohort rollout with a kill switch | Raising autonomy on evidence while bounding the population exposed | The kill switch must be tested regularly or it will not work when it is needed |
| Post-hoc sampled review | Unsupervised operation at volumes where per-action approval is impossible | Detects problems after they have happened; sample size and reviewer expertise decide whether it detects anything |