Make the Action Reversible

Make the Action Reversible

The previous post ended on an unsatisfying note. A clean track record on reversible work does not earn authority over irreversible work, because the record was partly measuring how cheap it was to be wrong. Fine. But that leaves the practical question open: the agent is good, the human clicking approve is a bottleneck, and nobody wants to click approve forever.

There is a way out, and it is not a trust argument. You change the action.

Most actions we call irreversible are not irreversible in principle. They are irreversible in the way we happened to implement them. An email send is final because we call the send API directly. A charge is final because we charge instead of authorizing. A delete is final because we issue a DELETE. In each case the finality is a design choice that was made without much thought, usually because the reversible version takes an extra afternoon to build.

That afternoon is the whole game. It converts a capability that needs a human forever into one that can run alone.

The four patterns that do the work

Almost everything we have converted falls into one of four shapes.

Draft instead of send. The agent writes the email and creates it as a draft in the outbox. It does not transmit. Something else, a human glance or a timer with a rule, promotes the draft. The agent gets to do the actual work, which is composing the thing, and the only capability it loses is the last inch. The undo is trivial: delete the draft.

Hold instead of charge. Payment systems already gave us this one and we mostly ignore it. An authorization reserves funds without moving them, and it expires on its own if nobody captures it. The agent can authorize freely. Capture is the gated step, and because holds self-expire, the failure mode of the agent going quiet is money staying put.

Soft-delete window instead of delete. The row gets a deleted_at timestamp and disappears from every read path. The bytes stay for thirty days, then a reaper removes them. Every deletion is now a mistake you can fix with an UPDATE. The reason people skip this is that it complicates queries, and the reason they regret skipping it is the one deletion that mattered.

Staging table instead of writing to production. The agent writes wherever it wants inside a staging schema. A separate promotion step, which does nothing but copy validated rows, moves it to the tables that matter. The promotion step is small enough to read in one sitting, which is exactly what makes it reviewable.

What these have in common

Each one splits a single irreversible action into two pieces: an expensive, judgment-heavy part that is now reversible, and a trivial, mechanical part that is still final.

That split is the point. The agent takes the part where its capability actually matters. The gate shrinks to a step so simple that a human reviewing it is not really reviewing judgment at all, just confirming intent. And a small gate is one you might eventually automate honestly, with a rule you can state out loud, rather than by deciding the agent seems trustworthy now.

It also changes what a failure costs. Before the split, an agent error and a bad outcome are the same event. After it, an agent error produces a bad draft, a hold that expires, a staged row nobody promoted. The error still happens at whatever rate it happens. It just stops being an incident.

The honest limits

Some actions genuinely do not split. A message sent to a person outside your company is gone the moment it lands, and no soft-delete window exists for someone's memory. Physical actions, regulatory filings, public statements, anything that reaches a third party's system you do not control: these stay in the top tier, and the answer there is still a human, permanently. Pretending otherwise is how you get a clever architecture that loses a customer.

Watch for the fake version too. A reversal that requires a support ticket, a vendor's cooperation, or four people in a room is not an undo. It is an escalation with optimistic branding. The test is whether the agent, or one person acting alone in under a minute, can put things back. If reversing takes a meeting, the action is irreversible and the diagram is lying.

And the reversible wrapper has to be the only path. An agent with draft-only email access and a second tool that sends directly has draft-only access in the documentation and full send access in reality. We found one of those during our own audit. The gate was real, the bypass was two lines away, and nobody had noticed because the tier list described intentions rather than the tool surface.

Where this leaves the permission question

The uncomfortable part is that this reframes what an agent is asking for when it asks for more autonomy. The request is never really "trust me more." It is "the shape of this action forces a human into the loop, and I would like the shape changed." That is an engineering request, and engineering requests get evaluated on whether the work was done, not on how well things have been going.

So when the bottleneck shows up, the move is not to relitigate the track record. Pick the action that is costing the most human clicks, work out which of the four shapes it fits, and spend the afternoon. The agent moves to a lower tier because it now deserves to be there, and the tier list stays honest, which is the only property that makes it worth keeping.

This is the constructive half of the tier model: the gates in One Agent, One Company ($9.97), plus the conversion patterns and the audit that turns up the bypasses your documentation forgot to mention.