The One-Way Door Problem
In 2015, Jeff Bezos wrote a letter to Amazon shareholders that changed how I think about automation forever. He categorized decisions into two types: one-way doors and two-way doors.
A one-way door is a decision you can't easily reverse — selling your company, launching a flagship product, firing a key employee. Once you walk through, there's no going back.
A two-way door is a decision you can undo — trying a new tool, running an experiment, changing a process. If it doesn't work, you walk right back through.
Here's what Bezos noticed: most organizations treat two-way doors as if they were one-way doors. They deliberate for months on reversible decisions, burning time and momentum.
Now apply this to AI automation. Every automation you build is a decision. But here's the twist that most people miss: some automations are reversible and some aren't — and the difference determines whether your system survives long-term.
Why Irreversible Automations Are Time Bombs
Let me show you what I mean.
You build an automation that, every time a customer submits a support ticket, uses AI to generate a response and sends it automatically — no human review. Fast, efficient, scalable.
But what happens when the AI generates a tone-deaf response to an angry customer? What happens when it confidently provides wrong information about a pricing change? What happens when a customer asks about a refund and the AI cheerfully tells them returns aren't possible — even though your policy was updated last week?
This is an irreversible automation. The email was sent. The customer saw it. You can't unsend an email.
Now compare: the same automation, but instead of auto-sending, it drafts the response and queues it for a 30-second human glance. If no one reviews it within 5 minutes, it auto-sends anyway.
This is a reversible automation. It captures 95% of the speed benefit while keeping a safety net. And critically, if you realize something is wrong — wrong tone, wrong info, wrong policy — you can pull the draft before it ships.
The Reversibility Test: 4 Questions
Before you automate anything, ask yourself these four questions:
1. Can I undo the output?
If the automation sends an email, posts publicly, or modifies a production database, the output is hard to reverse. If it drafts a document, updates a spreadsheet, or fills a queue, it's easily reversible.
2. Can I detect failures before they spread?
An automation that publishes to your blog without review can't be caught before readers see it. An automation that saves a draft can be reviewed, edited, and published manually.
3. Can I roll back the state?
If the automation modifies a database, can you restore the previous state? If it deletes files, do you have backups? If it sends notifications, can you send corrections?
4. Can I turn it off without breaking everything?
Some automations become load-bearing — other systems depend on their output. If you turn them off, everything collapses. The best automations are optional: they improve things when running, but the system works without them too.
The Reversibility Spectrum
Not everything needs to be fully reversible. The key is matching the reversibility to the risk.
Low risk, low reversibility needed: Internal data processing, report generation, file organization. If something goes wrong, you catch it next time. Automate freely.
Medium risk, partial reversibility needed: Content creation, customer communication drafts, data enrichment. Build in a review step or a delay window. Automate with a checkpoint.
High risk, full reversibility needed: Public posts, production database changes, customer-facing actions. Always build in a human approval gate or a dry-run mode. Automate with a kill switch.
The Asymmetry of Automation Failures
Here's the uncomfortable math of automation failures.
An automation runs 365 times a year. It works correctly 364 times and fails once. That's a 99.7% success rate — pretty good, right?
But if that one failure sends 5,000 customers a broken email with a broken link to a broken landing page... the 99.7% success rate doesn't matter. The failure is what people remember. The failure is what costs you trust, revenue, and reputation.
The failure cost is asymmetric. One bad automated action can outweigh hundreds of good ones. This is why reversibility isn't a nice-to-have — it's the core design principle that separates automations that compound value from automations that eventually detonate.
Building the Undo Into Your System
Here's a practical framework for making your AI automations reversible:
Draft before send. Instead of automating the final action (publish, send, deploy), automate the creation of a draft. Add a review step — even if it's just a 5-second skim.
Log before execute. Before any automation modifies state, write what it's about to do to a log. This gives you an audit trail and a way to understand what happened if something goes wrong.
Queue before batch. Instead of processing 1,000 items at once, process 10 at a time with a checkpoint between batches. If something breaks, you've lost 10 items, not 1,000.
Staging before production. Run new automations in a staging environment first. Let them process dummy data. Only promote to production when you've watched them handle edge cases.
Time-delay before action. For automated communications, add a 5-minute delay between generation and sending. This gives you a window to catch errors before they become irreversible.
The Paradox of Reversible Automations
Here's the counterintuitive part: reversible automations move faster than irreversible ones.
When you know you can undo something, you ship it sooner. When every automation is a one-way door, you agonize over every detail and ship nothing.
The teams that build the most automations aren't the ones with the highest risk tolerance — they're the ones with the best undo buttons.
Reversibility isn't caution. It's speed with a safety net. It's the difference between driving with brakes and driving without them. The car with brakes goes faster — not because it's more powerful, but because you can stop when you need to.
The Takeaway
The best AI automations aren't the ones that run the fastest or the ones that are the most complex. They're the ones you can undo.
Build automations that draft before they send. Log before they execute. Queue before they batch. Stage before they produce.
Because the automation you can't undo is a ticking clock. And the one you can? That's the one you'll actually trust enough to let run while you sleep.
What's one automation in your workflow that's currently a one-way door? How could you add an undo button to it?
Top comments (0)