Agent actions should be governed by reversibility, not by how confident the model sounds. An action an agent can undo cleanly deserves autonomy; an action that permanently changes the world — sent emails, executed payments, deleted records — deserves a human approval gate, regardless of the model's accuracy rate. The design question isn't "how often is the agent right?" It's "how expensive is it when the agent is wrong?"
Quick Answer: Classify every agent action as a one-way door (irreversible, needs approval) or a two-way door (reversible, can run autonomously). Optimize for the cost of being wrong, not the odds of it — cheap-to-undo actions can run at full autonomy even with a mediocre accuracy rate, while expensive-to-undo actions need a human in the loop even at 99% accuracy.
Why Accuracy Is the Wrong Metric for Agent Autonomy
Teams building AI agents default to asking "what's the model's accuracy?" as the gate for autonomy, but accuracy is a population-level statistic that says nothing about the cost of any single failure. A 98%-accurate agent still fails on the 2% — and if that 2% includes wiping a production database or emailing the wrong customer a refund, the accuracy number was never the thing that mattered.
The right question is asymmetric, not average. It asks: when this specific action is wrong, what does it cost to notice, undo, and repair? Two actions with identical accuracy can warrant wildly different autonomy levels if one is trivially reversible and the other isn't. This is precisely the logic Amazon's Jeff Bezos popularized as one-way vs. two-way doors in his 1997 and later shareholder letters: most decisions are reversible (two-way doors) and should be made fast, by whoever is closest to the work, while a minority are truly irreversible (one-way doors) and deserve slow, deliberate, senior-level judgment. Applied to agents, the "senior-level judgment" step becomes a human approval checkpoint.
This reframing matters because agent failure modes aren't like traditional software bugs. As explored in the complete guide to AI agents, agents chain multiple decisions and tool calls together, so a single subtle misjudgment early in a task can cascade into an action with real-world consequences several steps later — an outcome traditional deterministic software wasn't built to produce.
Why Non-Determinism Makes This Urgent
Agents are non-deterministic by construction: the same prompt and same context can produce a different plan, different tool calls, or a different final action on two separate runs. That's structurally different from a workflow, where every branch is pre-specified and testable in advance. The distinction between agents and workflows is really a distinction in how much you can pre-verify an outcome before it happens.
When you can't fully pre-verify what an agent will do, you're left with two levers: reduce the odds of a bad outcome (better prompts, better context, better guardrails) or reduce the cost of a bad outcome when it happens anyway. Most teams over-invest in the first lever and under-invest in the second. Reversibility is the second lever, and it's the one that scales.
The One-Way Door / Two-Way Door Framework for Agent Actions
A two-way door action is one an agent can execute, observe the result of, and cleanly reverse if it's wrong — these are candidates for full autonomy regardless of the agent's measured accuracy. A one-way door action permanently alters state, data, money, or a person's trust in a way that can't be fully undone — these require human approval no matter how confident the agent's accuracy metrics look.
Bezos's original framing was about organizational decision speed, not software architecture, but it maps unusually cleanly onto agent action design because both problems share the same shape: you're deciding how much deliberation a decision deserves before it's allowed to happen. For a human decision-maker, that deliberation is a meeting or a memo. For an agent, it's a human-approval gate, a sandboxed dry run, or a built-in rollback path.
The Reversibility Classification
Before an agent is given any tool, classify what happens if it uses that tool incorrectly. Three tiers cover most real systems:
| Tier | Definition | Example agent actions | Default autonomy |
|---|---|---|---|
| Fully reversible | Undo is instant, free, and complete | Draft an email (unsent), generate a report, query a database read-only, propose a Jira ticket | Full autonomy |
| Recoverable with cost | Undo is possible but takes time, money, or manual cleanup | Send a Slack message, create a calendar invite, modify a non-production record, post a low-stakes social update | Autonomy with logging + fast-follow review |
| Irreversible or high-cost | Undo is impossible or disproportionately expensive | Send an email to a customer, execute a payment, delete a database record, deploy to production, modify legal/compliance text | Human approval required |
A sentence that keeps recurring in the drafts of this classification is: "well, technically you could undo it, it would just take..." — that phrase is the tell that an action belongs in the middle tier, not the top one. Undo that requires manual cleanup, a support ticket, or a customer apology isn't the same as undo that's instant and free, even though both are technically "reversible."
The Governing Rule
Grant full autonomy only to two-way-door actions; require approval for one-way-door actions — and treat "recoverable with cost" as its own tier, not as an honorary two-way door. This single rule does more to make an agent deployment safe than any amount of prompt tuning, because it moves the safety boundary from "trust the model's judgment" to "trust the architecture's constraint," which fails more predictably.
In practice this becomes a lookup, not a judgment call made at runtime:
- Enumerate every tool the agent can call, at the granularity of the actual API or database operation, not the vague capability name.
- Tag each tool's reversibility tier using the three-tier table above, with a named owner who signs off on the tag.
- Attach the autonomy rule to the tag, not to the agent or the task — the same agent can autonomously draft an email and require approval to send one.
- Re-tag when the tool's blast radius changes — a "create draft" endpoint that later gets a "and auto-publish after 24 hours" feature has silently moved tiers and needs re-review.
This is close in spirit to the safeguards described in agent action guardrails: guardrails constrain what an agent is allowed to attempt, while the reversibility classification decides how much oversight a given attempt requires before it's allowed to execute.
Optimizing for Cost of Being Wrong, Not Odds of Being Wrong
The core mental shift is to stop treating accuracy improvement and reversibility design as substitutes and start treating them as separate investments with different payoffs. Raising accuracy from 90% to 95% helps every action a little; making one high-blast-radius action reversible can remove an entire category of catastrophic failure regardless of the accuracy number.
This echoes a much older idea from reliability engineering: Charles Perrow's Normal Accidents (1984) argued that in tightly-coupled, complex systems, catastrophic failures are not rare anomalies to be engineered away entirely — they're statistically inevitable given enough operating time, so the design goal shifts from "prevent all failures" to "bound the damage of the failures that will happen." Nassim Taleb's writing on asymmetric risk makes a related point in a different register: when downside is capped and upside is open, you should take the bet often; when downside is uncapped, the odds barely matter. An agent action with capped, reversible downside can be allowed to run often, even imperfectly. An agent action with uncapped downside needs a gate, no matter how good the odds look on paper.
A Practical Cost-of-Wrong Calculation
For any action tier above "fully reversible," it's worth estimating cost-of-wrong along three dimensions before deciding on the approval threshold:
- Detection lag — how long between the wrong action executing and a human noticing it happened at all. A silently-wrong Slack draft is noticed in seconds; a silently-wrong database write may surface in a customer complaint weeks later.
- Repair cost — engineering time, support time, or manual reconciliation needed to fully undo the effect, not just stop it from continuing.
- Trust cost — the damage to a customer's, regulator's, or colleague's confidence in the system, which frequently outlasts the technical fix and is the hardest of the three to price.
None of these three map onto model accuracy at all — they're properties of the system and the blast radius, not the AI. That's precisely why they belong in the architecture, not in a prompt asking the model to "be careful."
Building Rollback Paths Into Agent Actions by Design
An agent action's reversibility is a property you design in deliberately, not an accident of which tool happened to be available — treat "can this be undone, and how fast" as a first-class requirement alongside "does this do the right thing." Three patterns cover most of the surface area.
Soft-delete over hard-delete. Any agent-triggered deletion should flag a record rather than purge it, with a retention window before permanent removal — turning what would be a one-way door into a two-way one at negligible engineering cost. Draft-then-commit for anything sent externally. An agent composing a customer email, a social post, or a payment instruction should write it to a staging state that a human (or a second automated check) reviews before the "send" action fires separately. Versioned writes over in-place mutation. Any record an agent updates should preserve the prior version, so "undo" is a revert-to-version operation instead of a best-effort manual reconstruction from memory or logs.
| Pattern | What it converts | Engineering cost | Where it applies |
|---|---|---|---|
| Soft-delete | Hard delete → recoverable delete | Low (a status flag + retention job) | Records, files, user data |
| Draft-then-commit | Instant-send → staged send | Medium (a review step + queue) | Emails, payments, public posts |
| Versioned writes | Overwrite → revert-to-version | Medium (append-only storage) | Configs, documents, database rows |
The pattern connects directly to how customers experience failure, too. Mapping where an agent action sits on a customer journey emotion curve usually shows that an error caught and silently corrected before the customer ever sees it barely registers, while the identical error surfaced to the customer — even if technically "fixed" afterward — leaves a dip in trust that a follow-up apology only partially repairs. Rollback speed isn't just an engineering metric; it's a proxy for how much of that dip the customer ever experiences.
How Prodinja Applies Advise-Then-Act to This Problem
Prodinja's own posture toward agent actions is advise-then-act: every action an agent proposes stays a proposal — visible, editable, and inert — until a person approves it. Nothing commits to a system of record on its own initiative. That's the reversibility principle taken to its logical extreme: if nothing executes without a human "yes," there's no undo path to design because there was never an unreviewed commit in the first place.
This is a deliberate design stance for the current prototype, not a claim about what any agent has autonomously produced — Prodinja's simulated critique layers (Stress-Test, Feature-to-Feasibility, and the Evals/Context/Agentic reviews) are built to walk a PM through how that proposal-and-approval loop is intended to feel, surfacing what a proposed action would touch before anyone approves it. The living PRD in Spec Studio follows the same shape with PR-style diffs and readiness gates: changes are visible, reviewable, and reversible by construction, right down to how a change gets proposed and approved.
Key Takeaways
- Classify every agent action by reversibility, not accuracy — a two-way-door action deserves autonomy even at moderate accuracy; a one-way-door action deserves approval even at high accuracy.
- Use a three-tier classification — fully reversible, recoverable with cost, and irreversible — and route only the first tier to full autonomy.
- Cost of being wrong beats odds of being wrong as the design metric, echoing both Bezos's one-way/two-way door framing and Taleb's asymmetric-risk logic.
- Re-tag tools whenever their blast radius changes — a feature addition can silently move an action from two-way to one-way door status.
- Build rollback in architecturally: soft-delete, draft-then-commit, and versioned writes convert many one-way doors into two-way ones at modest engineering cost.
- Estimate detection lag, repair cost, and trust cost for any action above the fully-reversible tier — these three don't move with model accuracy and belong in the system design, not the prompt.
- Prodinja's advise-then-act stance keeps every action a reviewable proposal, which is the reversibility principle applied to the point where nothing ever needs undoing.
Frequently Asked Questions
What is a one-way door decision in AI agent design?
A one-way door decision is an agent action that can't be fully undone once executed — deleting a record, sending a payment, or emailing a customer. These actions should require human approval before an agent executes them, regardless of how accurate the underlying model measures.
How do you decide which agent actions should run autonomously?
Classify each tool the agent can call by reversibility tier — fully reversible, recoverable with cost, or irreversible — and grant full autonomy only to the fully reversible tier. The classification should live at the tool level, not the agent level, since the same agent can hold both autonomous and approval-gated tools.
Does higher model accuracy justify more agent autonomy?
Not on its own. Accuracy is a population-level average, while the cost of a single wrong action is what actually determines the damage. A highly accurate agent with an irreversible action in its toolset still needs an approval gate, because the rare failure is the one that matters.
What's the difference between agent guardrails and reversibility design?
Guardrails constrain what an agent is permitted to attempt in the first place — scope, tool access, rate limits. Reversibility design governs how much oversight a permitted action requires before it's allowed to execute, and how easily its effects can be undone afterward. See agent action guardrails for the constraint side of this pairing.
How does reversibility connect to identifying real agent use cases?
Mapping a workflow through a jobs-to-be-done lens, as described in the complete guide to jobs to be done, often surfaces which steps in a customer's job are naturally low-stakes and reversible (drafting, sorting, summarizing) versus which are inherently consequential (committing money, notifying a customer) — a useful head start before formally tagging each tool's reversibility tier.