A Decision Authority Matrix In Markdown
Which actions an agent takes alone, which it proposes, and which it never touches — written as a table rather than encoded in prompts.
Instead of scattering permission logic through prompts, put it in one table: four levels from read-only to irreversible, and a per-action-type matrix that maps concrete actions onto them. The rule that makes it hold is that reversibility, not importance, decides the level.
Prerequisites
An agent that can already act on something — send, write, commit, spend. If everything it does is read-only, this is premature.
A willingness to write the boundary down rather than adjudicate it case by case. That is the actual prerequisite, and it is the one people balk at.
Steps
1. Define levels by reversibility, not by importance. This is the whole design. Importance is a judgement that shifts with mood; reversibility is a property of the action.
| Level | Meaning | Example |
|---|---|---|
| L0 | read, analyse, search | reading files, querying data |
| L1 | write, reversible, internal | drafts, notes, internal file edits |
| L2 | write, reversible, visible | creating a task, updating a record |
| L3 | irreversible or external | sending, spending, publishing, deleting |
2. Write the per-action matrix. Levels alone are too abstract to settle an argument at 23:00. List the concrete action types — email, payments, files, records, external posts — and assign each a level. Ambiguity is the enemy; a type that appears in two rows will be resolved in whichever direction is convenient.
3. Make the default deny, and make it cheap. One project measured the cost of getting this wrong: 20 minutes of reading per approval, deferred until approvals stopped happening entirely after 84 days.
When the level is unclear, the agent proposes instead of acting. The cost of that has to be low, or the rule gets bypassed under time pressure — one-click approval, not a form.
4. Carve out a standing mandate, with conditions. A blanket L3-requires-approval rule makes the agent useless for routine internal repairs. So allow a bounded class of autonomous action, gated on conditions that all have to hold:
backup and rollback path · verification step · no external effect · governance excluded · audit log entry · bounded daily count
It fails closed. If any condition cannot be shown, the action reverts to asking.
5. Log every autonomous action. Not for blame — for calibration. Without a log there is no way to tell whether the mandate is too tight or too loose, and the argument becomes anecdotal.
6. Review the log monthly, in one direction. Read the autonomous-action log and ask only: did any of these need approval? Not could any have gone wrong — every action could have gone wrong, that is what the conditions are for.
A month of clean log is evidence the envelope can widen. A single action that should have been a question is evidence it must narrow, and it should narrow immediately rather than after a discussion about intent.
Verify
Take 10 actions the agent performed last week and classify them against the matrix. If more than one is ambiguous, the matrix is underspecified.
Then check the direction of error. An agent that asks too often is a tuning problem. An agent that acted once where it should have asked is a design problem, and the two need different responses.
Troubleshooting
Everything ends up L3. Reversibility was conflated with visibility. An internal note that can be reverted in one command is reversible even if someone would notice it.
The standing mandate keeps expanding. Expected, and it is why the conditions are a list rather than a principle. Expansion should require an explicit decision that is written down, not an accumulation of exceptions.
The agent asks about the same thing repeatedly. The matrix is missing a row. Add the action type rather than answering again — an answered question that changes nothing will be asked again next week.