AI use cases: autonomy tiers
Autonomy is where AI use cases create the most value and cause the most damage, and both for the same reason: nobody is watching. So the question is never “should this be autonomous?” It’s “which tier?”, and the discipline is simple to state: pick the lowest tier that captures the value, go live one tier below your target, and promote only on measured evidence. The foundations page introduced the ladder. This page is about what each rung actually demands, because every rung up demands more governance, not less.
The four tiers
Section titled “The four tiers”| Tier | What the system does | What it requires |
|---|---|---|
| T0 · Draft | Produces output; a human uses it | A human who genuinely checks |
| T1 · Propose | Prepares actions; a human approves each one | An approval that’s real, not a rubber stamp |
| T2 · Supervised | Executes whitelisted actions within thresholds | Whitelist, thresholds, audit log, sampled review, rollback |
| T3 · Unattended | Runs with no human in the loop | Own identity, least privilege, kill switch, blast-radius limits, monitoring |
The right column is the point of this page. Each entry is work: design, engineering, and ongoing operations. Treat it as a cost line in the business case, not a checklist you tick after go-live.
T0 · Draft: a human who checks
Section titled “T0 · Draft: a human who checks”The system writes; a person reads, corrects, and uses. The output never touches another system on its own. This sounds trivially safe, and it is, on one condition: the checking stays real.
That condition erodes. When the draft is right nine times out of ten, the reviewer stops reading and starts skimming, and by month three the “human in the loop” is a formality. T0 therefore still needs governance: a named owner for output quality, and periodic spot checks against known-correct answers so you notice when quality drifts before a customer does. If nobody would catch a wrong draft, you’re not at T0. You’re at T3 without any of T3’s safeguards.
T1 · Propose: a real approval
Section titled “T1 · Propose: a real approval”The system prepares the action, a draft reply queued to send, a record staged to update, and a human approves or rejects each one. The gate is the product here, so the gate has to work. A real approval means the approver sees enough to judge (the actual change, the record it touches, the amount involved), has the authority and the time to say no, and sometimes does.
Watch the rejection rate. If approvals run at 100% for months, you no longer have a gate; you have latency, and everyone involved knows it. That’s not a failure. It’s evidence, and it’s exactly the evidence a promotion to T2 should be built on. Which changes were approved, which were rejected, and why: that record is your whitelist waiting to be written.
T2 · Supervised: bounded execution
Section titled “T2 · Supervised: bounded execution”The system now acts on its own, inside a fence you built first. The fence has five parts, and all five are mandatory:
- A whitelist, deny by default. The system can take the actions you named and nothing else.
- Thresholds on whatever can hurt: amounts, volumes, rates. Anything above the line falls back to T1 and waits for a human.
- An audit log of every action: what, when, on which record, under which rule. Written to a system the agent can’t edit.
- Sampled review. A human no longer sees every action, so a human must see a sample, on a schedule, with someone accountable for looking.
- A rollback path, tested before go-live. If you can’t undo the action, it doesn’t belong on the whitelist.
T2 is where most write-capable use cases should aim to settle. The value of autonomy is mostly captured here, at a fraction of T3’s governance cost.
T3 · Unattended: safe by inability
Section titled “T3 · Unattended: safe by inability”No human in the loop, so every safeguard must hold on its own. The system gets its own service identity, never a person’s account, so its actions are distinguishable in every log and revocable in one move. It gets least privilege: the narrowest permissions that let it do its job, because a capability it doesn’t hold is a mistake it can’t make. It gets a kill switch that a named person can pull in seconds, without a change request. It gets blast-radius limits: caps on how much damage one run, one hour, one bad day can do. And it gets monitoring that pages a human when behaviour drifts, because at T3 the sampled review is all the review there is.
Very few use cases need this tier. Be suspicious of any that claims to.
The same layer, one level up
Section titled “The same layer, one level up”If this sounds like the deterministic layer, it should. It’s the same principle applied to a whole use case instead of a coding session: gates that can’t be talked past, capabilities withheld rather than rules requested, and a human who owns the consequential step. The tier you choose decides where that human stands, not whether one exists.
Once the tier is set, one question remains: build this at all, or buy it?