构建可信财务分析智能体测试框架

Francesco: Morning. Thanks everyone for being here and welcome to AIE. I guess first session for everyone and for us as well.

Francesco: So 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. We are Francesco and Felipe.

Francesco: 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. I work at data and I work at a bank as well with Felipe. I like just finding the best eateries 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. 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. And then nice. All right.

Felipe: Happy to meet everyone. Also quick intro. I'm Felipe. I'm originally Brazilian. I also moved to the UK. It's been a year and a half now. So, it's been a fun journey. Life turned pretty much upside down. But, yeah, it's good to be there. I like to tell a story that before going to decide whether I wanted to do it in university, I used to play piano for like literally seven hours a day. And the natural decision there was to then study electrical engineering because who wouldn't, right? I ended up at some point landing in data because someone showed me something that at the time called Google Data Studio. Now it's Looker Studio, but now they went back. I don't even know what's going on. 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. But yeah, the rest is history.

Felipe: So I worked at a lot of startups and small teams and scaleups. And then eventually went to a big company at Nubank. Maybe some of you do know and then before going back to Monzo which is I would say a middle term between a scale up and a big enterprise company but it's growing so fast for now. And yeah most of my time currently has been working at Monzo with building internal AI-driven solutions for internal productivity primarily for the data team. So, we basically want to get our data team better by building with AI. And yeah, when I'm not talking to robots and agents, you can probably find me climbing somewhere either in nature or in a gym.

Felipe: And some starting points of why are we bringing this for you today? I think both Francesco and I worked in data teams in financial services. So again, Monzo, Nubank and a few other companies in the sector. We're now pushing what AI can do there. Our team at Monzo has been working a lot 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 concrete business value. So the adoption is very, very deliberate and we've been seeing very good results on that.

Felipe: And on the flip side, this is also something we've been doing, Francesco particularly is applying AI to make our lives easier. And again not through the approach of I'm going to set up an open client instance, nothing against it, and just give it connections to everything, but actually what are the things that I care about in my life that I can get the help of AI to make easier. So this is why we say we're not representing Monzo in this example because we're going to use the knowledge we bring from Monzo but build with you an example where we can actually see that in practice without having to discuss a lot of domain knowledge. But if you are curious about the things we are building at Monzo we have a breakout session tomorrow where we're going to talk about agent chip which is our in-house remote agent capability. So with that, Francesco, back to you.

Francesco: 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. But you're going to see we're going to give it a little bit of a spin. Because I think we're past the point of having to spend hours like grinding through your keyboard to get something that you can trust.

Francesco: 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. 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. 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. I'm pretty sure some of you may have some background tasks running with like Claude or ChatGPT getting some stuff done. So that's not the bottleneck. We believe that based on the experience we had over the last few months, the bottleneck now is how it connects with us.

Francesco: So trust is the thing we cannot take for granted and transparently because we're talking about money specifically. This is one of the highest stakes topics. 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 one-shot your money problems, your budgeting, your financing, everything else, find me after the workshop, I will buy you in into some investment ideas, so yeah, let's chat later please. 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 do you trust the results that you're getting?

Francesco: I'm going to name-drop a few things because honestly none of them are new. You're probably already grinding thinking well you buy trust by 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; 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. What we want to discuss today is actually the design principles on how to achieve that trust. So building a harness that actually works for money matters requires an 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.

Francesco: 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 harness 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". Spoiler: it won't be. 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 harness. So again, this is just one very simple implementation, an example. 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. 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

Francesco: ...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 consistent. We also want evidence where basically show the receipts, right? You can follow back and trace back the decisions and what led to them.

Francesco: Accountability is probably a very spicy one and maybe the 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. 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.

Francesco: And finally, verification. So, we want to make sure that there is a separate point of view, another perspective. 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. Please, please, please.

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

Filipe: And just doubling down on something that Francesco said, we're not saying this is the model. You won't see us going 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 that has been working for us in a number of use cases. I'll share a few examples at Monzo later and Francesco has a few other examples as well. But yeah, again, there's not a single silver bullet to solve every single problem. And also feel free to challenge us. If you think actually trust is overrated, just throw a 100 agents at a problem, eventually it will get solved—happy to hear the success stories. 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. So yeah, trust. Happy days.

Filipe: Speaking of trust, I'm here to confess that I have an ulterior motive with today's workshop. 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, specifically just to figure out some stuff around the finances of paying for a wedding. And because it's a conference, I want to make it as cringey as possible. So, show of hands: who has had a wedding? Who's gotten married? Okay, awesome. Number of guests under 50?

Francesco: Yeah. Okay. No, still show of hands. It's still like cringey mode. Okay, cool.

Filipe: About 100. Yeah. Nice. How about 150?

Francesco: Okay.

Filipe: Nice. 200.

Francesco: More. All right.

Filipe: Yeah. 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. And even running the calculations and figuring out how things got so expensive so quickly—it's not trivial. This is a little bit of storytelling, and hopefully my 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 undersell it a little bit. I wouldn't recommend doing it, but you know, I'm already on the train. So today you're going to give me a hand with the wedding—unpaid labor—or you can do your own plan. So we put a few things in a repo that you're going to get access to. So if you want to pick your own adventure, do that. Wouldn't recommend because I do need help, but whatever you choose.

Francesco: So, we'll give you a few minutes for you to set this up. Just either scan the QR code or go to my 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.

Filipe: Yeah, let us know if you have any trouble setting up.

Francesco: Also, if anyone sings, it would be a good time to...

Filipe: ...karaoke live.

Francesco: By the way, you don't need to execute anything just yet. Just make sure you have the repo in your preferred setup and then we'll guide you through the execution.

Filipe: Cool. So you just cloned a virus. No, just kidding. But a lot of weird stuff in there. The structure does make sense. So we have a guide on how we start for today's workshop. We have the example—most important thing of the talk today, helping me figure out my wedding. Also the harness itself, the thing we built 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, with the added risk that we may not be able to help you if you get stuck, but you can. And everything you do today, you can take it home and you can check what you did and what you liked, what you didn't. And particularly the harness itself, talking to the jokes we were just making about how this is as far as this was built. Again, the principles we're sharing here, the principles that are built here—we were discussing just yesterday—can feel like we are showing you a table to teach you how to build a table, if that makes sense. But we really do believe that 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 going to look under the hood a bit at times just to show you what's going on behind the principles we're applying.

Francesco: And pretty much like Filipe was saying, it can feel akin to saying like, "Hey Claude, please build me a $1 million company." 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. 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? 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. And then finally, verification. So in data and in finance you often need to have a separate point of reference, a counterfactual that you can check against, and ignoring that part of the equation just leads to you running things on your own biases. So your results are always going to be skewed. There's some shortsightedness that plays into that. So these principles are just to try to funnel our efforts into...

Speaker A: Where is most useful to get something that we can actually trust? Heads up again, something will break today surely. Just call us to you, we will try to fix it with you. Some of it is also overengineered; this is not a session on good UI/UX design.

Speaker A: Okay, so this is just to show you how it could feel, show you the potential. By no means we're building a product. 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. So you may want to check if this works. Try and run that command.

Speaker A: 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.

Speaker A: Cool. And that second command there will open a very well-designed UI for you to do some stuff. 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 harness being run on an example use case.

Speaker A: 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 harness behaves, but that's the point. The point is to show you how it feels and should feel in the real world. Should I leave it here for a moment?

Speaker B: Yeah, I think so.

Speaker A: Yeah. Okay. Okay, I hear less typing. I'm going to assume you've typed whichever command you wanted to type. So let's go through the actual steps and the principles of the harness, and the shared domain is the first one. Can I see little show of hands of who opened the UI and hasn't done anything else with it?

Speaker B: Cool, cool, cool, cool, cool.

Speaker A: All right, so long story short, you have a chat window on your right-hand side and it has nothing essentially. If you want to follow through an example of a financial worry, some analysis you want to do, that's the place to start. 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.

Speaker A: Wait, can I go back and forward just in case? Okay, yeah, yeah. Demo. 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. So unless you're very rich and you have a lot of models trained for you, likely your definition of certain things are not going to be the exact as what the majority of the population defines.

Speaker A: So if you're looking up for a certain term, the model may be smart enough to know, well, this sits in this space, but it's not necessarily the thing that you meant. So going back and forth with your model really makes a difference. And the harness 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 ask yourself.

Speaker A: 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. 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...

Speaker B: ...while I run everything. And for the folks that arrived later, I will give you the QR code as well, so if anyone lost that you can pick it up again.

Speaker A: Okay, let me show you two things while we let you go with it. So this is what you should be seeing when you run with a wedding example, right? We're going to explain in a bit what's going on here. If you are choosing, just to show you as well, if you are choosing to pick your own direction...

Speaker A: ...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 use a harness for as well. So things like, I don't know, plan your own wedding, plan a trip, plan a new investment in your company or in your personal life, doesn't matter. Anything that relates to the financial life that we can implement the same principles.

Speaker A: If you ever need, again just opening the hood a bit, if you ever need to switch between one and another, like the wedding example or your own, 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. So you can just delete it. Oops. And then once you open the UI again with the previous command, you're going to get the example.

Francesca: Do you want to open the clean one?

Speaker A: Yes, I can. Sure.

Francesca: Yeah. So, appreciating that you're literally being given a blank canvas, we want to disambiguate a little bit. So, if you open the wedding example, that's a worked-through example that has all the elements. But let's say this is where we're starting, right? And I have a problem. Do you have a dictation thing there?

Speaker A: Um, I do.

Francesca: Okay. Let's see if this is working. Wait a second. So, basically on that chat window on the right-hand side, it's a familiar interface, right? So, how would you go about getting some help from an AI agent for whatever specific problem? Just start with a chat. You start with a problem and you start to describe what you want to achieve.

Francesca: 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, and another one for the rest of the money. And also, 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. And that's the amount of money I'm going to pay per dinner per seat. So, I don't even know how to go about making sure that I can pay on time, on time, on time." I'll say let me just cut the first bit. Cool.

Francesca: So if you want to run it for a problem that you actually care a little bit more about, you will start there, and all I'm doing is planning with the agent. 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.

Francesca: 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. 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.

Speaker A: Quick one before you continue. Is the size okay for the back of the room? The size of the text. Yes. Okay, cool. Thank you. Yeah. Sorry, I'm reading because this is like live. Okay. From the one I have.

Francesca: 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. I know the price per a person going to the wedding is around 150 and I'm paying 500 for the flowers. I need to buy my suit."

Francesca: 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 in not providing the information ahead of time. The whole point of this is that it's really guardrail for you to forcing yourself to actually go through every single data point that it needs to come up with a plan. I think for the next one we just build whatever comes up to try and move on.

Speaker A: Propose the plan. Now...

Francesca: ...is...

Francesco: anyone trying it out with a problem you have personally?

Audience Member: Yes.

Francesco: Okay, cool. Do you want to tell us a little bit about it?

Audience Member: Oh, fair, fair, fair. Nice. Okay. It's asking a lot of questions and I'm

Audience Member: No. Yeah. I I accepted the plan. Yeah.

Speaker B: So, can you go back to the seated example?

Francesco: Yes, I can. Um,

Francesco: 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. 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.

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

Speaker B: 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 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

Francesco: if you want to go back to um to 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. 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?

Speaker B: Cool.

Francesco: 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.

Speaker B: Oops, sorry. I was going to show

Francesco: too many tabs.

Speaker B: You could click on like step no

Francesco: 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 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

Speaker B: uh if you press and hold that yeah

Francesco: awesome

Speaker B: not AI

Francesco: 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. 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.

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. 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 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. 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.

Speaker B: Yeah.

Francesco: 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 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? Like are you confident on the results? You Yeah, a little bit.

Speaker B: Temperature maybe like very well um not too well. pretty bad.

Francesco: Okay.

Francesco: 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. 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

Audience Member: consistency right? So a lot of times the results look good reasonable but you run the same thing again that's something.

Francesco: Yeah. So that's basically the inspiration on the principle. Sorry, what do you want to share?

Audience Member: Yeah. So it goes to the point that every time it might

Speaker B: 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 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

Speaker: ...background and basically getting a nondeterministic result every time. 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 applied at Monzo as well—is mixing the non-determinism with some deterministic behavior that we want to control when relevant.

Speaker: 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 chat versus you asking the model to code up calculations for 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 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 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 engineering practices that we know how to do to ensure that that piece of code is going to give you a good result. 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.

Attendee: Yeah. Yeah. 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 was tested?

Speaker: We... I'm going to do the ad again. Tomorrow we're going to have a breakout session in the morning where we're going to talk about what we build at Monzo that applies some of these principles. But yeah, I think what is behind when we say like the harness being coded, I think it's more about the implementation detail of like abstractions, methods, the actual code. But the principles of mixing the determinism and the non-determinism are the same regardless, if that makes sense.

Attendee: Thank you.

Speaker: And another thing that signals that this is a good principle to consider: over the last what year or so, most of the agents have started to do more aggressive tool calling and building their own 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 it will create stuff on the fly, like in flight. So yes, you may get the right code for the right problem at a point in time, but maybe the time number 100 you run it, turns out it's inventing a new piece of code that didn't need to be reinvented.

And other examples, non-work related that I can share, are around 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 getting slightly different results every time. And I'm spending more money and time 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.

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. And the model is able to pick the tools; you just need to make sure that your harness makes it very strict that it's not going to do any arithmetic or try to solve these problems by just parsing tokens.

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 a new session, the new code for every new question and/or new session, and it becomes a mess. Same question, different answer, non-determination again—you're asking the stochastic machine to produce a consistent output, so you're likely not going to get it.

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. They stem from like software good practices.

So demo again, if we just want to go to the seeded example... Can you highlight this? Okay.

Speaker: So again just using this, you can see how the nodes in your decision making process, some of them needed to be implemented as code. And I think one of the easiest ways to check is: if it's a calculation, likely it has to be implemented as code, right, as well as some testing, unit testing, golden examples, etc. 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 is in front of you.

Another example of how this has looked in the wild is giving you versions of the code. Your code is more likely versioned. If anything changes 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 changed. Even though the function is the same, you probably shouldn't trust what's coming out of this because the whatever calculation is different now."

So as you're working 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?" And it will do it for you. And again, it's all guided. That's the point of a harness: that it guides things.

Is anyone building any of the steps on their plan?

Attendee: Is that okay?

Speaker: Yeah. Yeah. Cool.

Attendee: I switch to focus.

Speaker: Okay. Yeah. [laughter]

Attendee: Fair enough.

Speaker: Fair. Fair.

Speaker: 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. Tests here.

Co-Speaker / Attendee: Yeah.

Speaker: 95.

Speaker: Sorry, what time is it?

Co-Speaker / Attendee: 9:54. [laughter]

Speaker: Okay, good. But yeah, 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 sounds like I can create some code to solve it every time." The agent should guide you through it. And that's one of the principles we baked into building this. As an aside, I think we were telling you there's a little extra file in the repo that says "build yours" or something.

Co-Speaker / Attendee: It essentially has all the principles baked in in order, and it will guide you on building a [snorts] similar harness.

Attendee: It's "build your own".

Speaker: There you go.

Speaker: 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 test should be passing. You will notice that there was no "thinking", "perusing", all the verbs that agents put when they're loading something. 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. So if we... Yeah, I mean we can do that, but I'd rather not do a reading session. Basically, it all goes about figuring out what you actually care about and what are the functional...

Francesco: ...requirements for a functioning harness. I'm sprinkling some of that through the conversation. Again, need to avoid oversharing a little bit because of IP. 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 harness have an intent. 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. It is supposed to guide you very nicely on these are the things you should care about, but then you can pick your preference on how they get implemented.

Audience Member: Question. So how is this different from, let's say, the spec-driven 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?

Francesco: Do you mind if I come to that? I want to mention two things that I think are relevant here. 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 agents, because with the coding assistants, usually the code is a means to an end, right? Like we're building something that performs an action. It's a product, it's an app, whatever that is. In this case, the agent is helping us like analyze, solve a problem, and work us through that. So the gigantic spec for this, like let's say for Francesco's wedding, things will change. Like it will evolve, it will change, and then if we go back to the ever-changing spec, we are relying again on the non-determinism of the agent to interpret that, that can be very, very, very robust and perform the correct thing. So the harness essentially breaks down what would be the spec in opinionated sections, if that makes sense.

Francesco: And I think the second thing to complement with that, and is actually something I wanted to ground on our experience from data. 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 world in these principles is the idea that metric definitions and dimension definitions always change. Like in our experience, we've had many, many, many times—and I'm sure many of you as well—that conversation where, "Is this number correct?" "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? 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. We've reached alignment with it, and the harness can continue guiding us into that alignment continuing to be true over time. 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, rather than having to every time prompt again and go back to the process. Does that make sense?

Audience Member: Yep.

Audience Member: Follow-up question on that. Any complement from this perspective, because 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 part of this flow as well?

Francesco: Absolutely use that, this part, this harness to do that. It—

Francesco: Absolutely. And under the hood, this is essentially what's happening as well. So when we have, when we're creating, 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. So absolutely, like the same principle applies here. In the spec-driven development for, again, coding agents is usually used, you have something that is the source of definition for the thing being built. In this case, it's the same thing. The difference is that we surface that through opinionated workflows rather than a single looking document, if that makes sense. All right, cool. So, that's another thing you can try out. You can try and change how a calculation works. And you're likely going to get some pushback 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 multiplication for an aggregation, you may just go make the quick edit, save the file, success, you sabotaged the analysis, but when you run the test, you won't be able to actually reach any conclusion of the analysis you wanted to do, because the harness is going to stop you by its own definitions and the way it was built.

Francesco: Should we move on? Evidence. 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. This is correct because of..." and doing that causality relationship. So it builds on the second principle, as since you have code that is tested as well as everything else, 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 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. Not all information is the same. If you really want to present a piece of analysis, or you want 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. So since we can show where everything came from, 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—I don't know, going back to my wedding—the number of people invited is a fact." Turns out my fiancée invited three more people, didn't tell me. Now my whole model is wrong. 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.

Francesco: So let's say in the world of agentic building, it's very easy to assume something or treat something as a guesstimate. The model can't tell what is a hard truth and what is an estimation. So you need to enforce that through the design of your harness. And another example where this kind of falls 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 ran 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. But just having the trace to figure out, "Okay, I can follow back this decision," increases confidence for us humans quite a bit. So we have some different examples here. Unstructured thoughts in a chat need 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, go back again to being a data person, data labeling and making sure that you have a curated dataset 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 of it as you can. This is a really funny one, but evidence also goes into the code. So, it's not just where do you get this number from, but how...

Speaker A: 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. 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.

Speaker A: 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. The inputs were the same. Erh skipping ahead a bit. So if we're following from the example, can you open any of them?

Speaker B: Yes.

Speaker A: 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.

Speaker A: 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. I don't think we need to spend any more time here unless anyone has any questions. Oh, good. Cool.

Speaker A: 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. 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.

Speaker A: 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 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. 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.

Speaker A: Before we move on, anyone has any example of a time where having the evidence trail would have saved you a lot of pain? 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.

Speaker C: 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. 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

Speaker A: 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. 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. 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.

Speaker A: 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 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. 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.

Speaker A: Erh, I don't know who said this. I loved it. I never able to quote it. But agents face no real world consequences. 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,

Speaker A: 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. 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. H, who wants to go back to before when auto mode existed and you had to approve every single change by tapping enter?

Speaker B: Yeah. Yeah. Lovely times.

Speaker C: I still do it. Fair enough. [laughter]

Speaker A: Fair enough.

Speaker A: 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. Thank god I was looking at this. Yeah, I just pref

Speaker A: 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. 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

Speaker A: agents ship. 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 in a way that you know makes sense for the use cases. So what is the main takeaway on how to design 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 way they connect. It's a really good example on where people do 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 all your tests, right? So you put some gates in place, but those gates need to be very high signal.

Speaker B: And to complement, I think we're using some examples in the coding assistant world and, again, this is not how we for instance approach things at Monzo because of a different context, but this is bringing it to our harness. 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 daily basis. But what we apply here is 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. When we are building our financial harnesses, we can also guide our users in the same way.

That is pretty spot on. 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. 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 of its own, but so it's very important that you know that bad decisions carry forward into your other decisions. 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.

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. 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 an accountability mechanism I feel confident that that will gate anything else.

Speaker A: I think as an extra example, like in this challenge and decision here, likely as 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 accountability.

Speaker B: Yes.

Speaker A: Go up. No, I actually like I'm improvising a little bit. But if you scroll up a little bit,

Speaker B: this is like, again, not priding myself on any good design at all, anything the contrary. But 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 Philippe 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?", or just try to figure out things how they fit into the overall 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, 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. And the reason, again, I'm a very visual person, that could be a symptom of something, I don't know, but the reason I think it's kind of like 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.

So, I think it's important that when you're creating 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." 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 analysis is gone because I can't really take away that one sentence and please keep everything else as it was. 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, a few things we can try. You can go and hover into the chip that says how many guests we have in the wedding example. And you can add that, that will add it to the chat, and you can say, "Oh, actually, it's not this number. We will get no fewer than 150 guests, for instance." That will get your harness to rethink the plan, see the consequences of that input into other stuff, and suggest 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 this input may change your whole analysis. You need to be on top of making sure that those changes make sense. The other thing you can try is, if you click on step five, you can open up a new branch conversation—like a branched conversation, I think is the button on the chat at the bottom—

Speaker A: here.

Speaker B: Yeah. Yeah. So you can open a new branch. Has anyone used the slash btw by the way thing on Claude? How has been your experience using it?

Audience Member 1: Sometimes it works, sometimes it doesn't.

Speaker B: Sometimes it works, sometimes it doesn't. And it feels like you're doing an aside, but not really an aside aside.

Audience Member 2: It becomes a part of the context, right?

Speaker B: But do you get a choice? Like maybe I have a stupid question in the middle of the conversation.

Audience Member 2: No, I don't have a choice. [laughter] If I ask a question, then it becomes the part of the session.

Speaker B: 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. 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—

Speaker A: 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. Oops, cool, and then as for 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. And maybe that's too abstract, but has anyone been in a situation where

Speaker A: ...someone passed the blame on a bad decision to you or anyone else just on the basis of "No, but Francesco, review it." That happens.

Speaker B: 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. 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.

Speaker B: 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.

Speaker B: 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? 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.

Speaker B: 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 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.

Speaker A: Sorry. supply.

Speaker B: 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?

Speaker B: 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 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

Speaker B: 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. 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.

Speaker B: 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. 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. So they knew instinctively that number can't be right because it means my information in this other place is incorrect.

Speaker B: 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 at this other thing next to me I I don't even need to look again into my calculations. Cool.

Speaker B: 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.

Speaker B: 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. 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

Speaker B: 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 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.

Speaker B: 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. 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

Speaker A: the branch go comes back.

Speaker B: 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. 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.

Speaker B: 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. 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

Speaker A: ...decision, for every plan, whatever, spin another 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. So that's part of the design, the taste you need to build to create fit-for-purpose 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. So you need to have that kind of point of reference for validating things.

So just to summarize and leave this on the screen for a moment. If you're still playing around with the harness, the framework for building really good harnesses that you can trust with financial data with money, it's built on these five principles: 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 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.

Audience: 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 thinking about when should I build harness, how generic or how specific the harness should be? 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.

Speaker A: That's a that's a great question and there's no clear answer of course. I think we could trace as you said like the two ends of the spectrum as: I just use Claude Code or Codex 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 the tools sometimes.

Again there's no clear answer. I think it comes to when you feel the use case is worth enough. So you want reproducibility, you want it to feel—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 non-determinism. Right?

The reason why we're talking about the principles in the 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 pitfalls that Francesco talks through each of the steps. So then in this case it makes sense to avoid these pitfalls we are seeing over and over and over again to build the thing.

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 if there's a non-business-critical 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. But if you're putting this in the hands of an internal user—for instance, let's say you were building something for your team of credit analysts, 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 clear-cut I would say, but these are the things I would consider in making the decision.

Speaker B: Maybe I can help with 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 use AI just to produce like social media content and maybe one of your use cases is just flooding Instagram and TikTok with AI generated videos like everyone is doing. There's some steps here that you probably don't care that much. Evidence gathering—what for? 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. 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: 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. 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, you're finding yourself copy pasting text from one chat to another, opening a new session, it feels convoluted—harness. So all the repeated things that you had to do three, five times: okay, just once, and you design it around it.

Audience: Yes. Yes.

Audience: Some more related question. So for your wedding planning task, right? I think one of the naive way of looking at this is like maybe agent, right? Like agents, venue agents. Have you tried that and what's the outcome or like your opinion on that?

Speaker A: I will start by confessing that I have the most expensive Claude 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 scenarios for how much we will have to pay etc. 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 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 this again. And 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 had the same conversation three times 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.

Audience: So getting back to your example of being a BI, right? Like I don't think back in the day there were people who were validating your SQL queries, right? So this seems like 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 in conversations? Because to me it feels every time there is an AI, there is an expectation that it will be 100% correct. Like you see what I'm getting at?

Speaker A: So is your question about managing the expectations so that when people do agentic self-serve...

Audience: It's not agentic self-serve, more so like let's say you build this 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 the moment that you say, "Oh, I use AI and harnesses," they're like, "Well...

Audience Member: this has to be 200% correct or something like you know what I'm saying? Have you found the way to to kind of make sure that they understand this is still SQL queries?"

Speaker A: Bit of a spoiler,

Speaker B: but there's a talk tomorrow. [laughter]

Speaker A: I don't know. Do you have any? [clears throat]

Speaker B: 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 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. 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. 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.

Audience Member: 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 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?

Speaker B: 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. 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. 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 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 uh that the harness provides that out of the like out of the box is something we can cover or

Speaker A: anyone has any other comments, questions.

Speaker B: All right, cool.

Speaker B: 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. 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 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. 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. 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,

Audience Member: yeah, just really quick, like in the UI, how do you demonstrate trust? Do I like you just ask it? Show me how you calculated this or does it show you the code?

Another Audience Member: Can you show an example? Like how do you prove it?

Speaker A: 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. 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.

Speaker B: 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. 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.