Stop Making Your Customers Click Approve - Emil Chetty, Wise

AI Engineer · 15 min · 159 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

00:01[music]
00:12Anyone here ever get tired of clicking approve on their coding agents, giving ChatGPT the permission to be able to scrape that websites, or even just giving Hermes the ability to be able to read your the MCP that you definitely told it it's a lot to read?
00:30Anyone in the room get annoyed?
00:32Sure.
00:32Now imagine that was the experience every time you were using an assistant that promised you to save you time, reduce the complexity in your life, and ultimately provide you value.
00:45Everyone in this room, the AI evangelists of the world, we promised our normies are sitting outside this room the an assistant, something that's going to reduce the complexity of their lives.
00:57But instead, when it hit reality, we ended up providing them with a queue of requests.
01:04So, hi.
01:05I'm Emil.
01:06Um I lead um data and AI product at Wise.
01:09And I'm going to be talking you guys through about how we're thinking about removing that complexity for our users, and trying to give an agent useful autonomy without making our customer the API.
01:22So, for those of you who aren't familiar with Wise, um which I suspect some of you might not be given the US-based audience, um we're a technology company that's building the best way to be able to move and manage the world's money.
01:35We have this vision of achieving money without borders, and making sure that people can manage their funds and lifestyle across multiple geographies and currencies.
01:47To do that, we've built three products.
01:49We've built the Wise account, and that's
01:51[snorts]
01:51helping regular people manage their life across borders, helping them spend like a local, and save like a local.
01:58The second is Wise Business, which allows businesses, small and medium-sized, to be global from day one.
02:05And the last is Wise Platform, which allows banks and other financial institutions to tap directly into the payments infrastructure that we've built over the last since 20 11, and provide a Wise-like experience
02:17directly to their customers.
02:19And to do this, we've built one single global payments network powered by over 90 different local banks and payment providers from across the world, and connecting directly into domestic payment schemes.
02:33And that network has proved really effective.
02:37Last year, we've moved over 243 billion in cross-border in cross-border volume, and we're serving over just nearly 19 million active customers.
02:49So, we know this this model scales.
02:53And to be able to do that, we hold more than 80 different licenses worldwide.
03:00And that has meant that in different currencies, different countries, different regulated entities, and different products all bring different requirements.
03:10And that doesn't disappear when we put a chatbot in front of it, unfortunately.
03:14Our regulators still expect us to know what a customer is authorized, control what happens to their money, and explain the outcome.
03:24So, how can we give an agent useful autonomy that is actually going to simplify our users' life, and still answer for what it does?
03:35So, here's what a typical job might look like that we might give to an agent.
03:39So, some small business owner might say, "Handle this week's approved payment suppliers, reconcile the results, and bring back the exceptions to me."
03:47The business wants the work handled.
03:49They don't want to coordinate every lookup.
03:50They don't want to coordinate every status check.
03:52And they want this to ultimately provide them with the ability to focus on what matters most to them, running their business.
03:59So, how do we So, how are we going to about achieving How are we going about achieving this?
04:05This might look very familiar to you if anyone's using agent relatively recently.
04:09You will have list of different approved steps.
04:11Checking whether or not you are can look up there the payment account details, checking whether or not you can scan a PDF in to be able to understand the
04:21the invoice, etc. etc. Took eight steps, probably some time in between to be able to get to something that was ultimately small.
04:32And so for the engineers in the room, this might look relatively familiar, right?
04:36In the If anyone can remember the before times and if you weren't using dangerously skip permissions, this is what coding agents used to look like.
04:44We have to go through and approve every step while watching the terminal, check your run your tests, sure, fetch that face first lady documentation from Confluence, sure, and click approve
04:54all the way through.
04:57We ended up having to watch the terminal instead of getting real work handled.
05:01[snorts]
05:02We ultimately made the human the API.
05:06So how did co-coding agents solve this?
05:09Anthropic came up with this idea of auto mode, right?
05:12And that meaningfully reduced the friction that we experience as engineers.
05:16Permission rules, classifiers, sandbox helped be able to introduce controls necessary for us to be able to trust the agent wasn't going to go delete our production databases.
05:27These controls matter.
05:29But a payment needs a different kind of answer to a different kind of question.
05:35Well, a coding agent is asking, "Does this action look safe?"
05:39What a payment is asking is, "Did this customer authorize this payment to this recipient on these terms?"
05:48So again, we're at an AI conference.
05:50You might say, "Cool.
05:51Let's Let's chuck some eval's at it."
05:53For those of you who are on the bleeding edge, let's say we can build a harness to be able to do this and embed the controls inside the harness.
06:01But unfortunately, it doesn't give us the answer to whether or not the customer actually agreed to this job.
06:09What we need is an agreement.
06:12We need something immutable that a customer has agreed to that allows the agent to operate from within those bounds.
06:21I'm not saying we don't need the emails, we don't need the harness, we're still going to need both.
06:26But what we don't want is that the model said this is what the customer wanted and authorizing that payment based on that.
06:35We want them to agree to the job, not every step.
06:42So, how we how are we thinking about this?
06:44So, the idea is we want to be able to go from intent to something that is immutable.
06:49So, we want something to be able to take that take the vague customer a prompt that we have, ingest that, have trusted verified software that we've built that we spent the last 25 years building, verify it,
07:04and show the customer a particular outcome, and have them confirm whether or not that is the bounds by which they want the agent to be able to operate within.
07:13We can then take that, embed that into our trusted the our trusted stack, and provision the authority based on what the customer agreed to.
07:25The agent can then plan and act as usual.
07:28Our services, which are actually executing that payment, can then check whether or not the the payment should be executed on.
07:34And the results and exceptions can get surfaced back to the user.
07:40If something needs to change, and that changes that fundamental agreement, we surface back to the user.
07:46But if the if something is changing that's not going to affect the payment terms, we can still go back and have the agent re-plan.
07:55So, a different plan can still stay within side that agreement.
07:58Different terms ultimately need a revised proposal and a customer decision.
08:04So, we need the customer to agree to the job, the agent to choose the steps.
08:09And our software to enforce that agreement.
08:15So, let's take a hypothetical example.
08:17Let's say Sarah, our business owner from before, sends this off to an agent.
08:22What does this ultimately look like?
08:25So, first, we take Sarah's credentials, and we take the the all the setup that Sarah's had, and we go gather the context necessary to be able to propose a job.
08:35So, first, the agent explores with limited read-only access all the information necessary to be able to close that loop.
08:43The trusted software that we've attached to the account actually resolves the suppliers, the bank details, the amounts from those records.
08:51And this preparation doesn't actually give the agent permission to be able to execute anything meaningful.
08:57We then surface that to Sarah.
08:59And here's the job that she'll see.
09:00She'll see this is the thing that we want to be able to do.
09:03This is like the three suppliers, $775 with around like some for the fees that she might have to pay.
09:11And this is the draft that she will see.
09:14What also gives What's also important is the balance in which the agent is able to operate in.
09:19So, the decisions that she's comfortable offsetting to the agent versus the decisions that she wants to be able to be um looped back into.
09:28Any missing or conflicting details need to be resolved before the before before the job gets um made immutable.
09:36And so, what this means is we have two views of that job.
09:38One is the thing that Sarah sees, which is the is the promise that we're making in human language.
09:45The second is what our services can see.
09:47And that's ultimately a machine-readable promise that we're making that allows our services to be able to verify that this payment is a is is operating within a specific set of bounds,
09:58and gives the agent very specific instructions in which to operate within those bounds.
10:03And so, when she clicks approve, that then becomes immutable.
10:08She confirms and authenticates, and her decision is recorded against that exact version.
10:13And that draft becomes an authorized job.
10:18What you approve is ultimately what we enforce.
10:21And that's how we're thinking about reducing the complexity.
10:25So, what happens next?
10:27So, we take that we take that confirmed job, and we give a trusted provisioning platform the ability to be able to provision access purely based on what's been approved.
10:38The code deterministically checks three things: the confirmed job, what wise permits the agent to do, and Sarah's current rights.
10:47And we look at the intersection between those, as long along with what the job has proposed to be able to provision limited access rights to an execution agent.
10:59Those then split out into two workers.
11:00One is a payment worker and a reconciliation worker.
11:03And those are what is going to be able to actually execute based on that job.
11:10This still allows the plan to be able to change.
11:12The agent is still deciding how to best achieve the job that has been provisioned to them.
11:19What does What doesn't is the agreement.
11:22And so, the flexibility that that we promised, the ability for a customer to be able to delegate the job instead of supervising that implementation, still remains.
11:32So, there's fundamentally two different loops, and this gives us some element of resilience here, right?
11:36So, let's say um the job needs to be retried for whatever reason.
11:39A Kubernetes pod needs to be restarted, and then the job or the app crashes on her phone, and she needs to be able to restart that job.
11:46Given that that job is immutable, and we're sharing that payment state, it's on a second payment.
11:53Services will share the ability to be able to um execute that payment, but also be able to look up what has already been executed.
12:02And so, the worker follows the existing payment job rather than creating another one.
12:05However, if they discover that a quote has changed later on, or quote might have expired, service that back to Sarah cuz she wants to know.
12:15Sarah approved that specific quote and the agent then will prepare an updated proposal but can't approve the replacement itself.
12:24And so we control Sarah what's changed, get her to agree to a new version.
12:29And within that arrangement, the agent still keeps working.
12:35So it's a rough like sketch of what we're trying of what we've done on a white so far is we have like our different gateways that ultimately allow for the provisioning of these agents and also the ability to be able to have that immutable job be it be be verified against our
12:52We have the very controlled routes to our LM providers and we have an agent gateway which ultimately provides mechanisms for our tools to be able to be registered but also be evidenced.
13:05So we follow that one payment through the gateway.
13:08The worker checks what what tools it can use.
13:11Executes that against the payment surface.
13:13And make sure that the bounds mode they're operating within still comply with the promise we made the user.
13:21That immutable job record.
13:25But let's say there's some nefarious actions happening, right?
13:28So suppo- suppose we get prompt we get it get it gets prompt injected somewhere and the an agent says pay our payment details is updated.
13:39And let's actually say that the agent actually believes it, right?
13:43It's belief itself can't change the confirmed job.
13:46So the new PA fails when the at the service check.
13:50And the agent can't rewrite its own agreement.
13:52So the boundary doesn't actually depend on the model spotting the scam.
13:56It depends on our downstream services supporting the ability to be able to check those but also enforcing on what we agreed.
14:05So the software stack that we built over the last since 2020 since 2011 is still the one that we're going to be relying on and it's still the one that's going to be remaining compliant
14:15for all of the orders in the room.
14:19So, what can we answer for?
14:22We know who authorized the job.
14:24We know what the agent can do.
14:26We know what happened when that payment went through.
14:30We know what we can stop.
14:32We ultimately know who who is responsible.
14:36And we know whether or not it's doing good work.
14:38And so, that one chain of evidence, we get everything we need to be able to allow for our customers to be able to reduce the complexity when using agents,
14:47but still make sure that that money is safe.
14:51So, there's one thing I want you to take away from this.
14:53If you want to introduce a new approval flow, if you want to introduce a new agent into your like into your stack, get the customer to agree to the job and delegate it out.
15:04Allow your agent to be able to choose how it wants to execute that job.
15:08Allow your services to be able to enforce that agreement.
15:12And that way, Sarah doesn't have to worry about needing to approve 100 different steps.
15:18So, please, stop making your hu- humans your agency API.
15:25Thank you.
15:26[applause]