Teamday
← Back

Wise's Emil Chetty: Approve the Job, Not Every Agent Step

AI Engineer
agentsenterprisesafetyautomationbusiness

How Wise Lets AI Agents Move Money Without Endless Approvals

Emil Chetty leads data and AI product at Wise, the cross-border money company that moved over $243 billion last year for nearly 19 million active customers through a network of more than 90 local banks and payment providers, under more than 80 licenses. His AI Engineer talk is about a problem every agent builder recognizes: an assistant that promised to save time instead hands the user a queue of approval prompts. Before auto mode, coding agents worked the same way. "We ultimately made the human the API."

Safe-looking is not authorized: Permission rules, classifiers and sandboxes made coding agents tolerable, but Chetty argues a payment asks a different question. A coding agent asks whether an action looks safe; a payment asks whether this customer authorized this payment to this recipient on these terms. Evals and a well-built harness are still needed, but neither proves the customer agreed. Wise's answer is an agreement: "We want them to agree to the job, not every step."

From vague intent to an immutable job: His example is Sarah, a small business owner who asks the agent to pay this week's approved suppliers, reconcile the results and bring back exceptions. The agent first explores with read-only access, while Wise's existing software resolves the suppliers, bank details and amounts from records. Sarah then sees a draft job (three suppliers, $775 plus fees) along with the bounds: which decisions the agent may make and which come back to her. Conflicting details are resolved before she confirms. Her approval is authenticated and recorded against that exact version. "What you approve is ultimately what we enforce."

Provisioning from the intersection: A provisioning platform then grants access in code, deterministically, from the intersection of three things: the confirmed job, what Wise permits agents to do, and Sarah's current rights. Execution goes to a payment worker and a reconciliation worker that work through an agentic gateway where tools are registered and every call is evidenced. The agent can still change its plan; it can't change the agreement. Retries are safe because the job and payment state are shared, so a crashed app or restarted pod resumes the existing payment instead of creating a second one. If a quote expires, the agent prepares a new proposal, but only Sarah can approve it.

Prompt injection hits a wall: If an injected message tells the agent a supplier's payment details changed, and the agent believes it, nothing happens: "Its belief itself cannot change the confirmed job." The new payee fails the downstream service check. Safety depends on Wise's payment services, built since 2011, enforcing the agreement, not on the model spotting the fraud.

5 Takeaways from Wise on Payment Agent Authorization

  • Approval queues defeat the point of agents - A business owner wants the payments handled, not to supervise eight lookup and status steps.
  • Separate the agreement from the plan - The customer approves terms once; the agent decides the steps; changed terms need a new customer decision.
  • Two views of one job - A plain-language promise for the customer and a machine-checkable version that services verify on every action.
  • Grant access deterministically - Access is the overlap of the approved job, platform policy and the user's live rights, computed in code, not by the model.
  • Keep the old stack as the enforcer - Regulators still expect Wise to know who authorized what, what happened to the money and who is responsible. Existing payment services answer that.

What Wise's Model Means for Agents That Act on Money

Chetty's rule generalizes beyond payments: get the customer to agree to the job, let the agent choose how to execute it, and let your services enforce the agreement. It is a stronger form of human-in-the-loop control, with one approval per job instead of one per step, and it pairs with per-agent identity. For the failure this design prevents, see Speakeasy's Sagar Batchu on an agent with valid keys but no valid intent.