TL;DR: Five levels cover most AI features: L0 suggests, L1 drafts for approval, L2 acts with undo, L3 acts within budgets or rules, L4 takes on whole delegated tasks. Assign a level to each action type, not to the product, based on what a mistake costs, whether it can be undone, and how much evidence shows the AI gets that action right. Start lower, promote with approval data, demote when errors rise.
The levels
| Level | The AI | The user | Example |
|---|---|---|---|
| L0 Suggest | Offers options | Decides and acts | Autocomplete, reply suggestions |
| L1 Draft for approval | Prepares the full action | Approves, edits or rejects | Drafted email; proposed refund |
| L2 Act with undo | Acts and notifies | Can reverse within a window | Archiving newsletters; tagging tickets |
| L3 Act within limits | Acts without asking inside budgets or rules | Sets limits, reviews periodically | Accepting meetings within working hours; refunds under a threshold |
| L4 Delegate | Plans and completes a whole task | Briefs, handles checkpoints, receives a report | "Book the team offsite within this budget" |
Choosing a level
Three questions per action type:
- Cost of a mistake. Money, harm, embarrassment, legal exposure. Higher cost pushes the level down.
- Reversibility. Can it be undone easily, by whom, and how fast? Irreversible actions (sending, paying, deleting) rarely go above L1 without strong checks.
- Evidence. How often has the AI's proposal for this action been accepted unchanged, on enough cases to trust the rate? No evidence means L1 regardless of risk.
Mixed levels in one product
A real assistant runs several levels at once. An inbox assistant might summarise at L3, archive at L2, draft replies at L1, and never send payments. Describing a product as "fully autonomous" usually signals that nobody has thought about levels per action.
Moving between levels
Approval queues produce evidence. For each action type, track how often proposals are approved unchanged, edited or rejected, and why. Promote when approval-without-edit clears a bar set in advance, on enough cases (a few hundred for low-risk actions). Demote automatically when undo or error rates rise. Users should always be able to choose a lower level for themselves.
Watch for approval fatigue: very high approval rates can mean reviewers stopped reading. Periodically check catch rates with known-bad proposals before treating approval data as proof.
What each level needs
| Level | Design requirements |
|---|---|
| L0 | Low friction to ignore; suggestions that do not obstruct |
| L1 | Specific, readable proposals with evidence; edit before approve; app-rendered confirmation |
| L2 | Activity log; real undo with a clear window; notifications in digests |
| L3 | User-set limits; enforcement in code; periodic summaries; automatic demotion triggers |
| L4 | Structured brief confirmed back; decision rights; living status; batched checkpoints; final report and audit trail |
Autonomy and accountability
Higher autonomy does not move accountability to the model. The organisation remains responsible, which is why limits, logs and undo must be enforced by the system rather than promised by the model. In regulated settings, some actions should stay at L1 permanently, with a person making and recording the decision.
In the interview
Autonomy levels give structure to agent and assistant design questions. Strong answers assign levels per action using cost, reversibility and evidence, describe promotion and demotion with data, and list the design elements each level needs. Saying "autonomy is earned per action" captures the idea.