The problem with asking too much
An assistant that asks permission before every action is safe and worthless. Nobody wants a system that confirms whether to send the confirmation text. An assistant that never asks is fast and eventually catastrophic. Everyone building in this space is somewhere on that line, and almost everyone picks their position by feel.
Picking by feel produces a specific pathology: approval fatigue. Once a person has approved forty routine things this week, the forty-first is approved without reading, and so is the one after it that should not have been. The prompt is still there, the audit log still shows a human approval, and the safety property it was supposed to provide has quietly evaporated.
Reversibility beats risk
The framing that worked for us is not how risky is this action but how hard is this to undo. Those correlate but they are not the same, and the cases where they diverge are exactly the ones intuition gets wrong. Sending a message to a customer feels low-risk and is completely irreversible. Rescheduling an internal meeting feels consequential and can be undone in four seconds.
- Free: reversible by anyone, instantly. Act without asking.
- Cheap: reversible by the account holder within a short window. Act, then report.
- Costly: reversible but with effort or embarrassment. Ask, with what you plan to do stated concretely.
- Terminal: not reversible. Ask, and require the person to state the outcome rather than press yes.
What the reclassification changed
Sorting our existing action catalogue by reversibility rather than by intuited risk moved about a third of the actions, and moved them in both directions. Several things we had been confirming turned out to be trivially reversible and are now silent. Several we had been performing without comment turned out to be terminal, which was uncomfortable reading.
Things we stopped asking about
Creating a draft, adding a calendar hold, tagging a record, preparing a quote that has not been sent: all reversible by anyone in seconds, all previously behind a prompt because they sounded consequential. Removing those prompts cut approval volume by roughly 60% without touching any genuinely dangerous action, which is where most of the fatigue was coming from.
Things we started asking about
Sending a first message to a contact who has never been contacted before. Cancelling something a customer is expecting. Any outbound communication that states a price. None of these are dramatic, all of them are irreversible in the sense that matters: you cannot unsay something to a customer. And all of them had been running silently because they felt routine.
The outbound-message case is the clearest example of intuition failing. It is the highest-frequency action an assistant takes, which made it feel routine, and it is the one action that genuinely cannot be undone. Frequency had been doing the work that consequence should have been doing.
Making the prompt worth reading
Reducing the number of prompts only helps if the survivors are actually read, and a prompt is read when it contains information the person does not already have. "Send this message?" contains nothing. A prompt that shows the recipient, the exact text, what triggered it, and what will happen if it is declined gives someone a reason to look.
| Before | After | |
|---|---|---|
| Approvals per user per week | 41 | 16 |
| Median time spent on a prompt | 1.2 s | 6.8 s |
| Approvals later reversed by the user | 3.1% | 0.6% |
| Terminal actions taken without approval | 0.7% | 0% |
Median time on a prompt going up is the result we were hoping for and the one that looks worst out of context. Six seconds means the prompt is being read. One point two seconds means it is being dismissed, and a dismissed prompt provides no safety property at all while providing a complete audit trail suggesting it did.
What stays unsolved
Reversibility is a property of the action and the system it touches, and we do not always know the second part. An external system that reports a booking as cancellable may not honour that at the hour it matters. We currently treat unknown reversibility as terminal, which is conservative and occasionally annoying, and we would rather be annoying there than wrong.
None of this is a solved problem, and any vendor claiming their approval model is finished is describing a system that has not met enough edge cases yet. What we can say is that reversibility is a better organizing principle than risk, and that the number of prompts is a worse metric than whether anyone reads them.
What this looks like in a real deployment
The reclassification is not something an account holder configures from scratch. Every action in the catalogue ships with a reversibility class, and most deployments never change any of them. The ones that do are usually tightening rather than loosening, and the pattern of what they tighten is informative.
What customers move, and why
- Outbound messaging to new contacts, moved from costly to terminal in regulated industries
- Anything touching a price, moved to terminal almost universally
- Internal scheduling, moved from cheap to free once teams see how often it is undone anyway
- Record tagging, moved to free within the first fortnight in nearly every deployment
The direction of travel is consistent: outbound communication gets stricter and internal housekeeping gets looser. That is a sensible instinct and it matches what the data says about which actions actually get reversed. Teams are, on the whole, better at judging this for their own business than a default ever could be.
The audit trail is not the safety property
One thing worth stating plainly, because it comes up in most procurement conversations: a complete audit log does not make a system safe. It makes a system explicable after the fact. Those are both valuable and they are not the same, and an approval flow that produces an immaculate record of rubber-stamped prompts has delivered the second while appearing to deliver the first.
We report approval dwell time internally for exactly this reason. If the median time on a prompt falls, the safety property is eroding regardless of what the approval rate says, and that is a signal we would rather catch ourselves than have explained to us by a customer after an incident.
Where this is heading
The next problem is delegation over time. A person who has approved the same category of action forty times has effectively expressed a policy, and continuing to ask is both wasteful and corrosive. Learning that policy without silently widening what the assistant may do is the open question, and we do not have a good answer to it yet.