Home/Frameworks/The delegation ladder
The delegation ladder
Read, draft, send, commit. Four rungs of autonomy, and a way to notice when a system is standing on one it was never assessed for.
Ask a room what they would let an AI system do on their behalf and the argument is usually about the technology. It is the wrong argument. Consider three versions of the same task: the system drafts a reply and you read it before anything leaves; the system sends the reply and the customer sees it before you do; the system commits the organisation to an outcome, a refund, a price, a promise.
The technology does not change between these three. The permission changes, and so does the consequence.
The four rungs
Read
It retrieves and shows you. Nothing leaves the building and nothing changes state. The failure mode is quiet: it surfaces material the reader should not see, or misses material they needed.
Draft
It writes, and a person decides whether to use it. The cost of a mistake is the reviewer's attention. That is real, and it erodes: a reviewer who has approved two hundred good drafts is not reading the two hundred and first.
Send
It reaches the customer without passing through a person. A mistake is now external and public. This is the rung where most organisations discover their evaluation was not as good as they thought.
Commit
It binds the organisation to an outcome. A refund, a price, an eligibility decision, a promise someone can hold you to. A mistake here is not a bad message, it is a liability.
What each rung asks of you
| Rung | Who authorises | Cost of a mistake | Minimum before you climb here |
|---|---|---|---|
| Read | Data owner | Disclosure, or a missed fact | Access control that matches the reader, not the system. |
| Draft | Process owner | Reviewer time, and review fatigue | Evidence attached to the draft, so review is possible rather than nominal. |
| Send | Process owner and risk | An external error, at volume | Measured quality on your own data, a stop condition, and a way to recall. |
| Commit | The accountable executive | Financial or legal liability | A named owner, limits per decision, and a complete log of what was decided and why. |
Where teams get this wrong
Shipping at Send, assessed for Draft
The most common error, and the one worth watching for. A pilot runs with a person in the loop, quality looks good, and the human step is removed to gain throughput. Nothing is re-assessed, because the model did not change. But the controls that made Draft safe were the reviewer's judgement, and that has just been deleted.
Treating the rung as a property of the technology
Autonomy is not a capability level. It is a grant. Two teams can deploy the identical system at different rungs, correctly, because their processes carry different consequences.
Letting the rung drift upward without a decision
Nobody approves the climb. An integration is added, a confirmation step is removed to reduce friction, a default is flipped. Each change is small and locally reasonable. Together they move the system a rung, and no one has assessed it there.
A stop condition nobody can reach
At Send and Commit, the ability to stop matters more than the ability to review. If halting the system requires a deployment, it is not a control.
How to use it
Put every AI decision in your organisation on a rung, then check two things: whether the evidence you hold actually supports that rung, and whether anyone chose it deliberately. The second question usually produces the more uncomfortable answer.
Climbing is fine. Climbing without noticing is the problem.
Revisions
- First published. Drawn from the guest lecture delivered at Amsterdam Business School on 16 September 2026.
First-person account of the presenter's own practice. A teaching framework, not a legal taxonomy or any employer's policy. See how I make claims.