A payment agent needs a judged agreement, not a click on every step

Emil Chetty, who leads data and AI product at Wise, argued that payments need a different kind of control from coding agents. Speaking on the AI Engineer show, he said the human should judge one agreement for the whole job. The human should not approve each step along the way.

What was said

Chetty described what happened when AI assistants asked customers to confirm every action. "We ended up providing them with a queue of requests," he said. Engineers know the feeling from coding agents, where people end up watching the terminal instead of doing real work. In his words: "We ultimately made the human the API."

He credited coding agents with real progress. Permission rules, classifiers and sandboxes, he said, let engineers trust that an agent will not delete a production database. But he drew a line. A coding agent asks whether an action looks safe. A payment asks something else: "did this customer authorize this payment to this recipient on these terms?"

Better testing and a tighter harness around the model do not settle that, he said. Neither shows whether the customer agreed to the job. Wise needs both, but also an agreement the customer has locked in.

In his example, a business owner named Sarah asks an agent to pay three suppliers. The agent reads records with limited, read-only access. Wise's own trusted software fills in the suppliers, bank details and amounts. Sarah sees a draft, including which decisions she leaves to the agent. When she approves and authenticates, the draft becomes locked. Chetty summed it up: "What you approve is ultimately what we enforce."

Why it matters

Our reading: this moves human work from supervising steps to judging terms. The skill is reading one proposal closely and knowing what you are agreeing to. Clicking through a long queue does not build that skill.

For teams that build or buy agent products, the design question changes. Ask what record shows that a person agreed, and who checks the agent's actions against it. Chetty said his boundary "doesn't actually depend on the model spotting the scam." In his design, a tricked agent still cannot move money outside what the customer approved. Trust sits in software that checks terms, not in the model's judgement.

The other side

This is one company's account of its own design. The excerpts describe how Wise is thinking about the approach. They give no results on fraud, customer errors or how people behave when they face the agreement.

The model still depends on the customer reading the draft well. A person who skims one agreement is as exposed as one who clicks through many steps. Chetty did say that different terms need a revised proposal and a new customer decision, so approvals do not disappear. The excerpts do not show how often that happens, or how Wise keeps people from approving on reflex.