The Undo Problem
Warren Teitelman invented the undo command in 1971. Fifty-four years later, most AI tools that write to your data still don't have one.
Warren Teitelman invented the undo command in 1971. Not the key combination — the concept itself. His Programmer's Assistant, built at BBN in the years before anyone had heard of a personal computer, could watch what you did and take it back. Sophisticated enough to undo operations out of order: make six changes, undo only the third one, and the others stay intact. He called it the ability to "un-do a mistake." The INTERLISP Reference Manual documented all of it in 1974, before the Apple I existed, before VisiCalc, before anyone thought of selling software to normal people.
Fifty-four years later, AI tools are writing to people's notes, contacts, calendars, and task lists. Most of them have no undo at all.
That's not a minor oversight. It's a fundamental failure of design — one that reveals something about how we've thought about AI actions from the start.
Why AI writes are different
When you write something, the undo stack is clean. You typed a sentence, moved a paragraph, deleted a line. The application tracked every step. Ctrl+Z walks backward along a sequence you participated in.
AI writes don't work that way. Three things make them genuinely different.
First, an AI can act across multiple places at once. One instruction to "update my notes about this meeting" might modify a document, create a linked task, update a person record, and set a reminder — four separate writes from a single request. Undoing any one of them in isolation requires knowing which parts belong together.
Second, the writes happen based on reasoning you didn't see. The AI read something, made an inference, acted on it. If the inference was wrong, the error might not surface until much later — when you notice someone's job title is incorrect, or that a task was marked done that wasn't.
Third, AI agents fail and retry more than people realize. One industry report from 2025 found that LLM agents retry tool calls 15 to 30 percent of the time, due to timeouts, validation errors, or model uncertainty. If the underlying write operation isn't idempotent, retries don't just waste time. They corrupt data. The append that ran twice. The counter that incremented three times instead of one.
What reversibility actually requires
Building reversible AI writes is harder than it sounds, because there are four separate requirements — and most tools address only one of them.
The first is idempotent operations. "Set this field to this value" is idempotent. "Append this to the document" is not. If you design AI writes as state-setting rather than event-emitting, retries are safe by default. You can run the same operation ten times and arrive at the same place each time.
The second is patch proposals before application. Not a log of what happened — a preview of what's about to happen. A diff the user can inspect, approve, or reject before anything touches actual data. This is the step that transforms an AI action from something you witness into a decision you participate in.
After those two, you need per-entity history. Not "the document changed at 3pm" — that's a backup, not a history. Per-entity history means: this specific person record changed, here is what every field looked like before, here is what changed it. The granularity matters because when you want to undo, you rarely want to undo everything. You want to undo one thing.
And finally: a restorable state. Not a log you can read. A snapshot you can return to. These are distinct things. An audit log tells you the story; a restorable snapshot lets you rewrite the ending.
Most tools with any version history have only that last piece. The first three require deliberate architecture from day one. You cannot bolt them on afterward without rebuilding how writes work.
What this says about trust
A tool that can't be undone is asking you to trust it before it's earned that trust.
Real trust in software is built through repeated, observable, reversible interactions. You push code, you can revert. You make an edit, you can undo. You approve an AI action, you can roll it back. Each cycle of "I did something, I saw what happened, I could fix it if I needed to" builds a working model of what the system does and why. Over time, that model becomes confidence.
The tools that feel safest to explore — git, spreadsheets, any decent text editor — feel safe precisely because the floor doesn't drop out. You can make mistakes, correct them, try things that might not work. The reversibility isn't a safety net bolted on after the fact. It changes how you use the tool. You stop being cautious and start being productive.
This is what's absent from most AI writes. Not that the AI's judgment is necessarily wrong. It's that you have no way to develop a calibrated sense of when to trust it, because there's no recovery path for when it isn't right.
Teitelman figured out the philosophy in 1971. What's strange isn't that it took this long to become relevant again. It's that we're building AI systems capable of touching everything — every note, every contact, every preference — and we're not treating the undo problem as the central design question it obviously is.
Once you know you can undo something, you stop being afraid to let it happen.
Asgeir Albretsen is the founder of Harbor.