Stop Making Your Customers Click Approve - Emil Chetty, Wise
Emil Chetty of Wise explains how the company lets AI agents handle customer payments without turning customers into approval queues. The core idea is a locked customer agreement covering the whole job, agent-chosen execution steps, and existing payment software that enforces the terms, even when an agent is manipulated by a prompt injection.
Replacing approval fatigue with a locked agreement
AI assistants were supposed to reduce complexity, but in practice many have turned customers into an approval queue. Anyone who has clicked approve on every step of a coding agent knows the feeling. Emil Chetty, who leads data and AI product at Wise, argues that payments need a different model: the customer agrees to the job once, the agent chooses how to execute it, and the company’s existing payment software enforces the terms.
Why payments are different
Wise moves money for nearly 19 million active customers. Last year it handled $243 billion in cross-border volume through a single global payments network, built since 2011 and connected to more than 90 local banks, payment providers, and domestic payment schemes. Its three products are the Wise account for individuals, Wise Business for small and medium-sized companies, and Wise Platform, which lets banks and financial institutions tap into the same infrastructure. All of this runs under more than 80 licenses. Each currency, country, regulated entity, and product brings its own requirements, and putting a chatbot in front of that does not remove them. Regulators still expect the company to know what a customer authorized, control what happens to the money, and explain the outcome.
Coding agents went through a similar arc, from approving every terminal command to auto modes backed by permission rules, classifiers, and sandboxes. Those controls answer the question ‘does this action look safe?’ A payment has to answer a narrower one: did this customer authorize this payment, to this recipient, on these terms? Evals and harnesses remain necessary, but they cannot supply that answer. What is needed is an agreement the customer has actually accepted, within which the agent operates, rather than a model concluding that the customer probably wanted something.
From intent to a locked agreement
The approach is to turn a vague request into something immutable. Trusted software ingests the customer’s prompt, verifies it, and presents a concrete outcome. The customer confirms the bounds, and that confirmed version is provisioned as authority. The agent then plans and acts freely inside those bounds, the execution services check each payment against the agreement, and results and exceptions return to the customer. A change that touches the core terms requires a revised proposal and a new customer decision. Re-planning that stays within the agreement does not. The division of labor is simple: the customer agrees to the job, the agent chooses the steps, and the software enforces the agreement.
A worked example
Consider Sarah, a small business owner who asks an agent to pay this week’s approved suppliers, reconcile the results, and bring back any exceptions. The agent first explores with read-only access. Trusted software resolves the suppliers, bank details, and amounts from the account’s records, so the agent gets no meaningful execution permission at this stage. Sarah then sees a draft covering three suppliers and roughly $775 plus fees, along with which decisions the agent can make on its own and which will come back to her. Missing or conflicting details must be settled before the job is made immutable.
The same job exists in two forms. Sarah sees a promise written in human language. Services see a machine-readable version that defines the bounds and gives the agent specific instructions to work within. When she approves and authenticates, her decision is recorded against that exact version, and the draft becomes an authorized job. As Emil puts it, what you approve is what we enforce.
Provisioning access from the approved job
Provisioning deterministically checks three things: the confirmed job, what Wise permits the agent to do, and Sarah’s current rights. Access is granted only where all three intersect, and it is split between a payment worker and a reconciliation worker. The plan stays flexible while the agreement does not.
Retries rely on shared payment state. If a Kubernetes pod restarts or an app crashes mid-job, the worker picks up the existing payment rather than creating a second one, because the services can see what has already executed. If a quote changes or expires, the work goes back to Sarah, since she approved that specific quote. The agent can prepare an updated proposal, but it cannot approve the replacement itself, and the rest of the work continues in the meantime.
Architecture and enforcement
The system is built from several gateways. Provisioning gateways issue agent access and verify the immutable job record. Controlled routes handle calls to LLM providers. An agent gateway registers tools and keeps evidence of their use, so a single payment can be traced end to end. The worker checks which tools it may use, executes against the payment surface, and confirms it still complies with the promise made to the user.
The design also holds up under prompt injection. Suppose an injected instruction convinces the agent that a supplier’s payment details have changed, and the agent believes it. That belief cannot alter the confirmed job, so the new payee fails the check at the service layer. The boundary does not depend on the model spotting the scam. It depends on downstream services enforcing what was agreed, and the agent cannot rewrite its own agreement.
What can be answered for
The resulting chain of evidence answers the questions regulators and operators ask. It shows who authorized the job, what the agent is allowed to do, what happened when each payment went through, what can be stopped, who is responsible, and whether the agent is doing good work. That single chain is what allows customers to delegate complex work while keeping the money safe.
For anyone introducing an agent into an approval flow, the takeaway is to get the customer to agree to the job and delegate it, let the agent choose how to execute, and have services enforce the agreement. Sarah should not have to approve a hundred steps. Stop making humans the agent API.