The irreversible action problem in autonomous agents.

Most agent failures are recoverable. You roll back a transaction, re-prompt the model, edit a draft, restart a process. The agent overspent its token budget. The agent picked the wrong API. The agent hallucinated a function name. These are bugs. They cost time. They don't cost trust.

A small fraction of failures are not recoverable. The email got sent. The wire transferred. The record was deleted. The deployment hit production. By the time anyone reads the agent's log, the world has already changed.

I don't think the field is talking enough about this category. Most alignment work is concerned with whether the agent picks a "good" action — values, helpfulness, RLHF, refusal training. That's a separate axis. You can have a perfectly aligned agent making a perfectly reasonable decision that you wish it hadn't made, and the cost of that decision lands outside any retraining loop. Irreversibility is the dimension where alignment failures become permanent.

This post is a taxonomy, and a proposal.

What "irreversible" actually means

Irreversible is doing two jobs in the literature, and they're usually conflated.

The strong sense — physical irreversibility — is when an action cannot be undone at all. A nuke fired. A patient injected. These are rare in agent workflows today. They will get less rare as agents move closer to physical systems.

The weak sense — practical irreversibility — is when an action can technically be undone, but the cost of the undo dominates the cost of the action. A mass email is technically sendable-then-deletable from inbox APIs. In practice, by the time you've discovered that the agent emailed 18,000 customers, the brand cost is done. The unsubscribe-and-apology workflow does not restore the prior state of the world; it produces a different (worse) one.

Most production agents don't deal with strong-sense irreversibility. They deal constantly with the weak sense. And the engineering culture around agents — fast iteration, rapid prototyping, "we'll fix forward" — was built around fully recoverable systems. It doesn't transfer.

A taxonomy

Here is the categorization I find useful in practice, ordered roughly by frequency in production agent stacks:

1. Communication-out. Emails, SMS, Slack messages, social media posts, customer-facing webhooks. The bytes leave your perimeter. Recovery is "send a correction," which is itself an action with its own cost.

2. State-destructive. Deletes, drops, truncates, file unlinks, rm -rf. The data is gone unless something separate — backup, version control, soft-delete — preserved it. Most production systems have only some of those mechanisms, only for some entities.

3. Financial. Transfers, charges, refunds, payouts, credit-line changes. Most have reversal mechanisms, but those reversals are themselves actions, often with windows (24-hour ACH window, T+1 for cards, etc.) and often subject to counterparty cooperation.

4. Permission-changing. Adding or removing access, sharing documents, revoking tokens, granting roles. Cleanup is possible. The window between change and cleanup is exploitable.

5. Public-record. Filings, registrations, regulatory submissions, press releases. Some are amendable; some are not; all of them create a record that is separately discoverable from your application's state.

6. Deployment. kubectl apply, terraform apply, schema migrations, package publishes. Some are rollback-able and some aren't, and "rollback" often means "roll forward to something resembling the prior state, with new bugs."

Notice that this taxonomy is not about technology. It is about which side of your trust boundary the effect lands on. Reversibility is a function of who has to cooperate to undo. Internal state: usually you can. External state: usually you can't, or you can but it costs more than the original.

Where current architectures fail

Most agent frameworks treat all actions as equivalent at the moment of execution. The loop is roughly:

plan → choose action → call tool → observe → repeat

The classifier — the thing that decides whether this particular action should run — is either (a) nowhere, (b) embedded in a system prompt as a list of "don'ts," or (c) implemented as another LLM call that asks the model to reflect on its own decision.

All three fail at the same point: they put the classifier inside the same model that produced the action.

This is the architectural mistake. It is the equivalent of asking a defendant to sentence themselves. The model that just decided to execute the action is the worst possible evaluator of whether that action should run. It already has the intent baked in. It will rationalize. It will under-classify. It will treat irreversibility as a procedural detail rather than a hard gate.

Empirically: models grade themselves generous. We see this in self-evaluation studies, in jailbreak research, in "reflect on your output" experiments. The model has access to its own latents and is biased toward justification of what it just produced.

The proposal

The classifier has to live outside the agent.

Concretely: every action proposed by an agent — every tool call, every function invocation, every API request — goes through an external classifier before the underlying capability fires. The classifier does not reason about values, ethics, helpfulness, or task completion. It reasons about one thing: what does this action do, and is it reversible?

The classifier is fast (under 5ms), zero-dependency, deterministic on the same input, and lives in the execution path — not as a sidecar, not as a logging layer, but as a hard gate between intent and effect.

import { classify } from '@reshimu/nesher'

const result = classify({
  action: 'delete',
  target: 'user_records',
  context: { count: 4200, environment: 'production' }
})

// result.level === 'CRITICAL'
// result.irreversible === true
// result.escalate === true

Three classification levels, three behaviors:

When the classifier sees a SAFE action — read-only, fully internal — it passes through with a green light.

When it sees a CAUTION action — writes with a clear rollback path — it passes through with a log.

When it sees a CRITICAL action — irreversible by the taxonomy above — it stops the call. The agent receives a structured response: classification, explanation, suggested escalation. The action does not fire until a human, or a higher-trust evaluator, releases it.

This is not a new pattern. It is how Stripe Radar handles fraud. It is how SQL transactions handle commits. It is how every serious deployment pipeline handles production releases. The new part is bringing it down to the action level inside an agent loop.

What we built

We have shipped this as an open-source library: NESHER. Zero dependencies. Works in any JavaScript or Python runtime. Drop it between your agent's planner and its tool-execution layer.

The name comes from the four Chayyot — the four living creatures of Ezekiel's Merkavah vision, which we use as an architectural pattern for runtime integrity validation. NESHER is the eagle: precision, vision, the call that has to happen before the action lands. If you want the full pattern, the depth essay Bearers of the Throne covers it.

NESHER will not catch every bad action. No classifier will. But it will catch the specific class of failures that the rest of your stack is blind to — the well-meaning agent action whose effects cannot be undone, in a system that had no checkpoint between intent and execution.

What this doesn't solve

This is a runtime safety primitive, not an alignment solution. It doesn't help with mesa-optimization, deceptive alignment, distributional shift, or the deeper failure modes that get researcher attention. It targets a narrower problem: a well-meaning agent taking an action whose effects can't be undone, in a stack that has no gate between intent and execution.

That problem is the most common live failure mode in deployed agent systems today. It is also the most embarrassing, the most expensive, and the most likely to make the front page when an autonomous agent screws up.

If you are building agents in production, install it. Tell us what we missed.