Stop Chatting With Spreadsheets — Francesco Galletta & Felippe Felisola Caso, Monzo Transcript, AI Summary & Key Points

00:00 Morning. [music] Thanks everyone for being for being here and welcome to AIE. I guess first first session for everyone and for us as well. >> So h we wanted to introduce ourselves and tell you about what we're going to discuss. We think we need to stop talking with spreadsheets. So, this is all going to be about building a financial analyst harness that you can actually trust.

00:37 We are Franchesco Filipe. A little bit of a quick introduction about me. I'm originally from Venezuela. I lived in the UK for about seven years and recently moved to Madrid. H I work at data and I work at a bank as well with Felipe. Erh. I like just finding the best eeries in any city that I visit. So if you have any recommendations for New York, I'm more than happy to take them and just travel around.

01:01 And the reason my hobbies sound so vanilla is because I just spend most of my time building stuff and nerding out at the expense of my personal time. So that's how you end up with a list like that. Uh and then nice. All right. Um happy to meet everyone. Um also quick intro. I'm Philipe. I'm originally Brazilian. Um, I also moved to the UK. It's been a year and a half now.

01:25 So, it's been a fun journey. Um, life turned pretty much upside down. But, yeah, it's good to be it's good to be there. Um, I like to tell a story that before going to to decide whether I wanted to do it in university, I used to play piano for like literally seven hours a day. Um, and the natural decision there was to then study electrical engineering because who wouldn't, right?

01:46 Um, I ended up at some point landing in in data because someone showed me something that at the time called uh Google Data Studio. Now it's Looker Studio, but now they went back. I don't I don't even know what's going on. Um, and then my first dashboard looked like a papyrus of how vertical it was. You had to scroll scroll scroll scroll scroll down to see something.

02:05 Um, but yeah, the the rest is history. So I worked at a lot of um startups and small teams and scaleups. Um and then eventually went to a big company at New Bank. Maybe some of you do know um and then before going back to to Monzo which is I would say a middle turn between a scale up and a big enterprise company but it's growing uh so fast for now. Um and yeah most of my time currently has been working at Monzo with building internal AIdriven solutions for internal productivity primarily for the data team.

02:36 So, we basically want to get our data team better by um building with AI. Um and yeah, when I'm not talking to robots and agents, uh you can probably find me climbing somewhere um either in nature or in a gym. Um and some starting like points of why are we bringing this for you today? I think um both Franchesco and I worked in data teams in financial services.

03:02 So again, Monzo, New Bank and a few other companies in the in the sector. Um, we're now pushing what AI can do there. Our team at Monzo has been um, working a lot with with adopting AI from an impact perspective. We don't want to be like token maxing. We don't want to be spending a lot of money if that doesn't bring us like concrete business value. Um, so the adoption is very very deliberate and we've been seeing very good results on that.

03:25 And on the flip side, this is something also something we've been we've been doing, Franchesco particularly is applying AI to make our lives easier. Um and again not through the approach of I'm going to set up an open client instance nothing against it um and just give it connections to everything but actually what are the things that I care about in my life that I can um get the help of AI to to u make easier.

03:50 So this is why we say we're not representing Monzo um in this example because we're going to use the knowledge we bring from Monzo but uh build with you an example where we can um actually see that in practice without having to discuss a lot of domain knowledge. Um but if you are curious about the things we are building at Monzo we have a breakout session tomorrow um where we're going to talk about agent chip which is our inhouse remote agent capability.

04:17 Um so with that Franchesco back to you. >> Cool. So, as a reminder, today the goal is trust and it may seem a little bit counterintuitive because it feels very wishy-washy and this is a workshop and you're supposed to be coding really hard for two hours. H but you're going to see we're going to give it a little bit of a spin. Uh because I think we're past the point of having to spend hours like grinding through your keyboard uh to get something that you can trust.

04:46 So, let's start with the domain. Finance is tailored. You have your numbers. You have your strategy. Sometimes you don't really have a strategy. And there is the knowledge that you have on finance, on your personal situation and so on or generally misconceptions. H when we talk about a financial analyst, there is a very specific job description. We are being a little bit generous with that job description.

05:14 So it's going all the way from doing research for investments, investment firms, banks and so on all the way to like personal use cases as well. But finance is finance, right? So right now the gap on producing something, getting hold of your finances, doing an analysis is not really speed. H I'm pretty sure some of you may have some background tasks running with like claude or chpt getting some stuff done.

05:42 So that's not the bottleneck. H we believe that based on the experience we had over the last few months, the bottleneck now is how it connects with us. Um so trust is the thing we cannot take for granted and transparently because we're talking about money specifically. Erh this is one of the highest stakes topics uh we need to invest in making sure that there is trust built into the system and transparently if money is not high stakes enough for you and you can like oneshot your money problems your budgeting your

06:21 financing everything else h find me after the workshop I will buy you in into some investment ideas so yeah let's chat later please um so where everything starts is from the goal which is earning the trust. So then you can truly delegate the boring work to multiple agents, your swarms, your factories, whatever. But how you do trust the results that you're getting.

06:49 Erh, I'm going to namerop a few things because honestly none of them are new. You're probably already grinding thinking well you buy trust by h setting up traces or doing loops or any of the other keywords we have. So unit testing that gets old planning with your agent we know that that's good. Uh doing evals for sure traces and observability loops and graphs like I can keep naming components of how you think you can start building trust but they are basically components.

07:23 Erh what we want to discuss today is actually the design principles on how to achieve that trust. So building a hardness that actually h works for money matters h requires an in im immense amount of trust. So we're not going to be discussing specific technologies. We're not going to read you the readme of a particular product and we will assume you know some of the concepts that have been listed so far.

07:52 Um and mainly this is going to be a slightly different workshop because we want you to feel how the principles work in reality. So we have built a hardness today around a very simple example and we want you to try it out but don't focus on oh if I type this then I get the response so much quicker and the UI is so slick. It spoiler it won't be. Erh but more importantly we want you to feel how it may feel like having trust in an agent that has been built with a very specific hardness.

08:27 Uh so again this is just one very simple implementation an example h you can roast me later if you think this is too top level but we can discuss that later. So trust and I'm probably going to run out of times I can say trust without going insane but we think you need to build it from the ground up right. So you have a shared domain, the whole thing about a plan, making sure that you and the model are talking in the same terms.

08:55 And it sounds more trivial than it actually is. Then consistency and pretty sure everyone in the room will be on the same page, but it's making sure that the numbers come from a correct place. So rather than a language model trying to process a lot of arithmetic, it will do some tool calling. It will write us some scripts. It will try to come up with a way that the results are uh consistent.

09:18 We also want evidence where basically show the receipts, right? You can follow back and trace back the decisions and what led to them. Accountability is probably a very spicy one and maybe the mo most abstract of them, but ultimately even if you're running a 100 agents, the results of what they do, you're still accountable for them. So that's something we take very seriously at work.

09:49 And we think it's a mindset shift that when people make it, they start building systems that evolve with them and not black boxes that they just throw problems at. hoping that something sticks. And finally, verification. So, we want to make sure that there is a separate point of view, another perspective. H I would say I'm guilty of thinking I have the best idea in the world probably like three times a year and then only to have Filipe tell me, please don't implement that.

10:23 Please, please, please. >> And I I Oops, one second. And I would just compliment on on this bit that I think two things. The first one is we have a very generous window here to to work together. So um it will be very nice to learn from your folks's experience as well as we build through this principles. So if this resonates with any work you've done or any particularly any challenges you've faced um when working with agents feel absolutely free to to raise that and then we can we can build it uh together.

10:54 Um and just dunning uh doubling down on something that Franchesco said this we're not saying this is the model you won't say us going to to the big stage and saying forget everything you know this is how to do it this is a model a way to approach it uh that has been working for us in a number of use cases I'll share a few examples at Monzo later and Francisco has a few other examples as well um but yeah again there's not a single silver bullet to to solve every single problem we And also feel feel free to challenge us.

11:27 If you think actually trust overrated just throw a 100 agents at a problem eventually will get solved. Happy to hear the success stories. H but from repetition from experience and a lot of different use cases at work and outside. We do think you need to build a system that gives you the confidence that things are going in the right direction and not just that things look correct.

11:53 So yeah, trust. Happy days. Um, speaking of trust, I'm here to confess that I have an ulterior motive with today's workshop. Uh, so breaking your trust immediately. What is it? Less than five minutes. You are here to help me, Francesco, to plan my wedding. So nobody's super excited, but you will get excited. uh specifically just to figure out some some stuff around the finances of paying for a wedding.

12:25 Um and because it's a conference, I want to make it as cringey as possible. So, show of hands. Uh who has had a wedding? Who's gotten married? Okay, awesome. Number of guests under 50. >> Yeah. Okay. No, still show of hands. It's still like cringey mode. Okay, cool. >> About 100. Yeah. Nice. How about 150? >> Okay. >> Nice. 200. >> More. All right. >> Yeah.

12:58 Yeah. Big wedding. Nice. This is probably going to resonate, but it sounds like it's going to be a very simple calculation, very simple process, and the wedding is going to go by nicely and smoothly. And for the people who got married, probably you know that is not the case. Um, and even running the calculations and figuring out how things got so expensive so quickly.

13:20 It's not trivial. This is a little bit of storytelling. And hopefully my girlfriend doesn't fiance doesn't see this, but we were doing some calculations and she was like, "No, yeah, but the cost per like dinner is this much." And I'm like, "Yeah, and you have another two variable costs on top of that. So that's not the number." And anyway, budgeting for this has been a challenge to underelling it a little bit.

13:48 I wouldn't recommend doing it, but you know, I'm already on the train. Erh, so today you're going to give me a hand with the wedding unpaid labor or you can do your own plan. H So we put a few things in a repo that you're going to get access to. So you if you want to pick your own adventure, do that. wouldn't recommend because I do need help, but whatever you choose.

14:15 >> So, we'll give you a few minutes uh for you to set this up. Just either scan the QR code or go to my uh repo and there will be some instructions on how to set it up. We did not plan a background music like an elevator music for this moment. >> Yeah, let us know if you have any any trouble setting up. >> Also, if anyone sings, it would be a good time to >> karaoke live.

14:51 >> By the way, you don't need to execute anything just yet. Just make sure you have the repo in your preferred um setup and then we'll guide you through the the execution. >> Cool. Uh, so you just cloned a virus. No, just kidding. But a lot of vioded stuff in there. The structure does make sense. So we have a guide on how we start for today's workshop.

15:15 H, we have the example most important thing of the talk today. So helping me figure out my wedding. H, also the harness itself, the thing we build to show you how the principles are applied. And then finally, there is a folder where everything you build that drifts away from what we're doing is going to get stored in. So again, it's a little bit of a pick your own adventure uh with the added risk that we may not be able to help you if you get stuck, but you can um and everything you do today, you can take it home and

15:48 you can check what you did and what you like, what you didn't. And particularly I was going to say particularly the harness itself talking to to the jokes we were just making about like this is as far as this was built. Um again the the principles we're sharing here the principles that are built here we were discussing just yesterday is like uh this can feel like we are showing you a table to teach you how to build a table if that makes sense.

16:14 Uh but we really do we really do believe that the again building is not the hard thing. The hard thing is knowing how we want to approach the problem. So that's why we're bringing it like this. But we're gonna open the open the look under the hood a bit um at times just to show you what's going on um behind the the principles we're applying. >> And pretty much like Filipe was saying, it can feel akin to saying like, "Hey Claude, please build me a $1 million company."

16:48 If you don't know exactly what are the principles and the decisions you're making in order to make something happen, doesn't matter how many times do you try, you're likely going to be just leaving yourself up for the randomness of something good happening by accident. So we want to anchor the principles again because they build on top of each other and we think there is a nice sequence that kind of makes logical sense.

17:15 So building that shared domain plan mode however you want to call it. Then setting up consistency making sure that whatever can run or should run reliably does then having the evidence to back up where the decisions are coming from what information is coming through if things are being tested and so on and putting that front and center. Then the accountability how do you keep a good enough grasp of what the machine is doing?

17:44 You don't want to go full blackbox mode because then your accountability is gone. And that has happened to many of us in this room, I'm sure. But the other side is also not very realistic where oh for every change you make send me the diff. I'm going to review it line by line for sure. Nobody has done that ever. Uh and then finally verification. So in data and in finance uh you often need to have a separate point of reference a counterfactual that you can check against h and ignoring that part of the equation just

18:17 leads to you running things on your own biases. So your results are always going to be skewed. There's some shortsidedness that plays into that. So these principles are just to try to funnel our efforts into where is most useful to get something that we can actually trust. Um heads up again something will break today surely just call us to you. We will try to fix it with you.

18:44 H some of it is also overengineered. This is not a session on good UI UX design. Okay. So this is just to show you how it could feel, show you the potential. Uh by no means we're building a product. Um and yeah, just raise your hand. Something's not working out, you're a little bit confused, raise your hand. We're going to float around the room. Um so you may want to check if this works.

19:15 Try and run that command. Yeah. And I think at this point we can just go around if things are not working for anyone and give everyone five minutes to get going with this bit. You should see the UI opening if everything goes successful with the setup works success in the terminal as well. Cool. And that second command there will open a very well-designed UI for you to do some stuff.

19:51 Here is the example we're going to show you because this is kind of like layered, you know, like an onion or an ogre. We're going to show you an example hardness being run on an example use case. If you want to run that command at the bottom, you will see kind of like a more fleshed out example. But if you stay on the just running the second thing and just use the UI, it may feel weird that I'm asking you to use an UI to see how a hardness behaves, but that's the point.

20:22 The point is to show you how it feels in should feel in the real world. Um, should I leave it here for a moment? >> Yeah, I think so. >> Yeah. Okay. Okay. I hear less typing. I'm going to assume you've typed whichever command you wanted to type. Erh, so let's go through the actual steps and the principles of the hardness and the share domain is the first one.

20:45 Can I see little show of hands of who opened the UI and hasn't done anything else with it? >> Cool, cool, cool, cool, cool. All right, so um long story short, you have a chat window on your right right hand side and it has nothing essentially. Erh, if you want to follow through an example of a financial worry, some analysis you want to do, that's the place to start.

21:09 And basically, we want to walk from the goal we want to achieve and just try our best to give an explanation. You're probably doing this daily with your agents anyway, but focus on understanding that you're likely not going to have the same context as the agent. Um, wait, can I go back and forward just in case? Okay. Yeah. Yeah. Demo. Um, so I wanted to explain something and I think most people don't realize the fact that what the model knows is not necessarily what you think.

21:46 So unless you're very rich and you have a lot of models trained for you, h you're like likely your definition of certain things are not going to be the exact as what the majority of the population defines. So if you're looking up for a certain term, the agent may the model may be smart enough to know well this sits in this space but it's not necessarily the thing that you meant.

22:11 So going back and forth with your uh model really makes a difference. And the hardness is supposed to encourage you if you're trying it out yourself to dig deeper to challenge some of your assumptions to ask you questions you may not knew you needed to to ask yourself. So if you want to do Yeah. So let me do the same thing that you folks are doing, but I'm going to do harness example.

22:53 Let me go back here for a second. Just make sure I have everything Is anyone completely lost or are good? Okay, maybe could you give him a hand >> while I I I run everything. And for the folks that arrived later, I will give you the QR code as well for the so if anyone lost that you can you can pick it up again. Okay. Um let me show you two things while I while we we let you go with it.

23:49 So this is what you should be seeing when you run with a wedding example, right? Um we're we're going to explain in a bit um what's going on here. If you are choosing just to show you as well, if you are choosing to uh pick your own pick your own direction, um you're going to see something like this where it's empty. And then what you can do is as Francesca is going to run through the wedding example, you can say something you want to to use a harness for as well.

24:22 So things like I don't know plan your own wedding, plan a trip, um plan a new investment in your company or in your personal life, doesn't matter. Um anything that relates to financial the financial life that we can um implement the same principles. If you ever need uh again just opening the hood a bit. If you ever need to switch between one and another like the the wedding example or your own um you can just delete the in the my and var folder you're going to have a database that's basically what's storing this.

24:55 So you can just delete it. Oops. And then once you open the the UI again with the previous command, you're going to get the example. >> Do you want to open the clean one? >> Yes, I can. Sure. >> Yeah. So, appreciating that you're literally you're literally being given uh a blank canvas. We want to disambiguate a little bit. So, if you open the wedding example, that's a work through example that has all the elements.

25:26 But let's say this is where we're starting, right? And I have a problem. Do you have a dictation thing there? >> Um, I do. Um, >> okay. >> Let's see if this is working. Wait a second. So, basically on that like chat window on the uh right hand side, you are it's a familiar interface, right? So, how would you go about getting some help from an AI agent for whatever specific problem?

25:54 Just start with a chat. You start with a a problem and you start to describe what you want to achieve. So, if I were to do it, I'll say I have a wedding and I need to make three payments. One for $6,000, another one for an unknown amount, uh, and another one for the rest of the money. And also, uh, some of my costs are fixed. I know what I'm going to spend on a DJ and I don't know decorations, but I don't know how many people are going to attend the wedding.

26:30 And that's the amount of money I'm going to pay per h per dinner per seat. So, I don't even know how to go about making sure that I can pay in time in time. On time, on time on time. Um, I'll say let me just cut the first bit. Cool. So if you want to run it for a problem that you actually care a little bit more about uh you will start there and all I'm doing is planning with the agent.

27:02 Most of the harnesses today come with some notion that triages that you're trying to plan for a problem and it will try to come up with a reasonable idea some set of questions to give some more clarity. The harness itself is what guides the sort of questions that you will get asked and the sort of rigor that the plan needs to have before implementing anything.

27:21 The idea is that it doesn't go immediately into a yes man mode and just implements whatever crazy idea you came up with that is very unclear but that helps you drill down and dig into what it needs to do. So that's the principle of getting a shared context. >> Quick one before you you continue. Is the size okay for the back of the room? The size of the text.

27:48 Yes. Okay. Cool. Thank you. Yeah. Sorry, I'm reading because this is like live. Okay. From the one I have. Okay. So maybe I can keep adding clarifying information here. And I'm going to skip ahead, but something like I have no savings. It will come from my pocket. My mom may give me like 5k. Uh, I know the price per a person going to the wedding is around 150 and I'm paying 500 for the for the flowers.

28:34 I need to buy my suit. I'm just adding a bunch of like complexity and being disorganized on purpose because the point of the agent is that it doesn't let go the fact that you're being vague um in not providing the information ahead of time. The whole point of this is that it's really guardrail for you to for to forcing yourself to actually go through um every single data point that it needs to come up with a plan.

29:09 I think for the next one we just build whatever comes up to try and move on. >> Propose the plan. Now, >> is anyone trying it out with a problem you have personally? >> Yes. Okay, cool. Do you want to tell us a little bit about it? >> Oh, fair, fair, fair. Nice. Okay. It's asking a lot of questions and I'm >> No. Yeah. I I accepted the plan. Yeah. >> So, can you go back to the seated example?

29:46 >> Yes, I can. Um, >> so to save you a lot of the back and forth back and forth here because it's not very high signal for any of you. There's a couple of takeaways. One is having that self-awareness and forcing the hardness to remember that your domain knowledge and whatever the agent knows is not going to be the same. You want to find that kind of like vin diagram superposition as much as you can.

30:14 H but it takes a lot of back and forth and that's often where most of the time is spent. If you design a really good harness, it will guide you by the hand on coming up with a really good plan, implementing things well, uh, and knowing what components are important and which ones aren't. Uh, if your harness is basically like, yeah, say yes to everything I say and do your best to implement it, then you're going to get variable results.

30:41 So, this is the seated example. The plan accepted thing at the top means essentially that I already went through the back and forth for around 10 minutes or whatever. Uh and the agent feel it knows enough about my problem to break it down in steps. So what you have in the diagram over there is the all the steps that it considers as decision points in a decision tree if you may to actually make a decision >> and if I if I may um I think it's it's as we said in the beginning it's nice to look under the hood a bit just to

31:20 give you an idea and you can of course explore this by yourself or with your preferred agents help. Um but when we are when we are talking about everything that Franchesco is describing um this also comes from the instructions that we have inside the harness right so this is where we have the instructions of the agent performing the interview and what it must end up with so this is the materialization of the principle built beyond the harness right like built inside the harness I mean >> if you want to go back to um to

31:55 the UI. So this is hopefully going to start making more sense as we as we progress in the example. But we added a couple of quality of life things where if you want to know what elements of this whole UI that is so beautifully designed h makes sense for whatever uh principle we're discussing. You just need to hover down at the bottom and it will be broken down.

32:22 So you see when we did the planning the planning the sharing the domain context it came up with a plan is highlighted at the top on the right and then it came up with all the nodes and the connections in between the other decisions and what we need to start scoping from here. So should we move on? Yes. Is anyone still doing any planning with the chat?

32:56 >> Cool. >> Okay. Yeah. So, we had a few things here. If you wanted to uh play around and peruse the uh harness yourself, you could for instance go on the step three in the UI like in the little diagram on the left hand side. >> Oops, sorry. I was going to show >> too many tabs. >> You could click on like step no >> step three in the Yeah. And it will give you a little bit of a breakdown of where the information came from where why the model thinks this is the node you need to make a decision of uh including if it's

33:40 making any assumptions based on the language you were using during your planning with it. So for instance the agent did you say this I could point with this >> uh if you press and hold that yeah >> awesome >> not AI >> so there's there's quite a few things in the plan h that the agent put together that were proposed by it so you can start dissecting a little bit and understanding like actually this came from me this is a fact that I think I know or this is something the agent inferred based on my language.

34:15 If you scroll up a little bit just on the same Yeah. more more more more there. Yeah, sure. Uh here there was some back and forth because I was being vague with the language I was using and it made an assumption that because I was using this keyword here, I meant this. Again, this is a pretty obvious example, but you can play around with clicking through, seeing things around.

34:44 If we go back to the presentation, there's some annotation because again, this is all about grounding the principles into something that feels like it was designed for building trust. So you have some notation. Again, not the best UI design in the world, but knowing if things came from you, from the agent, or is it still an open point and you need to make a decision on and you can tell how the plan has been built.

35:13 You have another thing you can try. You can go back into step two uh and actually tell the agent if we click on the node there. Yeah. And you can actually tell the agent after you have sorry uh you can just tell the agent like well actually you're making some assumptions about this step that are not correct and then go a little bit back and forth. Erh, I will still do the show of hands thing, but because of reinforcement and engagement, uh, who has been in a chat session with over like well over 10 turns, so back and

35:53 forth and back and forth at least 10 times where at some point you said, let let me start from the beginning like this is not making any sense. Some stuff we already discussed like it's well gone. Who has had that feeling on a regular basis? Yeah. So, that is a consequence of the design of the harnesses we have today where they're designed for a linear discussion and to keep everything in the context as one big conversation.

36:22 Whereas here the way we designed it is supposed to break it down so you can discuss individual elements without necessarily making things you know more complicated in the grander scheme of things. >> Yeah. >> Erh cool. So I will let you play around with it a little bit but I do want to maybe go a little bit further. So I will introduce the consistency principle and this build on the shared domain erh because you already have a plan and the agent is very capable to understand well these pieces of your plan are just a

37:08 piece of code or just a calculation spreadsheet like it will always give you a consistent result is a deterministic element of your whole plan. Erh and based on that you need to implement code. You need to implement something that will give you the same result every time. Erh similar show of hands thing. Has anyone tried to do like budgeting or any financial calculation in the chat and how did that go?

37:37 Like are you confident on the results? You Yeah, a little bit. >> Temperature maybe like very well um not too well. pretty bad. >> Okay. >> So, so all right. So, I would love to know if anyone wants to volunteer their story, but what they saw and why they think it happened. But to me, a couple of times I thought I was giving all the necessary information.

38:06 The the agent gave me back a formula. It was even formatted as a formula. You know, the kind of like italics formula thing that looks really nice. I was like knows what he's talking about. And then the result was like I'm not a calculator and I know that result is wrong. So from the get-go I was like nah start from scratch. H anyone has any other like examples >> consistency right?

38:29 So a lot of times the results look good reasonable but you run the same thing again that's something. >> Yeah. So that's basically the inspiration on the principle. Sorry, what do you want to share? >> Yeah. So it goes to the point that every time it might >> Yeah. Uh and and that's a great a great um example to say part of the benefit why we are talking about building a harness and not just plugging these principles in a set of skills or instructions to an existing harness such as like codeex cloud code or anything

39:25 else like when we when we do it the non-deterministic way which is to give the agent a bunch of instructions that um say the right things but still rely on the agent agent. Uh, make no mistakes, please do the right thing. Um, that's that's the point. We're relying on a bunch of things happening in the background and basically getting a nondeterministic result every time.

39:48 So, I think the value here from building the harness again, this is looking a bit into the under the hood and like from principles we we applied at at Monzo as well is mixing the non-determinism with some deterministic behavior that we want to control. um when when relevant. >> I think you mentioned that for this demo a lot of this harness was quite I get this point right for production stuff like what's the difference between you making calculations in in chat versus you asking the model to code up calculations for

40:28 you in code. So I have a couple of personal examples on doing forecast where you can try and do forecast yourself by hand or come up with a spreadsheet with a lot of fancy um calculations and you will likely get a few things right and get a decent forecast. You can also just get a library from a trusted uh repo and that has everything baked in. You can also write some code in a more modular fashion that is well unit tested, you're doing end to end testing, you're doing all the like good software um engineering

41:03 practices that we know how to do to ensure that that piece of code is going to give you a good result. Um, so I think the different Oh, sorry. The difference lies a little bit on the fact that if you're just leaving it to the agent to decide how to implement things and when they need to do it in code versus when it like you should just build something on the side, you're going to have a little bit of a big miss ratio like hit or miss.

41:36 >> Yeah. Yeah. I I guess what I'm asking is if this is why quoted no good engineering practices were applied. I get this part. Do you have like a product that that was tested? >> We we I'm going to do the the uh ad again. Uh tomorrow we're going to have a breakout session in the morning where we're going to talk about uh what we build at Monzo that applies some of these principles.

41:58 uh but yeah I think the what is behind when we say like the harness being voded I think it's more about the implementation detail of like abstractions methods the actual code uh but the principles of mixing the determinism and the non-determinism are the same regardless if that makes sense >> thank you >> uh and another thing another thing that signals that this is a a good principle to consider on over the last what year or so most of the agents have started to do more aggressive tool calling and building their own

42:37 tools to solve calculations in a more deterministic way and honestly agents are just getting better right so we could just wait and then all the problems are solved the one challenge I have with that mindset is that h it will create stuff on the on the go like in flight so Yes, you may get the right code for the right problem at an at a point in time, but maybe the time number 100, you run it, turns out is inventing a new piece of code that didn't need to be reinvented.

43:08 uh and other examples non-workrelated that I can share err are around like doing exactly that like I have a I don't want to say strict but semi-strict close of budget every month and I categorize everything in my statements I left it to the agent to decide how to do the categorization and how to do the aggregates and everything else and the refunds and expenses and at some point I was like no no no this needs to be a script because I'm gettinglight slightly different results every time and I'm spending more money more

43:41 money and time uh wrangling with the agent to get it to give me the results that I wanted that it got right three times already but didn't get it right in the fourth uh so I don't want to repeat it again but make sure that we run the calculations you write the calculation once and then you run it every time you need it um and the model is able to pick the tools is you just need to make sure that your hardness makes it very strict that it's not going to do any arithmetic or try to solve these problems by just parsing

44:20 tokens. Um so what can happen if you don't make sure that your calculations and everything that is deterministic runs in code they're in the thickest in the model's head. So it's gone once you start new session the new code for every new question and or new session and it becomes a mess and same question different answer non-determination again you're asking the stoastic machine to produce a consistent output so you're likely not going to get it.

44:48 Um, so here's some examples of things that have a way to be calculated, right? Like I'm sure if you ask 10 different financial services companies, they will have a slightly different way of doing these things, but the general formula, the general idea is the same. So you could realistically export a library, write it once, update it, and these things are not new.

45:17 they saw from like software good practices. So demo again if we just want to go to the seated example h in the can you highlight this? Okay. >> So again just using this h you can see how the nodes in your decision making process um some of them needed to be implemented as code and I think the one of the easiest way to check is if it's a calculation likely it has to be implemented as code right uh as well as some testing unit testing golden examples etc.

45:58 the you should build trust with your agent when you're building a harness like this by making sure that the information you care about about its implementation it's in front of you. Another example of how this has looked in the wild is giving you versions of the code. Your your code is more likely versioned. If anything change with the version of the code and you're trying to run the same process, the agent should be able to pick it up and surface that information to you and say actually this code change you probably

46:31 even though the function is the same you probably shouldn't trust uh what's coming out of this because the whatever calculation h is different now. So as you're working with the with the harness and you accepted the plan, you have a nice graph like this being built, you will get something at the top saying, do you want me to build the code? H and it will do it for you.

46:55 And again, it's all guided. That's the point of a hardness that it guides things. Erh, is anyone building any of the steps on their plan? >> Is that okay? >> Yeah. Yeah. Cool. >> I switch to focus. >> Okay. Yeah. [laughter] >> Fair enough. >> Fair. Fair. >> Cool. So if you're following on the wedding example, you can try a few things. Click on step one, then code, and then the test and run the tests now.

47:47 Tests here. >> Yeah. >> 95. >> Sorry, what time is it? >> 9:54. [laughter] Okay, good. Um, but yeah, the the the principle here and just going back to try and tie everything up together, you shouldn't rely on you remembering to run the test. You shouldn't rely on you remembering that, hey, this this sounds like I can h create some code to solve it every time.

48:18 The agent should guide you through it. And that's one of the principles we baked into building this. Uh, as an aside, I think we were telling you, uh, there's a little extra file in the repo that says build yours or something. >> Um, it essentially has all the principles baked in in order and it will guide you on building a [snorts] similar hardness.

48:45 >> It's built your own. >> There you go. >> Yeah. So yeah, it will guide you on building something that feels similar to the harness we're showing you that prioritizes trust building mechanisms over just giving you something that looks correct. So you can try this. The [snorts] test should be passing. You will notice that there was no thinking, perusing, all the verbs that agents put when they're loading something.

49:18 Yeah. because these are just tests that need to run in your environment. Don't overengineer it. Funny that I'm saying that, but it's easier if all the components of your harness just work together as they should and not based on like hopes and dreams and magic glue from an agent orchestrating things together. >> I think we had a question. Erh, so if we Yeah, I mean we can do that, but I'd rather not do a reading session.

50:07 Basically, it it all goes about h figuring out what you actually care about and what are the functional requirements for a functioning harness. H I'm sprinkling some of that through the conversation. Again, need to avoid oversharing a little bit because of IP. Uh but you want to make sure that the objectives of each of the steps when you're building the parts that will make up the behavior of your hardness have an intent.

50:34 The intent of one of the first components is gathering as much information as possible to come up with a plan. And that is written in here as well. So this is basically instructions for instructions. It's the IKEA guide. Um it is supposed to guide you very nicely on these are the things you should care about but but then you can pick uh your preference on how they get implemented.

51:03 >> Question. So how is this different from let's say the specdriven development expected something like that which is also linear from starting from all the questions from you starting from idea all the way to the end and how is it different to this one is different to that >> do you mind if I come to that um I I want to mention two things that I think are are relevant here um I think the first one is when we're building a harness for a specific type of use case it's a bit different from the coding assistant world of

51:36 agents because with the coding assistance we usually the code is a means to an end right like we we're building something that performs an action. It's a product, is a an app, whatever that is. Um, in this case, the agent is helping us like analyze, solve a problem and work us through that. So the the gigantic spec for this like let's say for Franchesco's wedding things will change like it will evolve it will change and then if we go back to the everchanging spec we are relying again on the determin on the

52:12 non-determinism of the agent to interpret that that can be very very very um robust and perform this the the correct thing. So the harness essentially breaks down what would be the spec in opinionated sections if that makes sense. Um and I think the second thing to complement with that and is actually something I wanted to to like ground on our experience from data.

52:35 I don't know how many of you work in data engineering analytics or anything like that. I think something else that we bring from this word in these principles is the idea that um metric definitions and dimension definitions always change like in our experience we've like [snorts] had many many many times and I'm sure many of you as well um that conversation were is this number correct?

53:00 I don't know. It sounds like it is, but we're never sure and then if we're never sure, is the number correct? Um, I think this is also coming from that perspective is that to the point where we trust the agent as well as we trust a dashboard or a metric or a visualization. Um, we've reached alignment with it and the harness can continue guiding us into that alignment continuing to be true over time.

53:26 But premises will change, source data will change, context will change. And then having the harness able to adapt to that is like recognizing that this change will be a thing um rather than having to every time pro prompt again and go back to the process. Does that make sense? >> Yep. >> Follow question on that. any complnt this perspective because most most workable thing you are developing something even though it's subject to change through different iterations you are developing something with an AI agent can be

54:12 part of this flow as well >> absolutely use that uh this part this harness to do that it >> absolutely and this like under the hood this is essentially what's happening as well. So when we have when we're creating um the if you if you look under the hood in the my folder, you're going to have everything that is saved. So you can think of this as the spec that's behind the harness.

54:45 So absolutely like the same principle applies here in the in the specdriven development for again coding agents is usually used. you have something that is the source of um definition for the thing being built. In this case, it's the same thing. The difference is that we surface that through opinionated like uh workflows rather than a single um looking document if that makes sense.

55:11 All right, cool. So, that's another thing you can try out. um you can try and change how a calculation works. Uh and you're likely going to get some push back from the harness. Just to reiterate, the point of the harness is to guide you and force you to do the right thing. And the principles are here to help you make the right decision every time. So again if you go try and change uh multiplication for a an aggregation you may just go make the quick edit save the file success you sabot attach the analysis but when you

55:50 run the test you won't be able to actually reach any conclusion of the analysis you wanted to do h because the hardness is going to stop you by its own like definitions and the way it was built. Um, should we move on evidence? Er, evidence is the whole thing I was saying before about the receipts, having the receipts and being able to show that well, yeah, this is where this came from.

56:18 This is correct because of in doing that causality relationship. So it builds on the second principle as since you have code that is tested as well as everything else h you have a trail that you can follow backwards. So you have a way to substantiate the decisions you're making and you have the evidence and it's important in this principle because a principle is something you need to interpret right and I don't want to leave you with a very vague ambitional thing like oh yeah do evidence it's awesome but what is what

56:57 about evidence is something that you need to take care of going back to being data professionals this is something that bites us on a weekly basis. Erh, not all information is the same. If you really want to present a piece of analysis or you went to do some financial analysis on a potential investment for your firm, you need to show where your numbers came from and be able to attribute your decision to the body of evidence you had.

57:25 Erh so since we can show where everything came from uh there's some mistakes we want to avoid where everything is treated as a fact. So oh yeah this number you gave me for the number of um I don't know going back to my wedding the number of people invited is a fact. Turns out my fiance invited three more people didn't tell me. Now my whole model is wrong.

57:52 uh and I'm trying to reduce it to a very simple example but I think you can imagine how having a wrong assumption somewhere and not knowing where it came from can be fatal for any financial analysis. Um so let's say in the world of a gentic building it's very easy to assume something or treat something as a gueststimate. erh the model can't tell what is a hard truth and what is an estimation.

58:26 So you need to enforce that through the design of your hardness. Erh, and another example where this kind of like falls fall into pieces really quickly is imagine you have a data person, an analyst, something coming to you and being like, "No, no, no. Here's the result. Trust me, I run the numbers." Do you trust that as a Yeah, I see some like no. I don't think anyone here will want to see all the logs and the math behind a single number.

58:57 But just having the trace to figure out, okay, I can follow back this decision increased increases confidence for us humans quite a bit. Erh, so we have some like different examples here. Erh, unstructured thoughts in a chat needs to be labeled as an interpretation. the agent reasoning or pulling information from memory needs to be treated as an assumption and then if I submit a bank statement what is there to discuss like that is a fact that's how much I spent etc if I take like go back again to being a data person

59:36 data labeling and making sure that you have a curated data set for either training something or running any process is paramount and this is basically the same thing you just need to assign the right level of importance to the evidence you're gathering and make sure that you gather as much as as much of it as you can. Um, this is a really funny one, but evidence also goes into the code.

01:00:04 So, it's not just where do you get this number from, but how did you get this number? And I had I have an anecdote where someone was using the master file. In every company there's a master file and is favorited in the share drive and whatever. And that person puts some numbers in there and everything looked fine. The master file had some assumptions of what range of values were reasonable.

01:00:34 That person didn't know because the file changed. They didn't do anything wrong. They just didn't know the file changed. Uh and then the results were entirely wrong. And the same will happen with deterministic code you build with your harness. If you don't have a way to having a traceability even for changes you make in your code, you're leaving yourself uh vulnerable for blind spots on the process change.

01:00:57 The inputs were the same. Erh skipping ahead a bit. So if we're following from the example, can you open any of them? >> Yes. >> The evidence is highlighted. Erh, and again, you can see like the areas that you care about through the example by just like clicking on the bottom and then seeing the bits that get highlighted. But this is how the flow of information goes through and what parts are proposed by an assistant like you can show the receipts of where where this came from.

01:01:43 Looking at other implementations of financial analysts in the industry you get traceability down to the data set like you know which uh connector or which supplier of data gave you the information that whatever Apple had this price at this point of the day. if you're doing something about trading or investing in stocks and shares. So, this is extremely important.

01:02:07 I don't think we need to spend any more time here unless anyone has any questions. Oh, good. Cool. So, here's a few things you can try. Um, so you can add a little bit of a a curveball to the agent. Just typing in the chat and you will see how some of those evidence lines or some of the inputs that go into the rest of your process change and it it's able to trace that it came from you correcting some fact in the chat.

01:02:54 And another example is h if you want to go and make a change and click on the underlying figure that changed h it should show you all the way back where this came from and why it matters for the rest of your calculation. >> I'm going to say something that might feel repetitive. Um but again we are we are this this harness is an example of how to apply the principles but I I'm sure everyone is thinking about your use cases your companies the agency you're building the agency you're using and how like to to to connect

01:03:29 the dots and to to I don't know put the wires together. I think this is an an example we can think about when our users our and customers of the agents that we're building are using it and again the trust that they have in your product in your agent and in the output is what will drive usage adoption improvement and so on through the loops that we mentioned through tracing evolves and so on.

01:03:56 So again, I think um what's underlying here is when you're building a a harness, make sure that you can um make this happen to uh your customers that are using your users that are using so that they trust the results that your agent is giving them. Again, maybe repetitive, but like making sure we uh draw get everything together as we go. Before we move on, anyone has any example of a time where having the evidence trail would have saved you a lot of pain?

01:04:39 I see nodding like painful acknowledgement, but if anything you want to share, more than happy to to hear you out. Otherwise, we can carry on. basically every single time you try to do something. And so I'm playing with this. I really like the idea of being able to show the receipts and everything. That's basically every single conversation I have with an agent, whether I'm coding or like working on a deck or something.

01:05:08 I'm like, "Where did this number come from?" Like, "Well, we talked about this blah blah blah blah blah." I'm like, "It would be nice if I could just be able to show me specifically like the paper I like the that you use a presentation as an example because I had an example myself where I was trying as hard as I could to not have to resize text boxes in Google Slides for a good like month and a half.

01:05:40 So I was forcing my way into having something that could help me build slides. and I had a really nice harness that would like dig into the problem, get all the relevant documents and help me highlight what are the key points that I wanted to present to the team. And turns out in my conversations, I never caught the fact that when I ask for a modification and give an example, the model will fixate on the example so hard that it will put it everywhere in my presentation.

01:06:13 I didn't pick it up. So, you can imagine I was showing some colorful example to senior leadership and they were like, "Where did you get that number and that assumption?" And I was like, "That's crazy. I don't know where that came from. That's crazy." But yeah, it tends to happen. It's really annoying. And that trace of consequence can really hurt the trust that you have in your harness and the results it produces.

01:06:41 Let me carry on. So another principle is on accountability. Uh and this builds on the evidence because you only make a decision when you have some facts when you have some point of reference. Erh well I do want to say that but we all have that friend who speaks very confidently about something they don't know. So little bit of a counter example, but generally I think if there's one takeaway I would love for everyone here to feel aligned with is we are ultimately the responsible people, the accountable people for

01:07:19 whatever AI agents do, right? Um and there's a funny thing where people discussing that AI is going to um you know we're not going to have any jobs because of AI. I always go to back to the fact that I get higher, I get paid partially because I am accountable for the results that I produce for the company, not for me sitting in a computer and typing some stuff.

01:07:46 So there is an element of the human experience where the whole trust and accountability and working together as a team matters a lot. And how do you keep accountability high? You do need to be able to see under the hood, inside the black box, etc. Erh, I don't know who said this. I loved it. I never able to quote it. But agents face no real world consequences.

01:08:12 You do. So I I love the show of hands thing, but it probably is the only resource I have. Maybe that's why. Has anyone seen either written or been told? Well, I don't know. That's what Claude gave me. [laughter] Yeah, >> that feels great, right? Like, oh, that makes sense. Yeah. Yeah. Everything is forgiven. Don't worry. We face the consequences of what agents do.

01:08:41 So, having accountability mechanisms in our harnesses reduces a lot the amount of stress you need to go through. Just going in your head like, "But do you think it made the wrong assumption here?" Whatever. Erh, so you want to reduce ambiguity and not remove it. Erh, I'm pretty sure a lot of people here will remember fondly the days prior to auto mode.

01:09:10 H, who wants to go back to before when auto mode existed and you had to approve every single change by tapping enter? >> Yeah. Yeah. Lovely times. >> I still do it. Fair enough. [laughter] >> Fair enough. >> And from all the let's say 100 taps you did, how many of them you failed where? I mean, come on. This is a oneline change versus this is important.

01:09:44 Thank god I was looking at this. Yeah, I just pref >> and and that's basic that's basically part of the hardness like the design is intentional. So you review tasks instead of individual changes. And we're just providing you with a a reminder that when you're designing a harness, you want to make sure that you include on purpose those gates to make sure that you can still be accountable for what is being produced.

01:10:29 Um so make sure that any judgment call, any disambiguation that is important, not the trivial ones, right? H you can get some hold of it still. H what happens without it? I don't know. The stoastic machine said it was fine. Amazing answer. Approving every calculation. The other side of the spectrum doesn't feel great. H or reviewing every PR line by line that your agents ship.

01:10:58 Yeah, that it's not really well written, right? But yeah, it leads to a lot of either a lot of toil and unnecessary work if it's not designed um in a way that you know makes sense for the use cases. Erh. So what is the main takeaway on how to design a good mechanisms for accountability? Few gates with very high signal. Your example of the tasks and breaking it down in a way that you can reason about the the way they connect.

01:11:35 It's a really good example on where people do h reviews only on functional tests being passed. anything prior to that. I think you can be a little bit handwavy with yeah sure this looks about right but you wouldn't push anything into production that hasn't passed uh all your tests right so you put some gates in place but those gates need to be very high signal um >> and uh to to complement I think we're using some examples in the coding assistant world and and again this is not how we for instance approach things at at

01:12:11 Monzo because of like a different context text, but when we this is bringing to to our hardness. I think we use the AI coding examples because they're close to us and they're the tools many of us are using on a on a daily basis. Uh but when we apply here is the the same thing that claude code does when they have a feature that allows you to gauge how much you want to be involved in the process.

01:12:34 When we are building our financial harnesses, we can also guide our users in the in the same way. That is pretty spot on. Um, and again, just going back to the domain with money, there's some stuff you can leave the agent to figure out. For instance, if you have a few possible values for something, you're like, well, do three scenarios. It's probably going to be fine.

01:13:03 But you want to review them side to side before making any decision. You wouldn't hand over entirely the keys to the kingdom to something that you don't necessarily trust is going to have your best interest in mind. Not that it will have an interest at mine, but um so this is a it's very important that you know that bad decisions carry forward into your other decisions.

01:13:31 So the gates you design need to be fit for purpose. You need to know the use case really well in order to be able to put the gates where it matters. Otherwise, you're just adding before any decision, ask me and then it becomes very low signal again. Um and well for code you don't necessarily need to ask because the tests will speak for themselves. That's where the receipts come in handy because you only need to check that everything is passing and you will have a lot of confidence because of it.

01:14:04 So if you go back to the demo, funnily enough, this plan is not very high on accountability. The only step is I will check everything that we calculated all the scenarios whatever and I will make a decision on how much I need to save every month. I mean still nice because no money is moving out of my bank account anywhere but yeah there's a accountability mechanism I feel confident that that will gate any anything else >> I think as a as a as an extra example like in this this challenge and decision here likely as we

01:14:41 let's say we accept this and this is now marked as a decision we made if we ever use this information like the 20k landing on the same day as payment three as something that influences the final decision. This definitely comes with the with the accountability. >> Yes. >> Go up. No, I actually like I'm improvising a little bit. But if you scroll up a little bit, >> h this is like again not not priding myself of any good design at all, anything the contrary.

01:15:21 But h you see we have a little bit of a weird structure there. Looks like a tree a little bit with something branching out joining back in. That's another accountability mechanism as Philip is saying where there's some decisions the model will either assume and just try to verify with you like hey is this right? Is this the number you want to use here?

01:15:44 Or just try to figure out things how they fit into the overall um system. We thought a good way to showcase that you need to design a harness that gives you the accountability is making sure that you can trace all the decisions that have been made, who made them uh and have that sense of well this was something that the agent assumed and I let carry on in the rest of my flow or it's something that I provided a revised input to.

01:16:16 And the reason again I'm a very visual person that could be symptom of something I don't know uh but the reason I think is kind of like a not a straight line conversation but rather branching out and then branching back in is that when you're chatting with an agent again for financial purposes you may reason about something after a decision has been made and you are well in your right to correct information and add more context.

01:16:46 So, I think it's important that when you're creating an a harness that you not only build those gates for validating things, making sure that you're still accountable, but also for correcting the course and making sure that you can do so safely and it's not like, oh, because I typed this sentence in the chat, now all my analysis is gone. H that has happened to me many many times trying to solve a problem and maybe I was like dispersed dictating to my phone I said something in the middle of it and then the whole

01:17:21 analysis is gone because I can't really take away that one sentence and please keep everything else as it was h so this gives us another means to be accountable for what goes into the system for financial analysis and what Do you want to move to the slides? Yes. Okay, cool. So, uh, a few things we can try. Erh, you can go and and hover into the chip that guest that says how many guests we have in the wedding example.

01:18:00 And you can add that that will add it to the chat and you can say, "Oh, actually, it's not this number. H we will get no fewer than 150 guests for instance. Erh that will get your harness to rethink the plan see the consequences of that input into other stuff and suggest a either a modification of your plan or just change the input whatever. The important part here is you build the feedback mechanism on purpose and you have some judgment over making sure that there is some consequential decision making on the fact that

01:18:36 this input may change your whole analysis. H you need to be on top of making sure that those changes make sense. The other thing you can try is on if you click on step five erh you can open up a new branch conversation like a branched conversation I think is the button on the chat at the bottom >> here. >> Yeah. Yeah. So you can open a new branch. Has anyone used the slash >> btw by the way thing on cloud?

01:19:17 How has been your experience using it? >> Sometimes it works, sometimes it doesn't. >> Sometimes it works, sometimes it doesn't. And it feels like you're doing an aside, but not really an aside aside. >> It becomes a part of the context, right? >> But do you get a choice? Like maybe I have a stupid question in the middle of the conversation. >> No, I don't have a choice.

01:19:38 [laughter] If I ask a question, then it becomes the part of the session. >> Yeah. Yeah. So in here, what we're trying to do, and going back to why we're doing it like this, we want to show you how it could feel if we design something with the intent of, well, this really needs to be an aside. I have too many stupid questions when I'm chatting with AI.

01:19:59 So many. And it's shameful, but I end up having to open a separate chat because I don't trust it's not going to contaminate what I'm doing. And then I will take more time just being like, "Hey, this is a stupid question. please don't use for anything else is the please don't make any mistakes thing Philippe was saying >> h doesn't work quite well. So whatever you design if you have a feedback mechanism make sure that you tailor it to how you actually want to use it.

01:20:24 Erh oops cool and then as for h the last point the last principle will be verification. So you want a second pair of eyes and this builds on the principle of accountability because you are accountable for that review as well. Erh, and maybe that's too abstract, but has anyone been in a situation where someone h passed the blame on a bad decision to you or anyone else just on the basis of No, but Franchesco, review it.

01:21:14 That happens. >> That happens. So, um, we were having a funny conversation like a month ago where a few a few people are starting to have thoughts that the burden of something being good or correct with VIP coding ends up being in the hands of the reviewer in a team that feels really demoralizing because you're just being given a bunch of stuff that sure looks about right, but then it's your responsibility responsibility ultimately to make sure that it is right.

01:21:48 This whole principle of verification is just building more feedback loops so you don't have blind spots but without relegating any of the accountability. Ultimately, this is just extra information from a different source to avoid biases and avoid you getting stuck on your own thinking and your own processes. But it doesn't remove any of the responsibility or accountability.

01:22:15 Um yeah, funny enough, expert experts often do not check every cell. And this is more on like my experience working with financial finance teams in data. A they could open a spreadsheet and just look at the you know a few cells they know will give you a ballpark total and if it doesn't feel right they will let you know. It's like, how did we spend this much money on marketing?

01:22:43 I don't think that's right. Uh, and it's a little bit of a gut reaction. You don't need a lot of effort. You don't need to like redo your plan entirely or challenge every decision you're made, but you do want to have a separate point of reference. Erh, I think I I had an example, but I don't remember what was it was something about a tweet that got really famous about Elon Musk having I don't know how many trillion dollars and someone saying like, well, he could give a million dollars to every person in the world and

01:23:21 still have money. And he was like, wait, what? That doesn't feel right. Like you read it and you're like, wait, what? Looks plausible. And then you're like, "No, no, that's not right." And that needed need that needed for you to look into the calculations the person made is like a little bit gut feeling. Um, so just having something review and give you a rough answer or some challenge if something doesn't look right is extremely helpful.

01:23:49 >> Sorry. supply. >> That is such a good question. Uh I was trying to come up with a examples that feel more down to earth, but I think that's a very conversation to have. A good argument is if you're getting golden examples of how the data should look like, why would your process give you something different to that? Like why don't you just check with your golden examples?

01:24:27 And this is something I I wanted to abstract away from the world of finance. You have a lot of sources of information, a lot of them. You always have another point of reference outside of your data. So if some sources you're using are claiming I don't know whatever fact a number you have the internet you should always try and enhance the signal you're getting by looking out look at all the resources that are not the ones that I'm using and you avoid that h feedback loop where you only have the information you have

01:25:07 available you only have your golden examples and everything looks right to me Always try to get a little bit creative when building a harness to try and guide which other uh points of reference it could use to help you make a better decision or to know if something is not quite right. Does that >> Yeah. And I guess we generally try to like work whoever it is to like understand what would be the best set of things that agent should use the best answer.

01:25:47 So trying to understand how that would have been the optimal to give you another example that could be useful. I think the golden examples give you your ground truth for making sure that you are within the right space but no domain is isolated. So what happened to me a lot of times when I was a BI analyst in some like company is that I thought what I wrote was really good.

01:26:27 So my query was good. The number I got seemed reasonable and I was checking everything and nothing looked off. And then when I presented the dashboard to some stakeholder immediately went like that's not correct and I was like what do you mean? Do you know SQL more than I do? Did you do do the analysis with me? And turns out this person was from a separate team and they just had an idea of how many whatever sales were made in that year.

01:26:56 So they knew instinctively that number can't be right because it means my information in this other place is incorrect. So it's not if we translate that to the agentic world the golden examples I will give my agent in my hardness will be based on like biases and selection bias and so on based on the domain and I picked them for the domain and I think they're good for the domain but when you look at a slightly tangential domain you may find out that actually this is nonsensical like this number is wrong just by looking

01:27:32 at this other thing next to me I I don't even need to look again into my calculations. Cool. Erh. So there is a concept called thing slicing where you have thin slices of your anecdotal experience and you know what things feel right or feel wrong based on your experience in your domain. Whatever analysis you're doing. the model will have an average of everyone else's experiences.

01:28:07 So when you're building your hardness, you need to make sure that you can uh have a feedback mechanism so that you can verify from what the model thinks it knows all the way to what you think you know. And if you flip that convoluted sentence I just said it's the it's how we started the whole framework and all the principles where you're trying to get to that shared domain shared context.

01:28:37 You're essentially translating your language into the training data set for the model. You're just working with the model to be like okay this is how I understand the problem or how my company does this. and then the model is helping like okay this is how would I fit it in my training data set here we're doing the opposite we're just saying okay I think we got to a point where you can make a reasonable judgment over this domain but let's have a feedback loop so I can tell you from my experience if this looks entirely

01:29:10 off or if it looks reasonable so um yes it's probably fine may look nothing like yours I think is a way good way to describe it like yeah it looks about right and then turns out your company does care about that 5% difference it makes a world of a difference when you're building hardness for your team that you're aware that that 5% it will be a deal breaker for the whole team.

01:29:42 Um there's some stuff that happens if you don't have um a way to do this. So checking everything line by line or checking nothing or you know no sense of what about right looks like and if you don't have that point of reference your harness won't have it either. So you need to build those kind of like external validation points. I'm going to skip through some of this.

01:30:13 And for the verification, it's those notes in the H decision as well where we're adding uh an external point of reference to some of the stuff the model thought it knew. It's kind of satisfac satisfactory when the thing just like >> the branch go comes back. Yeah, exactly. And again, I think it creates a a trace to to um be able to like the the thin slice and the quick instinctive look also comes from from this because you understand the thought process that the agent went through and not only the the output only.

01:31:06 I go back. Yes. So, as with the other examples, if you're still following along, uh there's a few things you can try. So, you can open a branch uh on a tagged challenge. That's basically a separate agent that we tasked with reviewing the plan, reviewing the assumptions, and then doing some healthy challenge. Does this read reasonable? Um so just click it open it up and then you will see how just Philippe did it will join back into the trunk and actually change the plan.

01:31:42 So there is a consequence and we think this is another important part of being intentional with the design of your harnesses. We could have left it as LLM as a judge. So for every decision, for every plan, whatever, spin another uh agent and then do a review and call it a day. The problem is if there's no feedback loop, our financial decision or decision whatsoever doesn't improve at all.

01:32:10 So that's part of the design, the taste you need to build h to create fitforpurpose harnesses for whatever use cases you have. Then the other thing you can try is opening another and just clicking on dismiss. And we did that on purpose because sometimes as I was saying before some conversations don't actually change anything or not material to your process and you will know better.

01:32:37 So you need to have that kind of like point of reference for validating things. Um so just to summarize and leave this on the screen for a moment. Um, if you're still playing around with the harness, uh, the framework for building really good harnesses that you can trust with financial data with money, it's built on these five principles. So having a shared domain, having consistency, showing the receipts, keeping your accountability, and making sure that you create intentional loops for verification outside of what

01:33:13 you think, you know. Erh, what? No confetti. Disappointing. Okay. So, there's a few cases where we think it's important to define. Oh, sorry. You had your hand up. >> Yes. So, I just confirm my understanding. You brought us a framework like this five principles. You can build your harness upon it. And you also brought one harness as an example. So, I'm I'm thinking about when should I build harness, how generic or how specific the harness should be?

01:33:59 Because you solve problems with the specific harness and like for example, how many harnesses do you have in your work? It's just one and you solve everything that you have for this in this harness or you have multiple more specific harness. How generic and how often do you build one? Like how much effort do you put in building one? you make one every month or you make one every six months.

01:34:29 >> That's a that's a great question and there's no clear answer of course. Um I think it's we could we could trace as you said like the two ends of the spectrum as I just use clo code or or codeex for everything and I just embed everything into skills instructions so on so forth and on the other end of the spectrum is for every small new thing I want to do I'll build it from the ground up and like of course that will get tiring at some point because like you're spending more time creating your tools than actually using

01:35:00 the tools sometimes Um again there's no clear answer. I think it comes to um when you feel the use case is worth enough. So you want reproducibility, you want it to feel few the results you are getting using the pre-built harnesses are very frequently getting it wrong because the value you get from building the harness is you get more control again with the deterministic bit together with the nondeterminism.

01:35:31 Right? Um the reason why we're talking about the the principles in the case in the um scenario of a financial analysis is because if we do this type of use case in a harness that doesn't have it we'll probably have some of the f pitfalls that Franchesco talks through each of the steps. So then in this case it makes sense for um to avoid these pitfalls we are seeing over and over and over again to build the thing.

01:36:02 But again, I think it comes down to how many users you believe will go through that use case, how critical is the problem that you were seeing. So like if if there's a non-b businessiness critical um task that you were solving, you were probably fine to have a human in the loop reviewing the outputs that you get and steering the agent even if that takes a few extra turns.

01:36:24 But if you're putting this in the hands of a uh internal user, for instance, let's say you were building something for your team of credit analysts, um you're going to have 50 people using something to support key company decisions. Yeah, you absolutely don't want a lot of variability on that. So again, there's no clearcut I would say, but these are the things I would consider in in making the decision.

01:36:53 Maybe I can help with uh the counterfactual. So, we think this is a good recipe specifically for financial harnesses because there's a lot at stake. You want a lot of feedback loops. There's very specific things about those use cases that somehow we're representing here even at the personal level or the company level. But imagine you want to do you want to use AI just to produce like social media content and maybe one of your use cases is just flooding Instagram and Tik Tok with AI generated videos like everyone is

01:37:28 doing. There's some steps here that you probably don't care that much. Evidence gathering. What for? H verification or accountability even less so. So this is specifically geared towards like financial use cases and it can be extended to different levels of it but everything hinges on the fact that is a trust system. H this recipe may not be as useful if your use cases are not necessarily like that and in terms of how many harnesses you want to build.

01:38:02 I think Filipe said it better, but you can easily fall victim for doing a lot of axe sharpening and not actually using the axe. H So, at some point, if you're trying to use something and you're not getting the right results, you can try adding a couple of skills, a couple of commands, a couple of extra things, still not getting the results or the experience you want.

01:38:30 You're finding yourself copy pasting text from one chat to another, opening a new session. It feels convoluted harness. So you all the repeated things that you had to do three five times. Okay. Just once and you design it around it. >> Yes. Yes. >> Some more related question. So for your wedding planning task, right? I think one of like one of the naive way of looking at this is like maybe agent right like agents, venue agents.

01:39:00 Uh, have you have you have you tried that and what's the outcome or like your opinion on that? >> I will start by confessing that I have the most expensive cloth subscription and I do max it out and not in a good way as in Anthropic is definitely on the on the red because of me. I tried research everything for all the venue, the flowers, the wedding, do the planning, do the different like scenarios for how much we will have to pay etc.

01:39:33 And what I found is that in many cases it was good enough to give me the list of the top five photographers in Madrid with the new web search with like a refined h tooling etc. Worked like a charm. didn't have to do anything else just spinning and having comparisons and even reaching out to them but for some more nuance use cases where I do want to have more control and predictability and this is linking to the financial nature of them I did find myself being like I need to build something robust I'm not recalculating

01:40:07 this again uh and to to make the pain very real I remember myself one day because I was in the car and I was like I can dictate some stuff. Voice mode and then I was driving and it was about an hour drive back and forth, you know, an hour and an hour and I re had I had the same conversation three times in that t in that trench just because every time I was trying to do some financially related or adjacent planning, something will go wrong and I'll be like so yes, that helps.

01:40:47 So getting back to your example of being a BI right like um I don't think back in the day there were people who were validating your SQL queries right um so this seems like we are it's like next level of SQL queries right now you're building tools because harnesses are easier to build and stuff have you found ways to kind of make this point clear to leadership ship in in conversations that like because because to me it feels every time there is an AI there is an expectation that it will be 100% correct like you see

01:41:24 what I'm getting at >> so is your question about managing the expectations so that when people do agentic self surf >> it's not enginic sales more so like let's say you build this and and you're talking to your senior leadership to make a financial decision in your company Right? And they start drilling you and drilling you and and the moment that you say, "Oh, I use AI and harnesses, they're like, well, this has to be 200% correct or something like you know what I'm saying?

01:41:55 Have you found the way to to kind of make sure that they understand this is still SQL queries?" >> Bit of a spoiler, >> but there's a talk tomorrow. [laughter] >> I don't know. Do you have any? [clears throat] >> Yeah. Yeah. Yeah. No, I think um it's with the AI first world, we sometimes as you were saying forget that what's that that's only a two and a means to an end be before like what's what's going on right so I think what we would have noticed and again from Monzo's experience we've been approaching it from an

01:42:34 highly impactbased um point of view so it's not about we should use AI for this because AI can something something something. It's like what's the outcome we're looking for here? What how do we measure success here? Are we looking for less uh back and forth with a BI team? Uh we don't even have a BI team, but you get you get what I mean. Um to validate a new dashboard.

01:42:57 Okay. So, we can track that and actually see if AI can support us in in generating that outcome. um are we looking for um less I don't know internal ask tickets because the number looks wrong. Okay, so let's track that and then the approach that we do the way we do that doesn't really matter to a point if that makes sense because it will be again a tool that can get us to that um to that result probably faster with better guard rails and so on and so forth.

01:43:34 So I think it's less it's less about gaining trust on the implementation on the AI itself but more about aligning on what's the outcome we're trying to drive with the AI. I think we had another one there. My question is more you have show a harness that has some complexity right you have a UI you have databases say but I have also build processes that invoke some of these steps but they are all at skill right that it ask you questions it runs the number based on a Python script and so on so my question is more like

01:44:20 where you see the boundaries between like having a skill that does all these creating like a separate tool or have have you tried that? >> Absolutely. Yeah, absolutely. Um I think it it again very similarly to to what we were saying about your user base and the reproducibility you want is when this becomes critical enough that the tradeoffs we are getting with the nondeterministic approach are are not uh we're not willing to have them.

01:44:47 I usually describe the the skill command like the the promptbased approach as hey please follow all of this and make no mistakes please please please like again because this is what's going on right we are we are giving a a lot of organized very well organized instructions to a machine and hoping that it it will perform these instructions agents are good enough nowadays they will probably perform your instructions 99% of the time.

01:45:17 Uh, but what about that 1%? What about an edge case that makes things don't work? What about if you distribute this to your internal users and your internal user has a instruction in their user level cloud.mmd file that goes against what you are telling your agent to do. You see my point is like um there are many when you when you start distributing it to a number of users and use cases things can get messy in places you are not able to predict and then you can find yourself I we have a at Moz we have an internal like

01:45:59 contribution for agent extensions where multiple teams can well I've come across something that works with me let me share it internally um so like plugins skills and so on and very frequent ly we when reviewing the instructions we see things trying to cover for if the user tries to do this tell the user back that this skill does not support that and you see like it's again trying to cover for many things that with the determinism and when I say determinism is the backend code like the python the whatever we are using

01:46:29 uh that the harness provides that out of the like out of the box is something we can cover or >> anyone has any other comments, questions. >> All right, cool. >> Where is the thingy? [laughter] Never mind. Never mind. Never mind. Cool, cool, cool, cool. Skipping ahead. Skipping ahead. Ah, fun. Erh, I wanted to make a joke and I completely missed it for clicking this thing too quickly.

01:47:09 But finance is funny. And I say funny because I find it to be a super interesting domain with a the added advantage that back in the day finance felt like just working with spreadsheets, very like boring work, adding numbers here and there, formulas, whatever. If you ask any accountant is all about creativity and interpretation because they will come up with the weirdest things and I think in that level of ambiguity AI is really good really really good you have some bits that are the spreadsheet and then you realize

01:47:49 some of the cash flow didn't quite make sense because some of the revenue was attributed a month later and you're like ah creativity. So because we are in this space of finance and depending on where is your mind mindset at you could look at a problem as something very simple that you can just get an agent to fix within 10 minutes or you could look at it as it actually is which is a mixture of things that need to run reliably 100% of the time and a lot of interpretation and freedom of creativity in between the lines.

01:48:26 So yeah, sorry, very poorly delivered joke, but that's what I wanted to go through. Uh, and the bottom line being the design of your harnesses needs to be intentional to increase trust. Don't assume that oh because this is running on AI is going to be what was the the quote 200% accurate. It will likely not unless you design all the mechanisms so that whatever process runs you know you can trust the results to a degree.

01:48:57 Um and yeah models are going to get better. We have seen the last six months nine months in saying I'm getting a little bit of whiplash even with you know how fast things are going but they still have to earn the trust. it's not a 100% right and in when we're talking about money 1% wrong sometimes is a lot of money. So yeah, we kind of skipped into the questions, but if anyone has anything else, >> yeah, just really quick, like in the UI, how do you demonstrate trust?

01:49:27 Do I like you just ask it? Show me how you calculated this or does it show you the code? >> Can you show an example? Like how do you prove it? >> The intent was that it was a aggregation of everything. So all the steps in the framework should have failed like, oh, but I know where this is coming from, but I know this is running as code, but I know this is tested.

01:49:50 So it should have been an experience to kind of like immerse into this feels trustworthy. But again, it's one implementation we came up with. So not not super direct. >> Yeah. But I think the the takeaway is there won't be a single thing that will work to earn the user's trust at any point. So I think that's for some people the verification will be more important.

01:50:14 Some others are a bit more skeptic and they want to see the actual calculations and numbers and so on. So I think again that the process guides and covers for a multitude of u of possible possibilities.