Make stop actually stop

A buyer changes their mind halfway through and tells the agent to stop. The purchase happens anyway.

There are several reasons it can happen, and they are independent of each other, which is what makes this hard. The payment order may already have gone. The agent may be holding a credential minted an hour ago that stays valid whatever your database now says. A request may be on the wire, and nothing unsends an HTTP request. And the shop, which is the party about to take the money, may never be told anything at all.

There is a quieter version. The agent handed part of the job to another agent forty minutes ago, with a copy of its authority. You revoked the first one. The second is still working.

The thing worth noticing is that none of those failures is a bug. Each is a system behaving exactly as designed, and the design simply never had a defined answer for stop.

So the revocation that matters is not the row you changed in your own database. It is whether the purchase happens.

When permission is withdrawn, three different things end at three different times, and it is worth separating them because systems tend to be built as though there were only one.

The first is the authority between you and your agent. As a general matter that ends the moment you say so — and it is the least useful of the three, because it governs the one relationship where nobody is about to take your money.

The second is the payment. Payment law fixes a point after which an instruction can no longer be pulled back. Under Article 80 of the EU's payment services directive, a payment order generally becomes irrevocable once it has been received by the payer's payment service provider, subject to specific later cut-offs for cases including direct debits and agreed future execution dates.

Card payments have their own version of the same shape. There is typically a separate authorisation stage before clearing and presentment, and scheme rules provide mechanisms for reversing an authorisation when a transaction is cancelled or changed. The exact window depends on the scheme and on the transaction, so this is a clock rather than a single deadline. Either way it is set by the plumbing rather than by you, and it closes earlier than most people expect.

The third is what the merchant is still entitled to believe. This is C2's wrinkle given a control of its own. Ending your agent's actual authority does not by itself end the appearance of it. The appearance ends when it is no longer reasonable for the third party to believe the agent still has authority — which is to say it does not stop when you act, it stops when the other side has reason to know.

Line them up and the result is uncomfortable. Revocation is instantaneous in the place it matters least, fixed by someone else's deadline in the middle, and slowest exactly where the loss lands. A stop button that only does the first of the three is honest marketing for about one second.

One more thing is worth knowing before anyone promises a user an unconditional cancel. Ordinary agency authority is generally revocable, but there are narrow exceptions — notably a power given as security, historically described as a power coupled with an interest. The bar is higher than simply calling something irrevocable, and higher than the agent merely having an economic stake in going through with it. For a consumer shopping agent this is genuinely an edge case. It gets more interesting wherever authority is wrapped up in collateral, financing or an escrow-like arrangement, so it is worth knowing which kind you have built.

Do not hand the agent a credential with no way to call it back. A self-contained token — one a recipient can validate on its own, without asking anybody — has no built-in kill switch. Unless the parties checking it consult external revocation state, or have that state pushed to them, it stays usable until it expires. Issue a one-hour token and you have decided in advance that stop may take up to an hour.

This is not a niche observation. RFC 7009, the standard for revoking these tokens, says as much: immediate revocation of a self-contained token needs extra communication with the back end, short lifetimes are the alternative way to bound the exposure, and revocation can propagate with a delay that implementations are told to keep small. Short lifetimes and a check against live authority are most of the fix, and the cost is a lookup.

Make revocation a condition checked in front of the money, not a message sent to the agent. This is the same architecture as C2, for the same reason: an agent that has been told to stop is an agent you are trusting to comply, and the whole premise of C4 is that its instructions are not reliably yours. The check that counts reads the current state of the mandate at the point of payment.

Tell the counterparty, not only the agent. This is the single step that closes the third clock, and it is the one almost everyone skips, because it sits outside the happy path and nobody is asking for it. Anyone the agent has been dealing with under this mandate should be told it has ended.

Decide in advance what happens to work already in flight, and write it into the mandate alongside everything else in C1. There are only three answers — let it finish, abandon it, or reverse it — and the right one differs by category. A booking that can be cancelled free for an hour is not a custom order already in production. Choosing at the moment of panic means choosing badly.

Make revocation travel down the chain. If your agent can hand work to another agent, withdrawing permission has to reach the second one too. In the agentic-commerce specifications I have reviewed, I have not found a normative mechanism saying how revocation of an upstream mandate must propagate through downstream agent-to-agent delegations — the Agent Payments Protocol treats that kind of delegation as possible but currently puts it outside its own scope. Related machinery exists elsewhere: token exchange can represent a delegation chain, and a revocation server may, depending on its policy, invalidate related tokens along with the one presented. None of that is the same as an agreed cascade. Keep delegation chains short and explicit rather than assuming somebody has solved this.

Fail closed on doubt. If the system cannot currently tell whether a mandate is live, it does not spend. That is the same rule as C2 and it matters more here, because revocation tends to be attempted exactly when something has already gone wrong.

One number does most of the work: the gap between when the buyer said stop and when the last thing the agent could still do actually stopped. Revoked at 14:02, final action at 14:07, gap five minutes. That number is the control, and if nobody has ever measured it, it is not bounded — it is just unknown.

Alongside it: every attempt refused after revocation and what was attempted, and evidence that the counterparty was told, with the time.

The test is a rehearsal. Revoke a real mandate mid-task in a system you control and measure what happens. Almost nobody does this, which is why almost nobody knows their own number.

More concrete than most of this set, because payment law has had to answer the question of when an instruction becomes final since long before agents existed.

Article 80 sets the general rule described above, and card scheme rules handle the same problem through the gap between authorisation and clearing. Neither was written with an agent in mind, and neither needs rewriting for this control to bind: the deadline applies whoever pressed the button.

The framework is itself being replaced, and the successor is much further along without yet being the applicable rulebook. Parliament and Council reached provisional political agreement in November 2025, and COREPER confirmed the final compromise texts in April 2026. Formal adoption and publication remain outstanding as of September 2026, so the existing rules are still the ones to design against. This is the sort of claim that goes stale quickly, and the date at the top of this page is doing real work.

On the agency side there is no statute to point at, only the ordinary principle that ending an agent's authority is one thing and ending the impression of it is another. That principle is old, well settled, and almost never reflected in a product's cancel flow.

In the standards I have reviewed, I found no specified end-to-end deadline for how quickly a revocation has to become effective across everyone who might act on delegated authority, and no requirement to publish that latency. The nearest thing is the instruction in RFC 7009 to keep the propagation window small, which is guidance about a mechanism rather than a duty owed to the person pressing the button. Worth sitting with, because stop is the feature most likely to be promised on a marketing page and least likely to have been measured.