London Executive Forum 2026 - A leader's guide to advanced team structures in an agentic world

Thank you to Yiana and Phil. Always insightful. Many of you may have seen this Scott Galloway quote. AI won't take your job. Someone using AI will. Everyone heard this seen this a few of us. Yeah. What about this one? that uncomfortable moment. Am I the horse in what's going on right now? We don't want to be the horse, right? We want to be in charge. But this is actually the conversation that's going on. Now, this presentation I actually created originally at the AWS reinvent conference that I presented in December in Las Vegas last year. Since then, between then and now, I spent about 400 hours updating this presentation. And it's interesting of what's going on. And I've interviewed many of you. the Amazon leaders. I've built my own production products. I've helped customers get into production with their Gentic systems. And although this is slightly amusing, the concern that we feel, the concern as employers, employees, as leaders is very real. So let's ground it in a little bit of data. This report came out from Anthropic uh just last month. labor market impacts of artificial intelligence. And it's really only just started if you actually look at the data in here. So this blue on the spider diagram you're seeing is the potential disruption right now of these frontier models. The red is where it's actually started. So this is really early days still. And then when you look at the effect on unemployment and the unemployment rate, least exposed, most exposed. Interesting data point again. And then when you look here at the exposure, the projected employment change, you can start to plot this out in your own mind. So this is real. But before we go on, let's just ground ourselves in what an agent really means. When we look at the spectrum, automation, all of us have looked at automation for years, even a cron job if you're looking at a Unix based system executing code still heavily used in agentic systems by the way through to AI assistants. We've all used chat GPC in this room or claude. Um, my personal favorite is anthropic. through to these goal-based agents, which I call them on here. You'll probably know them better as the coding assistants, the Claude codes, the codeex from OpenAI, the Amazon hero from Amazon. These goal-based agents, which really only started in legitimacy October last year, have fundamentally changed the game. The ability to drive a goal, to instantiate code, has fundamentally changed the game all the way through to an agentic system. And let's not overthink what an agentic system is. By the way, an agentic system is fundamentally a prompt with context or the ability to pull tools in that's hitting a language model. And in my experience right now, 80% of the use cases that customers are hitting is actually one of the frontier models, models when they're building these systems. So these goal-based agents have changed the game because not only can they take on a goal, they can instantiate that infrastructure. My personal projects which I've built at home, the ability to then take them to the cloud, a reasonably complex multi- aent system with a few gigabytes of data, suddenly to build that and have the gold-based agent build this and instantiate my entire AWS environment securely in 45 minutes with all the cloud for code required blows my mind. So what's going on when you actually look at it is the ability to write software. There was an fascinating stat that I briefly saw this morning where I was talking about the amount of code contributions to GitHub have gone up by an inordinate amount just in the last 6 months. So you've actually got to think about this not from a job threat point of view but from a Jevans paradox point of view. And we've seen this every time a general purpose technology has come out in human history. All the way back, by the way, 5,000 years ago, from the emergence of the bronze chisel, which allows us to defeat friction by creating a wheel and an axle, through to electricity and the discovery of electricity, through to the silicon discoveries, through to cloud, now through to AI. Let's look at this first point. Anyone remember incandescent light bulbs? Of course we do, right? We all had them. Terribly inefficient, weren't they? So, what do we do? Ah, replace for an LED light bulb. Watch our electricity bills go down. Anyone feeling their electricity bills gone down right now? No. Because what do we do? We put these things everywhere. LED

lights everywhere. And guess what? Your electricity bill goes to back to where it was. This is Jevans paradox. Whether it's the price of electricity, whether it's the usage of coal, factories, every single time we've seen this play out, the explosion coming out the back of it is dramatic. So don't for a second think that software is set at this level. Oh no software is going through the roof and beyond. We are getting to disposable applications. We do not want this as leaders, right? like control is still important. We're accountable for what our teams are doing. But, and this is the conversation, the real fear conversation I've had in the last five or 6 months since these goal-based agents come out. Could 6 months of seed funding and 30 engineers and Anthropic Frontier model replace your business entirely? Because if you look at it, these moes that we previously had, workflow embeddedness, software scale, integration lockin, engineering complexity, I have hid behind decades of technology that I've built before going, you're not going to be able to come after me. I have a lot of IP locked in the software I've built. Wow, that just changed, didn't it? What truly matters now? Compounding proprietary data. Network effects, regulatory permission, capital at scale, physical infrastructure for your team. The meta mode's the same. Time that can't be paralyzed. I have had conversations with banks that are thinking of expending expanding their branch network again. Who would have thought it? Because that suddenly differentiates their business. So for you as business leaders, those five things are really going to matter. And by the way, if you want to take pictures, some of these slides are dense. I've tried to simplify them. So have your camera phones ready if you want to take pictures as you go. So this reality check, this quote from William Gibson, the future is here, but it's not evenly distributed. Has never been more true to me. Never been more true. And then many of you may have seen this report that came out from MIT Nandanda and you can argue about the statistical uh breadth which they took on but still look at this title that sort of grabs your attention. Despite 30 to 40 billion in enterprise investment to genai this report uncovers a surprising result and that 95% of organizations are getting zero return. Ouch. So when you actually look at why 95% of AI pilots f pilots fail, lack of workflow alignment and I'm going to talk about the ability to focus at a workflow level being the difference between success and failure. AI bolted on is going to fail and Phil talks and talks a little about that wrong targets. Companies aiming at sales marketing high visibility instead of back office operations where there's higher ROI are going to struggle and then missing integration pilot stay as demoed never connected to actual business decision flows pilot purgatory for goodness sake and this is why you get these some of these shocking stats at the bottom of the slide here and yes proof of concept almost four weeks but hey do you know what works on my laptop this is not where you want to So what do the 5% do differently? They're picking one point and executing well implementations that adapt involved customized and specialized for critical tasks. Right team composition and I'm going to go deeper on that and integrated into real business decision flows from day one. It's got to matter. Nobody cares about a point a proof of concept on your executive committee. They care about a business outcome. We always have. And then this paper came along from Nvidia and this drove a lot of people to think hm small language models are the future of aentic AI. I don't expect you to be able to read the subtext. So surely I need to go and create my own models to do generative AI or aentic systems. And the answer is yes and no. Yes, if you have specific tasks and we're absolutely ready to help you with that with SageMaker AI and Amazon Nova and uh the Forge very happy to help you do with that. But this has sent some people to an interesting place and not always the right one because you've actually got to put the economics first. So let's have a little look at what's going on. This shows you the cost to train a frontier model going back the last few years all the way from a transformer back in 2017 costing $900 all the way to those frontier models we suspect costing that much money to train them. That's a lot of money and this requires a big team of data scientists, data experts, model enthusiastics, fine training. You're taking on a lot of responsibility when you train a model. You're creating that model for a long time. It's a bit like a puppy at Christmas.

It's for life, not just for Christmas. And then conversely, the cost of inference to access these frontier models has dropped dropped. So the decision that you have to start with when you're looking at workflows is economic and interestingly think of it like this and this is a new mental model you are going to have to use some things of course you're using a sunundry of software solutions right now and I'm sure all of those software vendors are rightly coming to you going we have the answer to your aentic AI woes just use X Y and Zed and there's going to be an absolute legitimate case for you to do in scenarios. So this use is really important. But conversely, you are a specific business that has a specific unique selling point. You're going to want to compose Agentic solutions. use those frontier APIs, those the Open AIs, the anthropics, the AWS. Of course, you are. Absolutely. And actually, this is where I see around 80% of my customers choosing to build the Aentic solutions right now. They don't want to train those models. They just want to hit the frontier model. And whether they're using Haiku, the small model or Sonet or Opus 47 available just this last few days, that's what they're choosing to do. And then if you need to build, if you have an edge case where you need special latency, special knowledge to be fine-tuned into a model, absolutely fill your boots. And as Franchesca talked about this morning, Amazon Bedrock Agent Core we believe is there to help you achieve your goals in regards of the containment, the simplicity, the security, the observability that you're looking for. But day one, we're seeing that frontier model does a lot of things. And the risk of building your own with that training curve still going up is have you built something where a frontier model can actually give you an inference cost which cheaper than you maintaining that model. That's why it's an economic decision first and foremost and the team to go and build is very different to the team compose that's to use. Let me show you an example of three customers I've worked with a recruitment platform. They are using orchestration and coms from their existing vendors for both email phone. Absolutely they're happy with the agentic solution but they also use the frontier models to do application matching. Now this has been done for a long time with machine learning but they wanted to move to an agentic system. So they used again matching of a resume to a job. The frontier model returns a pass or fail of 90%. Haiku really good at this but at scale they realized they could do it cheaper by taking those results and building their own. So that's what they did. customer service, queueing connect, amazing aentic AI solutions. But again, this customer wanted the hard stuff to go to a frontier model and then eventually wanted to do sentiment analysis at scale across all of them. And for cost effective service, they built their own model. Supply chain optimization, you get the idea. So optimizing the economics and understanding that for as a leader really, really important, really important. One of my personal AIC AI systems, by the way, I used 12 Opus agents, did a run, it consumed 2. 1 million tokens, cost me 45 quid, one run. That isn't going to scale when you got millions of customers. So things like batch optimization, caching really important here. So the economics is what a good thing to answer first and then we're seeing a huge change in the data space across this. So where data engineers used to build integration pipelines, they're now ensuring source systems are clean. Because if your data is not clean and a lot of data systems are now being built in Python, if you're not building a podantic layer to make sure that data going into the agent's correct, expect problems. Data going in, you're going to get a bad call. data an agent echo. Bad things happen. So yeah, your data's got to be clean and curated. Under compose, data engineers were building rag pipelines and vector databases. Well, that goal-based agent can now write that better than they can. Now, context is king or queen depending on who you are. That is important. The ability to help an agentic system understand the relationships with the data in my experience is everything. Moment you got a problem, you've not given the context. One really simple answer for you here. I was working with a financial customer building an agentic system. They assumed that an ETF that tracks the price of silver would understand the price of silver. No, not unless you put that into contacts. The agent won't and it will get really confused on the two prices. All the way through to build where data engineers create training sets. They're now composing data to help you train

data automatically from whatever that frontier model has done. So this is changing across the board but the lessons for us in data are still consistent. Every data should have a business owner. Clean unique data advantage is your competitive advantage. Data engineers are becoming context architects and monitor data quality not just data flow. Put the controls in for it. This is not just a case of connecting it to a SQL database. And this slide is important. I hear somebody on the previous question asked about pricing. There is no credible model that I have been able to find right now for monitoring and measuring NPV or ROI prior to going into this because the simple fact is you cannot at the front end understand where you're going to save the cost, how the data is. You can't verify that at the start of a project. You would spend three or four years trying to evaluate that and get nowhere. And without a reliable framework, things aren't being approved. What I have seen work both at Amazon and with my customers is working closely with the CFO office. Embed a financial analyst with that team. Have them understand what the opportunity cost is with time saved, with data sets, with decisions, with outputs. Hour by hour, the scope is now incredibly flexible on what value can be achieved. And for us as leaders, we've got to know then are we pivoting or persevering an idea really quickly? Because the truth is, as it's been mentioned already, we're moving from builders to orchestrators, not just for our team, but for ourselves. This goal-based agent has really disrupted things. And the shrumpian disruption cycle does not stop for anybody. So, what's happening in the world of talent right now? Well, Martin Fowl, a big fan of mine, he coined the termed strangler fig um pattern for those of us that deconstructed monolithic applications before. He has a really interesting post on expert generalists, which I love. Now, all of us in the room have tenure and experience otherwise we wouldn't be in this room. We've stepped on those mistakes. We've learned from those things. actually makes us pretty powerful domain experts in knowing what a secure available system is. We actually make pretty good builders. It was interesting on the panel this morning that individual that built his own home control system. I guarantee he learned a lot doing that with one of those building agents. And this is what's happening. So domain experts are pushing outward. Generalists are deepening their domain expertise. This is leading towards this renaissance developer as Verer Vogles talked about it in his final keynote at reinvent last year and you see this playing out. Anthropic had a competition in this last few months. Look who won. The second place person was a cardiologist from Poland who built an AI agentic care platform that guides patients after they leave the doctor's office. He built that. He knew what was wrong. He had the insightfulness to use a gold-based agent while he was flying around the world with just Wi-Fi to build this. Look at the first place, a lawyer. Look at the third place, a cardiologist. Look who wasn't on there, a developer. Wow. So, think in your business, who has the domain knowledge? We're moving from a world where we had specialist squads that we used to put together based on the business outcome we're trying to achieve with a diversity of skill sets to a world that is starting to look a little bit like this. generalists, often software engineers who now have a deep understanding of a business outcome, a process or domain experts reflecting inwardly to now look at orchestrating that entire workflow. Not own, orchestrate alongside business process experts. Often I see lawyers dropping into these teams when they're doing it alongside those tenured software architects that have guided you and becoming a team in their own right to instantiate this make it real. But before you rush here, there's another reality that's occurring. Some really interesting patterns. Let's start on the left here. This was a team called project mantle in Amazon Web Services where we wanted to fundamentally rearchitect the layer underneath Amazon Bedrock. We thought this was going to take us a long time, maybe even a year and a half. And Anthony Lrini, one of our VP

distinguished engineers. Um, we have only a few of these folks in AWS, of course, our most tenured engineers along with what we call level seven principal engineers. Again, some of our most senior engineers who have proven sign code came together and shipped it in 76 days. These are people that know what exceptional quality of code looks like. They do the code reviews. Look how it supercharged them in their delivery time cycle. But the bottleneck is shifting. It's not execution now. It's decisions. It's product management. And for a long time, for 30 years in my career, it has been the long tail in getting things done. Suddenly, we're seeing that invert. So, our domain experts and our business leader colleagues aren't ready to make decisions. If you don't know what you're doing and you're just arbitrarily accepting code, then we're starting to see more vulnerabilities creep into it if you've not got the right support around it. And for those newer folks, they don't understand what they're shipping. And that is why when you heard Franchesca in the keynote this morning talk about security agent and devops agent. These are the companions which are going to go into those teams to remove that heavy lifting so they can focus on the domain expertise. They can continue to accelerate their demat um static and dynamic security code reviews. They can accelerate their pen testing. MTR to finding out the skills because for all of us who looked at that twoperson team they recognized a huge problem and I did straight away on call. Now I've looked after many on call teams in my career and when a team used to get to four people for on call I used to really start to worry because you get one person ill one person off on holiday maybe another person on off on holiday that one person left isn't having a fun time. We haven't fully thought this out or solved this yet. I don't have all the answers. I just want to share the trends. But we are seeing a dramatic log analysis improvement in Amazon. You know, detecting that signal from the noise. I mean, just look at some of these um secop engineers used to spend 6 hours analyzing NOGS now only 7 minutes. 50x productivity lets them detect and respond to threats faster than ever. We monitor 400 trillion network flows per day. looking for those patterns. So for us, extracting that signal from the noise from the humans and by the way that's only going to grow is really important. So when we think about jobs declining, bear all of this in context. We still know that P 0, P1, P2, P4, P5, humans are going to be involved in those higher incident limits than they still are right now. The human in the loop is as important as ever. But we do see this changing the operating model. We've gone from this pyramid that we've all seen for years through to people trying to put managers or people in charge of agents. I haven't seen this working really well because those domain experts need to understand that orchestration flow of what's going on. I do see this occurring. These seniors are 20xing their productivity and we're cutting back on the juniors. I would fight this. I would say here is where we're actually going where we've got to actually look towards the hourglass organization. We have to keep looking at bringing in the juniors because sadly right now we do have a bit of a junior hiring crisis. 73% entry hiring level collapse in European tech according to Ravio last year's study. The 7% by the way of new grads entering big tech has dropped from 15%. 7. 77 junior headcount decline, 9% employment growth in those senior roles. Now, I'm proud that Matt Garmin said this statement because all of us in this room, I think, remember the moment we got our first job opportunity, that first official you've got the job. How good was that feeling when we got that? Would we deny that to the next generation? We've got to solve this. And I think we are and will because we've got to because every single revolution by the way in human history has shown us that jobs explode. Now all of us are going yeah but this time it's different really is the data really showing that because actually when you look at us suddenly you see the senior people's comp rising the fastest growing US top job title AI engineer 1. 3 new million new AI roles created according to the web 67,000 open software engineer roles uh opened and virtually 52,000 layoffs

So we are going through a job family change. There is no doubt about it. Now I put this leveling on the board because I wanted to give you a little bit of an insight into how Amazon does this really quickly. So a level four engineer is typically a graduate level engineer for us. Uh through to level 5, 6, 7, 8. There is no level 9 in Amazon. Jeff Bezos has eliminated it. Through to turn 11. That's it by the way. That's that's it. There is you know that's it. Um we have a responsibility to understand how to help those juniors go from here to here and understanding as that person asked the question in the previous session how do we help them go through understanding those failure patterns the responsibilities in their code and we're trying in Amazon to figure that out because if you stop training the juniors where on earth do your seniors come from in 5 to 10 is now moving on to the organization. I've got some news for you here and you might have a complete health reaction to this and that's fine. I'm just sharing what I'm seeing. If your organization looks like this, you're going to have a hard time with aentic systems. I'm sorry to say because the challenge here is that we're now bringing in line systems that aren't deterministic and we have optimized for determinism but in agentic AI systems non-determinism a feature not a bug and this path to high agency we all understand what managing a high agency individual looks like this requires a leadership shift and we've spent years building these toll gates or should it be toil gates to help these deterministic systems find their own path. But really when you look at an agentic system, much like a river busts its banks, agents do find their own path. You've got to watch them what they're doing. And I love this quote from Rory. Most business is probabilistic, but everyone in business wants to prove and pretend that it's deterministic. So every spreadsheet is in some ways an act of pretense because it's past information which you pretend has wonderful predictive value. Nobody's been there, right? Have they? I have. So some principles before we move on to the penultimate section. Match your operating model to your growth stage. Put humans on judgment work, agents on execution work. And I'm sorry to say if you still have engineering and operations as two different things, you are going to struggle with the genic systems. And here's why. Runbooks are deterministic. Agents are not. Ticket culture kills the context. No authority over the model. No ability to change anything. No authority over the data feedback loop of death leads to that statistic from the MIT Nandanda part first of all. So what model does work? work? What I'm seeing is this embedded pod model does work. So how it works? Three to five engineers per pod. What is the business outcome? They're solving workflow. Notice I didn't say product. I didn't say MVP. I said workflow the hourglass strengthens it. Seniors already understand production. Agents are absorbing some of that junior work, but we've got to help those juniors now get to that senior level much faster. Understanding what the responsibility of security, durability, availability, regulatory looks like is really important and we are only just now starting to solve that. By the way, I don't have the immediate answers for you. So yeah, some interesting different dynamics I'm seeing play out here depending on the skill sets, depending on the country, dispend depending on the workflow around the world that you're looking at. And that 3 to 5 million by the way is for the extreme end of building some models that I've seen some customers do. So yes, this model looking at a business outcome is where I see success working and this team is now going to create that moving forward. They're going to use other agents to manage the encore workload and assist them relieving that burden. But here's the question. Once you get beyond three or four pods, then the real decision to allow this empowerment in action to actually take place is going to be on the platform that helps them across these dimensions. If you're any scale of 10 teams or beyond because without a platform team, you're going to have inconsistency of build. You're not going to have the observability which is crucial in an any sort of regulated

environment at our not even regulated. You need to know what is going on with these agents with a platform team. Yeah, I'm getting one paved road. I'm still giving the empowered and those platform teams have got to have absolutely really good emotional intelligence to empower those pod teams, not hold them back. So this is the model I'm working now. Many of customers I've seen have gone, well it's all right. We have site reliability engineering. We have S sur. Here's the problem with S sur. By the way, it works very well for Google who are an exceptional company. They're a competitor, but they're an exceptional company because their SRRES are the most senior developers that exist in Google. SRRES are software engineers. They have really interesting responsibilities. is but if you're just renaming IT ops to S people same skills that is going to fail and I have seen it fail with customers so an embedded team model with the right platform supporting them and that's not necessarily the platforms you have right now in fact it isn't you're going to need supplementary ones you're removing the friction from those pods that's your focus not controlling the pods removing the friction from those pods is crucial And finally, governance. Everyone's asking me about it quite rightly. So, Tunisia touched on it with ethics. When we look at governance models around the world, there's only really one that I've seen a government produce right now, which for me stands out, and that's the Singaporean model they announced this year at Davos. Simply four things. assess and bound risks up front, human accountability, technical controls across life cycle, end user responsibility, pretty clear. And then when you start to look at how the different components actually map to that, whether it's identity management, deskkilling prevention, it's not legally binding yet, multi- aent risk, and some of those five risk categories, we can start to map this to how actually businesses think. And when I looked at actually the Amazon tooling to actually overlay into that, I was pretty happy. I was pretty happy because this is now actionable for our customers to overlay into it. And the final elements when you really want to lock this down is policy as code. And as much as we've become experts at policy as code in cloud formation and your controls and control objectives, we also see it utterly crucial in agentic systems. So to take it away because I'm one minute over time when we look at the economics map your workflows to the tiers discipline. Measure the verification tax because you do not want 2. 74 times more vulnerabilities coming in to you. You want to get them down. You want to escape model A. And for those of you that are still running in it, I'm sorry. It won't work for Agentic Systems. Implement that governance that's appropriate for you. Audit your seniority mix. Be prepared to bridge the gap from juniors to seniors and protect that jouring, that junior learning path. Now, I'd like to invite a customer to stage now who's going to share their journey, and then I'm going to open it up to some brief Q& A. And one of these customers who's been dealing with these challenges for real is Brooklyn Solutions, a UK scaleup that's been quietly building AI powered supply management for some of the most regulated organizations in the country, including the Ministry of Defense, Danska Bank in Europe. The kind of customers who do not accept it'll probably work. here to walk us through their aentic AI journey. What worked for didn't. I'm happy to announce the chief technology and marketing officers to stage, Nick Francis. Nick. — Thank you, Jonathan. And uh good afternoon to you all. As Jonathan said, I'm Nick Francis. I'm a co-founder and chief technology and marketing officer at Brooklyn Solutions. Um, Brooklyn is a supplier management platform. We focus on helping organizations deal with their commercial agreements and all the risks and delivery that goes along with that at scale. We work in financial services across defense and energy sectors to name but a few. Prior to Brooklyn, I spent 20 plus years working in organizations similar to Jonathan Barkclays, Lloyd's Commerce Bank. So, I've been on both sides of the fence as a buyer and a product builder. Our journey with AWS started eight years ago when Brooklyn was born, but our journey with AI started around 3 years ago, and we went through a number of

phases in looking at what it could do for us and our customers. We started with basic use cases such as, as you'd expect, document summarization, formatting, extracting key points from larger texts, essentially making our application smarter. Phase two, we went on to looking at Agentic AI from a conversational perspective and we gave birth to something called Ask Brooklyn, which essentially is putting a bunch of bots in our application that's backed off to a number of large language models so they could be naturally language queried by the users. Phase three moved us into Agentic AI where we started coupling up that intelligence with the capabilities of the platform and the agents being able to actually execute within the software. And phase four is where we're heading which is onto an multi- aent multi-agentic AI solution. By doing the previous steps, what we were able to do is come up with a rich set of use cases that really lend themselves to Aentic AI from contract intelligence, risk, supply management, coordinating together. We never had a grand plan. Each phase found its way with the previous one, finding out things for us and use cases that could work better. What we had initially was we moved from the old way which is the first two steps and phases we were in where we used to push information into what was effectively a steel box into an intelligence to get output out and use that across the application. But the new agentic way we're leaning into is actually teaching what was in the box, how to use our application for us through APIs, endpoints to actually shift and do a step change from advising into the agents being able to act on behalf of the users. Jonathan spoke about data and context and we learned that lesson the hard way. We assumed naively out the gate that we could cook up the AI and the large language models of all sorts to our standard SQL database in the application. How wrong we were. That database was built for development. It was built for an application that has a lot of overlay and UX and information for the user to use it. So the large language model couldn't make a lot of sense out of it. And the response it gave were weward at best. As an example, we have a segmentation system in Brooklyn which essentially just buckets suppliers from critical to non-critical. In that table in the database, it essentially says numbers 1 to five, critical, important, transactional, etc. What we've had to do now, as we've learned the hard way, is add context to all parts of the database as to what constitutes a critical supplier, what governance a critical supplier is expected to go through. And by doing that on a iterative basis across the database when delivering our use cases, we get much better results from the AI to the point that AI started giving us things that we didn't even expect. They started to combine tools and use things across the platform that we had no idea they would do. I think the rule here is don't wait for perfect data. Start with what you've got. Start with a use case and iterate on top of your data on those use cases to get to where you need to do to know. From a team perspective that we're building the solution, we've had to adapt. Traditional development was we'd spec something out and then work on it for 3 to 6 months knowing exactly where we'd end up. Now we've got a partner in the AI and the large language models. You can't have that kind of determined outcome when the models themselves are evolving outside your team's remit. So what we have to do is more sandboxing, piloting, more experimentation, more feedback loops, more iteration within the development cycles to play for that unknown. And sometimes, like I said, it surprises us and go both ways. It has the ability to do things we didn't expect at a benefit level, but also sometimes to things we didn't want it to do. And then we have to tune it. We have to manage that through things like bedrock guardrails. We define B boundaries which the agents operate in through the prompts as well. We ground our data in reality and we make sure that's effective. What we've gone from is builders to orchestrators. So, everyone in Brooklyn that's a developer and in all other teams have been asked to work with agents and build their personal team and functions with concluding AI as a resource in that team. We look at it at a task level, not a whole process level. Does AI genuinely improve the situation or is it AI for AI's sake? And then we rightize it to the agent. We build for reuse using the same pattern over and over again. So we have examples of agents that review and recommend and work across different context as the data changes. This mental model leads to mixed teams

where we're pairing people with agents. The same principle in building effective human teams is applied but including the AI from a product perspective and what we do with our customers. We work in a regulated environment. We make sure that human in the loop is very a reality of what we have in the platform and Jonathan mentioned it. We essentially always have a human start the work and a human end the work. But we may have agents of all different sorts in between that taking place doing steps that are now highly automated that weren't to begin with. But what that makes sure is the human themselves are still accountable for the work that gets done. We work with regulated clients. They need that accountability. So we make sure that's a deliberate design choice that we don't automate everything end to end. The benefit is though now with agent core we start getting observability the ability for what agents do is logged triggered looked at from a cure duration perspective a cost and every token is accounted for within Brooklyn we have a concept of the 5x expectation we're not holding managers and teams to this as such but the 5x expectation is for them to get five times the output for as little as 25 increase% increase in opex. Now, you're not going to be able to do that in people. So, we're asking them to fundamentally look at the way that they're doing things and increase that output to 5x where possible by using a series of tools and agents rather than in getting in people and personnel and how they'd scale a business. In that regard, we keep it honest. So we have quarterly executive reviews where we look at what we delivered, what we learned back to the point of regularly getting together, regularly testing, regularly iterating internally. And the way we work with our customers at workshops is to help them find their initial use cases. And we do that on a way of looking at a combination of frequency and variability where we find tasks that are in processes that happen a lot that aren't really that variable. So they have a known output and a known format. We mark them as something that AI is perspectively good to do or good to look at. How we do that is we sit down with subject matter experts from all departments and all divisions and typically within your businesses you'll find these people as well that just through conversation they'll tell you these things that are mundane high frequency not that variable that happen day in day out that starts you identifying your use cases that you can go after on a volumetric basis and where your biggest benefits will be. So in closing, momentum beats perfection. In Brooklyn, we had no grand strategy, just a basic use case that we learned from and we built from there. We've got a backlog of over a hundred now, but each phase revealed itself as the next one closed off. The mantra, as it says on the slide, momentum beats perfection. Don't over plan it. Don't wait for perfect data. Don't wait for the technology to settle, otherwise you'll miss the opportunity. So for you guys in the room, if you don't know what AI can do for your business, start to find out. And the only way you do that is get started in a small part of the business at the right level with the right level of detail in the lines that I just mentioned. Thank you.