Rewind: Undo for agent payments.

AI agents are starting to make purchases on people's behalf. You can give them access to your money, set the rules, and let them handle everyday tasks.

But there is a gap. If an agent buys the wrong product, pays the wrong amount, or makes a decision you did not want, how do you question it or get your money back?

An agent can buy on someone's behalf, but nothing says who answers for it when the purchase is wrong. So I started from the people in the moment after, and what each of them needs.

Rewind had to work for both sides of a dispute, so I built three things: a way to understand what the agent bought, a way to question it, and a way for a bank to review the same evidence.

The customer and the bank needed to see the same purchase details. So Rewind is built around a single shared record: the person raising the dispute and the team reviewing it work from the same information, rather than from two accounts of it that have to be reconciled.

One journey: see what the agent bought, understand why it bought it, and say something when it was wrong.

1. See the purchase

   Agent payments sit in the ordinary feed with a small Agent pill on them. Nothing has to be hunted for, and nothing new has to be learned to find it.

2. Understand what happened

   The decision record lays out what was asked, the rules the agent was given, what it actually chose, and what was paid. Four lines, in that order.

3. Question the purchase

   Plain symptoms rather than dispute categories. Somebody who has just been charged for the wrong thing knows what went wrong; they do not know which of a bank's eleven reason codes it is.

4. Get an answer

   A clean mismatch refunds on the spot. A judgment call goes to a person with a 24-hour promise. Sometimes the charge stands, and the screen says why rather than going quiet.

7 screens

The app is only half of it, because somebody at the bank has to resolve the judgment calls. The instant refunds and the fraud handoffs never reach that queue, which is the point: the tool is supposed to cut a reviewer's dispute load, not add a new source of it.

Three of the four matched. The decision did not, and that one layer is the whole case: the agent stayed inside every rule it was given and still bought something its owner would never have chosen. That is the shape of almost every honest agent dispute, and it is why the record is four layers rather than one verdict.

Four calls shaped the product. Each one was about making the thing understandable rather than about adding to it.

Real products live or die in the states nobody demos, so these are the four I designed rather than the four I would have liked to skip.

The hardest part was saying no.

My first instinct was an authorisation layer: the thing that decides whether an agent is allowed to pay at all. That turned out to be already solved, by people with real infrastructure and more leverage than a designer. The actual gap was the unglamorous part nobody wanted, which is what happens after a payment goes wrong.

1. Trust needs context

   Showing what happened matters as much as showing the payment. A charge you cannot explain is a charge you cannot accept.

2. Design for both sides

   A good consumer experience is only half of it. If the reviewer's five minutes with a case do not get easier, a bank has no reason to adopt any of it.

3. Think past the happy path

   The abandoned draft, the duplicate, the refund that fails. Those states are where a payments product is actually judged.

If I did this again I would talk to a real disputes team early, because the whole product lives or dies on whether Priya's five minutes with a case get easier. And if agents are going to spend on our behalf, the recourse has to exist before the mistakes do.