Every Rule Held. That Was the Problem.

Two pieces ago I argued that agent guardrails are usually installed in the wrong place. One piece ago I argued that what belongs on-chain is not the rule but the attestation that the rule ran.

Both arguments share an assumption, and I have been making it as loudly as anyone. The assumption is that the failure we are defending against is the unauthorized one.

It is not. Or rather, it is the cheap one.

Key Takeaways

• The expensive agent failure is not the unauthorized action. It is the fully authorized action that was still wrong.
• Every operation an agent performs goes on the stack. Not one of them writes an inverse.
• Agent payment rails inherited finality from protocols designed to meter cheap API calls, then grew into transactions where that assumption no longer fits.
• A reversibility budget meters exposure to irreversible state, alongside the spend limit that meters loss.
• Escalate on reversibility class transition, not on transaction size.
• Idempotency keys must be derived from the mandate at the signing layer, never minted by the model.

The failure that passes every check

A procurement agent has a mandate. Counterparty whitelisted, per-transaction limit set, chain and rail specified, identity resolved, policy evaluated before the signer is ever asked. This is the architecture I have spent two articles arguing for and I still believe in every part of it.

The agent pays the wrong supplier. Not a fraudulent supplier. A real one, on the whitelist, for a real invoice, at the correct amount, that a human somewhere already paid last Tuesday.

Every check passed. The evaluation was fast and correct. The attestation is clean and will hold up in an audit, which is exactly the problem, because what it attests to is that we did this on purpose.

Now find me the button that sends it back.

There is no button. There is an email address, and a human who will read it in four hours, and by then the agent has run the same loop nine hundred more times because nothing in its world told it to stop. The guardrail did its job. It has no opinion about what happens next, because we never gave it one.

Every serious piece of software written in the last forty years has an undo stack. Not because the software is careful, and not because it holds a copy of every state it has ever been in. Undo works because each operation, at the moment it runs, writes down its own inverse. The stack is not a memory of the past. It is a ledger of reversals, composed forward, one entry at a time, by operations that have not failed yet and are quietly preparing for the possibility.

We have built an economy of autonomous actors and given it no such ledger. Every operation goes on the stack. Not one of them writes an inverse.

And the thing about an undo stack is that it unwinds only as far as the first operation that skipped that step. Everything above that point is stranded. Permanently, regardless of how good your logging was.

Policy answers permitted. It does not answer right.

None of this is a private observation, and I want to say so before I say anything else. The question of what happens after an agent-initiated payment goes wrong has been circling the ecosystem for months and I read most of what comes past. Legal commentary on whether agency law even reaches an actor that cannot consent. Merchant-side writing on return policies that quietly assume a human made the decision. Protocol threads arguing about whether recourse belongs in the rail or above it. Fraud teams describing abuse that never trips an alarm because every individual action was inside policy.

Nobody is missing this. What I have not seen is a proposal for where the reversal primitive actually lives, and that happens to be the layer I spend my days in, so I would rather add to the pile than nod at it.

Gadi Lavi published a paper in April naming the core of it precisely, and it is the most useful framing I have come across on agent execution. He calls it the pre-action legitimacy gap: the case where a decision is authorized by role, compliant with explicit policy, scored low risk, and still structurally invalid in context. His argument is that legitimacy is a feasibility boundary rather than a score, and that no amount of positive signal can compensate for a missing required condition. High confidence cannot buy its way past a failed structural check.

He proves the non-equivalence, positions the boundary against authorization and safety and runtime governance, and then does something I find admirable and slightly maddening. He lists reversibility as an example of a constraint category and declines to define any of the constraints, on the grounds that the paper is about the boundary rather than the implementation.

So the boundary exists and it is empty. Someone has to fill it.

I would like to argue that reversibility goes in first. Not because it matters more than identity binding or authorization or observability or human escalation, all of which the ecosystem is building hard and building well. Because it is the one nobody is building at all. An empty slot in a non-compensatory boundary is not a gap in the system. It is the system, failing quietly, with a clean audit trail.

We inherited finality without inheriting reversal

Here is the structural fact underneath all of this, and it is nobody's fault.

x402, the HTTP-native payment protocol that most agent-to-service settlement now runs through, is non-reversible by design. No chargeback path, no dispute window, no merchant pull-back once settlement confirms. That was the correct decision for a protocol metering API calls at thirty cents, where the dispute costs more than the transaction and the counterparty is a rate limiter. The spec says as much and tells implementers to architect refunds at the application layer if they need them.

Then the stack grew. The same rails that were metering inference calls started buying compute, then data, then services, then things that arrive in boxes. Somewhere in that expansion we stopped metering and started transacting, and the finality assumption came along for the ride because nobody wrote it down as an assumption.

Card networks did not start with chargebacks either. Reversibility was bolted on over decades, mostly under regulatory duress, mostly because fraud made the alternative unworkable. Which means the reversibility machinery in commerce today is not a property of the wire. It is an obligation, issued by a network, to a merchant, at onboarding, priced by underwriting that merchant.

That distinction is the whole essay.

Where I part ways with the credit-first argument

Noah Levine wrote a piece in March that I have been chewing on ever since. His claim is that cards will keep winning agentic commerce because cards do not just move money, they extend credit and guarantee fraud protection with chargeback rights, and stablecoins can do the first thing and not the rest. His example is a hotel room that is nothing like the listing. With a card you dispute. With a stablecoin the money is gone. His conclusion is that stablecoins win in the gap where processors cannot justify underwriting the merchant, because a tool with no website, no entity and no track record is genuinely hard to underwrite, and he is completely right that this is the gap.

I think he is right about the mechanism and wrong about it being permanent, for one reason.

You do not have to underwrite the merchant if you can underwrite the transaction.

The chargeback right is an obligation that has to be issued by somebody. Card networks issue it centrally, at onboarding, against corporate history, which is why the long tail cannot reach it and why it took sixteen years to write the payment facilitator guidelines. But an obligation can also be issued per transaction, signed by the counterparty at authorization, collateralized by stake or by an identity that carries a track record rather than by a certificate of incorporation.

That is not a worse chargeback. It is a chargeback with a different issuer, and the issuer is the party actually in the transaction.

Three things that have to exist

Reversibility as a required constraint, not a risk factor

Classify every action by reversibility class before execution, not by value.

Then give the mandate a reversibility budget alongside its spend budget, because those are different quantities and today only one of them exists.

Spend limits bound how much an agent can lose you. Nothing today bounds how much it can lose you permanently.

Denominate the budget in exposure rather than in spend. It is the maximum value the agent may be holding in irreversible state at any moment inside the mandate window. An action against a live refund obligation consumes nothing while that obligation stands. It consumes the full amount the instant the obligation expires unexercised or gets refused. A genuinely irreversible action consumes its value on execution and never gives it back.

The property that makes this a budget rather than a limit is that it replenishes. The same agent on the same mandate can move fifty thousand dollars through counterparties carrying reversal obligations and two hundred through ones that do not, and neither number is arbitrary. Both are the same constraint doing its job.

What you are actually metering here is undo depth. How far back the stack unwinds before it hits the first operation that never wrote an inverse.

The second dimension is time, and it is the one I keep underestimating. A reversal window you cannot act inside is not a right, it is a decoration. If a counterparty offers two hours and your anomaly detection runs on a daily review, that transaction is irreversible and your ledger should say so out loud. Effective reversibility is a function of the obligation, the remaining window, and your own detection latency. Only the third term is under your control, which means the cheapest way to buy back reversibility budget is not negotiating longer windows with counterparties. It is noticing faster.

This also inverts escalation, which I think is the practical payoff. Right now we escalate on ticket size, because we inherited that reflex from card fraud where value correlated with harm. In agent workflows it does not. A twelve dollar irreversible action deserves escalation. A four thousand dollar action against a bound refund obligation does not. Escalate on class transition, not on magnitude.

A reversal obligation signed at authorization time

AP2, Google's agent payments protocol and the closest thing we have to a standard for binding an agent's action to a human's authorization, has an Intent Mandate, a Cart Mandate, a Payment Mandate, and a Receipt. Verifiable Intent, which Mastercard and Google shipped in March, links identity and intent and action into one record and points out that when a dispute occurs the parties rely on that audit trail to resolve it. That is genuinely the closest thing in production to what I have been arguing about attestations, and I want to be precise about where it stops.

An audit trail establishes what happened. It does not obligate anyone to do anything about it. Every mandate type we have is forward-facing. Nobody has signed the reverse path.

The inverse has to be written when the operation runs. That is the entire trick of the undo stack, it is not a hard trick, and it is the step we skipped.

So sign it. At authorization, before execution, the counterparty commits to five things:

1. The window in which a reversal can be initiated
2. The machine-checkable conditions under which it must be honored
3. The destination the value returns to
4. The compensating instrument, whether that is a refund, a credit, an escrow release, or a slash
5. Who bears the cost

The dispute right becomes a property of the authorization rather than a property of the rail, which means it stops being something you can only get by being large enough to be underwritten.

The first objection is latency, and it is a fair one. The whole appeal of x402 is a single request-response loop, and a negotiation round trip before every call would break the thing worth having. It does not need one. The server already returns a payment requirements envelope in its 402, carrying scheme, network, asset, recipient, amount, expiry. Those are terms it publishes, not terms it negotiates. Reversal terms belong in the same envelope, as terms. The agent side already carries a signature. Nothing new crosses the wire except fields.

The second objection is capital, and it is better. A merchant charging three tenths of a cent per call cannot post collateral against reversals without destroying the unit economics that made the business possible, and a framework that demands it has quietly rebuilt the payment facilitator it was trying to route around. Two things fall out of that. Collateral does not have to be capital: for the long tail it should be registry history, which costs nothing to hold and everything to lose, and which is exactly the asset a merchant with no entity and no credit file can actually accumulate. And obligations should net across a settlement window rather than bond per call, which is a boundary the ecosystem has already drawn for gas reasons and can reuse for this one.

The more honest answer is that at three tenths of a cent, reversal is probably not worth having, and I would rather say that than pretend the framework covers everything. A reversibility budget does not demand that every transaction be reversible. It demands that irreversibility be metered. Cheap calls burn cheap budget. That is the system working, not the system conceding.

And the destination problem has an answer already sitting there. An agent that paid with a session key may not have that key next week. ERC-8004, the Ethereum standard that gives an agent a durable on-chain identity with a queryable track record attached, mints an agent card carrying a payment address. That is where the refund goes. The Validation Registry is still explicitly a design space, which makes this a good moment to argue that reversal requested, honored, and refused belong in it as recordable events. An agent that honors reversals should accumulate something worth more than a bond.

Idempotency keys the model cannot touch

Small point, largest blast radius. Viraj Bandara wrote up an incident where an agent retried the same operation seventeen times in ninety seconds, each retry carrying a different idempotency key because the LLM had rephrased the parameters, producing hundreds of duplicate charges while a perfectly good idempotency layer sat there being useless. His conclusion is that idempotent agents are impossible because the contract assumes a deterministic caller.

They are impossible if the model mints the key. Derive it instead from the mandate. Agent identity, mandate ID, operation class, target, sequence position, hashed. The signing layer issues it and the model never sees it, so rephrasing produces the same key, because the key was never a function of the phrasing.

Tuesday, again

Same agent, same mandate, same invoice a human already paid.

The 402 comes back carrying reversal terms alongside the payment terms. Seventy-two hour window, refund owed on duplicate execution against a repeated mandate key, destination the agent's registered payment address. The action classifies as compensable rather than irreversible, so it consumes no reversibility budget while that obligation stands, and the agent proceeds without escalation, which is correct. Nothing here is asking a human to look at a routine supplier payment.

The idempotency key was minted by the signer out of the mandate rather than by the model out of the parameters. So when the loop comes back around the ninth time, it is the same key, and the ninth call is the same call, and nine hundred duplicates never happen.

It still gets to two. The first duplicate was a genuinely new payment against a genuinely stale intent, and nothing in this stack catches that, because the invoice was real and the supplier was real and only a human knew about Tuesday. But the predicate fires on the second, the obligation is live, the window is open, and the money returns to an address that still exists next week.

That is not a system that cannot fail. It is a system whose failures have a floor.

The part I cannot solve

Machine-checkable is doing an enormous amount of work in that list, and I want to be honest about how much.

It holds for a specific class of facts, and the class is larger than it first looks. Non-delivery. Timeout. Error class. Schema violation. Duplicate execution against the same mandate key. Settlement with no corresponding fulfillment signal. The rail already observes every one of these, which means the predicate needs no oracle and no validator set, only a rule over data the protocol was collecting anyway. The scenario I opened with, a duplicate payment to a whitelisted supplier, sits squarely inside that class. That is not a coincidence. It is where most production incidents actually live.

It falls apart the moment the dispute is about quality. An agent buys an inference call and the output is confidently wrong. An agent buys a dataset and the dataset is stale. No signature, no registry, and no quantity of stake resolves that, because the disagreement is not about whether something happened. It is about whether what happened was any good, and that is a judgment, and judgments need judges. The Validation Registry gestures at re-execution and zkML and crypto-economic validation, and each of those works for deterministic outputs and none of them works for subjective ones. I do not have an answer here. I am reasonably confident nobody does, and I am suspicious of anyone selling one.

The second limit is enforceability, and it is sharper. A signed reversal obligation from a counterparty with no legal existence is worth precisely what its stake and its reputation are worth and not one rupee more. Cryptographic commitment does not replace legal enforceability. What it replaces is underwriting, which is a real and valuable thing to replace, and I should not inflate it into more than that. For a pseudonymous merchant the only enforcement available is economic, economic enforcement has a ceiling, and above that ceiling you are back in courts and entities and all the slow machinery we were hoping to route around.

Then there is arbitration, which I have skipped entirely. Who decides a contested reversal, under what evidentiary standard, inside what SLA, is genuinely open and probably its own essay. GenLayer shipped an internet court with AI validators this month, which is either the start of an answer or a very interesting way to discover the failure modes. I am watching it with more hope than confidence.

What we are chasing

I do not think any of this is solved, and I would rather say that plainly than pretend otherwise.

At Abstraxn we build the layer that sits between an agent and its signer, which means we are already holding the thing that would have to enforce a reversibility budget and mint a mandate-derived key. Whether that layer should also hold reversal authority is the question we are working on now, and the honest answer is that we do not have it yet. Remediation authority and policy authority almost certainly have to be authored together, because the alternative is two systems that disagree at exactly the moment you need them to agree. That much I am confident about. The rest is open.

What I am sure of is that we have put autonomous actors onto rails with no undo stack, and that we are about to find out in public what that costs.

There will be exploits. There will be prompt injection and leaked session keys and credential misuse and every failure we already know how to name, and we will handle those, because handling those is what the last two years built.

The one that changes how this industry builds will not look like any of them. It will be a thousand transactions that every single guardrail approved.

FAQ

See the layer between an agent and its signer on the Abstraxn dashboard