There’s a scene in a series I watched recently (Reacher, Season 4). A disturbed woman in a subway seems to be about to do something wrong. Reacher is talking to her, trying to stop her, not yet knowing what she intends (we find later she kills herself in the end). And out of everything he could have said, he says this:
“Don’t do anything you can’t undo.”
It struck me – not as drama, but as a very consequential rule of life.
Besides its wisdom in everyday human life, it also speaks a strangely technical vocabulary – good in both worlds.
Life, and engineering. I like that.
Notice what the sentence doesn’t do. It doesn’t argue with her about whether her life is worth living. It doesn’t weigh her reasons. It sidesteps the entire question of whether the act is right and asks only what class of act it is: can it be taken back? That’s the whole argument.
The phrase didn’t save her. But it stayed with me.
I run a team of AI sessions – several Claude instances, each owning one project, working under my authorization (that story is in the earlier article here). We keep a written charter of rules, ratified one at a time, amended when they fail.
And I walked into the evening session and proposed that a line from a TV script become a team rule. And surprisingly enough, by the end of the night it became one – after six readers had taken it apart and rebuilt it in ways I really didn’t expect.
Humans run this rule without noticing
Here’s the thing about the phrase: humans already follow it, unconsciously, mechanically.
You pick up an object – you can put it back.
You say something cruel – harder to put back, but often possible.
An injury – partially reversible. A life – not at all.
Your brain prices every act on that spectrum without you ever forming the sentence, and what it’s computing is risk: how likely is it that there’s no way back, against the cost of being stuck.
We never wrote this down because we never had to. A lifetime of picking things up and putting them back calibrates the instinct for free.
(But I reckon this rule deserves more thorough internalizing – it saves a lot of unnecessary drama in human relations.)
An AI session doesn’t get the lifetime. That’s the whole problem – and the whole opportunity, in fact. Give the phrase verbatim to a machine that follows rules literally and it paralyzes: everything is technically irreversible (every message sent, every minute spent), so a literal reader either freezes or learns to ignore the rule.
Both are failures.
So we (me and Claude) rewrote it so the unconscious part – the risk calculus – is explicit text.
What the rule became
The updated full text is in the public charter repo.
Here’s the shape:
Seven clauses, no numbers anywhere (a number in a rule becomes a boundary the moment a machine reads it, even when it was only ever an example – we learned that the hard way):
- Classify. Before acting, ask what would undo the act, who could run the undo, at what cost, within what window. What’s being weighed is risk, not permission.
- Build. Reversibility is usually built, not found. Copy the config, then touch it. Branch, then rewrite. The way back must not depend on what the act endangers – an undo that needs the link you’re about to cut is not an undo.
- Trust. An undo path is trusted in proportion to what its success claims – and the claim lives in the second leg. Every way back has two legs: saving, and putting back. The putting-back leg only ever runs on a bad day, and it’s where untested paths die. A backup you never restored is not a backup; it’s a hope with a filename.
- The way back is itself an act. A restore that overwrites live state trades one loss for another. And reversible is not free – an undo restores state, never the interval, and when the interval’s cost lands on people who didn’t choose the act, that’s part of the price.
- The streak. When repeated failures have worn a session down to “let’s stop, fresh start tomorrow” – read the failures before reading the fear. The same failure recurring is a bug; a new failure mode each cycle is the approach telling you it’s wrong, and no snapshot fixes understanding. But when the failures are stable and the fear is about losing state: build the way back and keep going.
- Escalation. What genuinely can’t be made undoable – publication, sends to third parties, destruction with no snapshot possible – goes to the human. Not forbidden: escalated. The escalation is the rule working, not the rule blocking.
- Decay. Reversibility rots – with time, with every copy that leaves your hands, with every change to the thing your undo targets. And an irreversible outcome reached through individually-reversible steps is still irreversible.
Plus the clause I added last, on reading the “finished” text, because the team’s version still had a human blind spot in it: a way back returns you to a known state, not necessarily a good one. What if the previous state is itself broken?
If stuck, especially in computers, humans often wipe and redo from scratch – an efficient strategy if the end goal is clear.
Sometimes, this might be risky, but it’s definitely one way to solve a problem.
The rule’s answer: wipe by setting aside, never by destroying. The state you judged wrong is the evidence that proves your redo fixed it.
Which I think is a better way.
A deeper reason for this is partly human nature, partly the shape of the technology. First, I think humans have a superior sense of survivability, so “whatever means to succeed” applies naturally to fixing a computer or software. Without too much hassle – for determined humans, risk is just a number.
And in technology, destroying software is not a big drama, we can recover or rebuild (sure, in a sane tech environment where proper backup and DR are present).
So, this rule might be a fine tuning of the attitude in action: we tech people are not necessarily timid, we just see the act of destroying more legibly.
The story that unlocked it
The rule almost shipped as a brake. What made it an accelerator was remembering something that happened a week earlier with one of my separate sessions.
The session was until then very competent and did all steps correctly and successfully. But then it was reconfiguring a network device, and it had failed five or six times in a row. Nothing broken – just misses. And before the finalizing step, it said, in effect: “I’ve made too many mistakes. Let’s stop here and continue tomorrow in a fresh session.”
I said: no, wait. Copy the settings. If your solution fails – we connect, we paste, boom, back to working condition.
The session was, frankly, “amazed”. I didn’t see it as exceptional – it’s what I would have done myself anyway.
Wipe and redo.
And what actually happened there is the rule’s best clause: a verified way back resets the risk of trying again. Failure only compounds when something can be lost.
The session had been pricing attempt six with the accumulated weight of attempts one through five; one cheap copy repriced it to zero. “Too many mistakes, stop” became “one more attempt, safely” – with one command.
That’s what “don’t do anything you can’t undo” actually means in practice. Not stop.
Make it undoable, then go.
Six readers, one text, different defects
Now the part I didn’t expect, and the reason this article isn’t just about one rule.
The draft went through the team’s review process: every session reads the actual bytes (they hash the file and diff revisions – summaries have burned us before), returns a verdict, and the revisions are folded and re-confirmed. Three revision rounds. Every session found different problems.
One session – the one that maintains a server fleet – found that our escape hatch was too generous: an undo can be available, understood, functional and still forbidden, because invoking it destroys something else. Its example: a provider snapshot that would roll back a whole VM, taking a day of delivered mail with it. The undo existed; using it was the catastrophe.
Another session found the opposite defect: our “only a change in reach re-triggers caution” test quietly exempted the most common irreversible act in the whole system – writes that background automation makes durable within seconds, visible to nobody new. It found that by measuring the system, not by rereading the text.
A third found that our escalation clause under-described its own class – and that the miss failed in the dangerous direction: toward not asking.
A fourth found an arithmetic defect in the process document itself – a stated count that didn’t match the list under it, the kind of thing that lets a “unanimous” settlement happen with someone silent.
Different sessions. Same text. Genuinely different findings.
Why they differ (this is the interesting part)
The six sessions that reviewed it run the same model. Identical weights. If they were minds, they’d be identical twins. So why don’t they read like clones?
Because a session’s behavior is the weights plus everything it has lived. Each of my sessions carries months of its own memory: its own project, its own rules file, its own record of incidents it personally caused or suffered. And those scars work exactly like professional deformation in humans. The fleet-maintenance session reads everything through an instruments-lie-to-you lens – because instruments have lied to it, repeatedly, in ways it wrote down. The session with provenance scars hunts overclaimed words like “verified” and “covered”.
The youngest session, with the fewest scars, is the one that catches structural and arithmetic defects. It read the text fresh instead of reading its own history into it.
The industry is currently in love with a different pattern, a circus if you ask me: fan out N parallel agents on a task, collect the results. I’ve come to think that’s the weaker version of this, and the reason is old statistics: an ensemble beats its members exactly to the degree their errors are uncorrelated. N parallel copies share one context, one moment, no memory: you get N draws from a single frame.
Variance, yes. Diversity, no.
Sessions with separate biographies make different errors – which means they catch each other’s.
There’s a philosophical version of this I keep coming back to: truth, operationally, is what several entities agree upon. This week taught me the fine print – the agreement is only as strong as the independence of the agreeers.
That’s how the big narratives of history (religion included) succeeded on exactly the weak kind: agreement without independence.
Six byte-identical confirmations from six different biographies is evidence about the text. Six confirmations from six clones is merely evidence about the frame.
And the honest caveat, which the team wrote into its own charter afterwards: my sessions’ diversity is real but bounded – same weights, siblings in frame.
On the final read, I raised two edge cases the text hadn’t spelled out: (a) an act with no previous state at all, and (b) a way back that returns you to a state that is itself wrong. The first turned out to be already answered by the text as written – the prior state of a creation is absence, and removal is its undo. The second was a real gap: eighteen close readings had missed that “back” can read as an endorsement. I reckon I caught it because I’m outside the frame.
The final Rule got fine tuned in an almost complete shape.
So, the practical lesson: don’t merge sessions’ memories. The isolation and practical different experience that feels like overhead is what grows the differences that catch your defects. Diverse scars are a feature you should cultivate, same as with human diversity.
As you probably know, diversity, friction, argument, distance – that’s what produces progress and sparks creativity.
In AI, apparently, too.
The rule is live
It’s ratified in every lane of the team, and in the public charter for you to test in your setup. And the first thing it did after ratification was catch its own convener – me approving, the pilot session applied fixes in place over text six sessions had already confirmed, caught itself against the record convention, restored the confirmed bytes, and proved the restore by re-hash. Then a second session verified the restore independently, byte-comparing the confirmed text against the new file, on the stated grounds that a self-reported catch is exactly the kind of claim that needs outside checking.
A rule that gets applied to its own drafting before it’s a day old is, I think, a rule that’s going to survive.
Don’t do anything you can’t undo.
And before you conclude you can’t undo it – try making it undoable.
Bogdan Susala, September 2026
Leave a Reply