Seb Leal Bennett leads architecture and cloud for a major European investment bank, where the margin for error is basically zero. On Security Visionaries, he tells host Emily Wearmouth how regulation shapes cloud architecture from day one, why roughly 30% of cloud spend still goes to waste, and how zero trust holds up across hybrid environments. They also debate what changes when an AI assistant stops simply agreeing with you.
Regulation comes first. Seb's team only builds on cloud services that have already cleared a rigorous compliance review, then designs around what's approved rather than retrofitting compliance onto a finished architecture. That same discipline covers data and AI sovereignty: jurisdiction, data center location, and backup zones are core to the design, not overhead bolted on afterward.
On cost: roughly 30% of all cloud spend is waste, according to Seb, mostly from over-provisioning rather than unused services. His team runs an annual OKR specifically to find and cut that waste.
On AI: Seb treats it as a second opinion, not a replacement for his team. He uses it to pressure-test architecture documents, prompt for edge cases, and even diagnose a broken home CCTV system from raw log files. Emily and Seb also compare notes on what changes when you stop letting an AI assistant simply agree with you, after Emily's own experiment asking Claude to drop the sycophancy and get blunt.
The throughline: in a heavily regulated environment, guardrails and good architecture patterns move faster than ad hoc decisions, and the same discipline that keeps regulators satisfied is what makes room for AI experimentation without losing control.
Emily Wearmouth (00:01):
Hello, and welcome to the Security Visionaries podcast. I'm your host, Emily Wearmouth, and today I'm joined by Seb Leal Bennett, who heads up architecture and cloud for a major European investment bank. He spent his whole career thus far in financial services, which I think we can agree is probably the sharpest end of some of the most highly regulated and highest stake tech environments that you might find. He's a pro in architecting for cloud, resilience and security, where the margin for error is probably zero. Welcome to the show, Seb.
Seb Leal Bennett (00:32):
That's great. Thank you.
Emily Wearmouth (00:33):
It's good to have you on.
Seb Leal Bennett (00:35):
I'm looking forward to it,
Emily Wearmouth (00:36):
Yeah. I've got some grilling questions, and I'm going to dive straight in actually, because this highly regulated point I think is really pertinent. And one of the reasons I'm really glad that we got you on. What I wanted to start with is thinking about what does it actually mean when you are architecting for cloud and you've got all of these regulations probably sitting on a shelf somewhere, are they front of mind and you start with that, the constraints that they put in place and then think about what's possible within them? Or do you architect what you think is the right approach and then put it through a filter of, hold on, does it meet the regulations? What's the order in which you think about things?
Seb Leal Bennett (01:15):
It's definitely the former. It's not build it and see what happens. It's very much we ensure that the services that we're using in the cloud have really gone through an extremely rigorous process when it comes to what you can and can't do with them, the data you can and can't store in them and the ways you can use them. So therefore you know that the services that are available to you to architect or build against have already been approved. However, it's still your responsibility when using those services to make sure you use them properly. So if you do have that data jurisdiction or sovereignty concerns, making sure that the service you're using are in the right zone, in the right area, in the right region, and you can demonstrate that. So it's very much we are heavily regulated and we ensure that all our service that we use adhere to the same regulations.
Seb Leal Bennett (02:00):
And we have specialist teams that go through this day in, day out, and it is a very hard process. I did it once for one of our services and it's like, "Ooh, these guys do a lot."
Emily Wearmouth (02:10):
How much do you think it slows you down? If you compare your sector to other sectors, does it limit the speed at which you can embrace innovations?
Seb Leal Bennett (02:20):
A little bit, I suppose, but don't forget with large organizations, so you could be a large tech organization and you get slowed down because it'll have its own policy and process to go through. But we also need to make sure that we're using it properly because if we get it wrong, if we're out the market and we create market impacting events, or if our data gets breached, the reputation damage is just through the roof. So we can't even risk that. So it's better to go slow and steady, get it right the first time round, or rather than be the poster child that the regulator holds up saying, "Look what they did wrong." No one wants to be that person.
Emily Wearmouth (02:54):
I introduced you as cloud and architecture. How much of what you are doing is in the cloud? Are you fully cloud or do you work in environments where you've got a hybrid on-prem cloud mix going on?
Seb Leal Bennett (03:10):
It's very much dependent on the application and the available technology. So anything that's low latency, that's going to stay on-prem and that's going to be in the colos next door to the data centers. If you've got something that's just an average, say three tier application, you've got your middle and back end tier that can go into cloud, then that can go there. As long as it makes sense. Don't just push stuff out there because you've got a metric that says you have to move 10% or 100% of your applications over there. As long as the position makes sense, then make sure you go for it.
Emily Wearmouth (03:42):
And how much complexity does that hybrid approach bring in? If you are all one thing or all another, I guess you're architecting a single approach, you're immediately duplicating two different approaches, two different systems and structures. Where are the complexities within that?
Seb Leal Bennett (04:00):
Well, again, it depends on the approach. So you could have, if you do take a hybrid approach, so the hybrid approach could be the fact that you have your non-production estate in cloud because you can turn it off, you can be efficient, you can be elastic. It's not on that evenings or weekends, you don't need it. Turn it off to save the money. That can't go into production in cloud because you haven't got the services you need. So you maintain those two stacks, or you could take an approach, you're either taking all the application, all environments on-prem or in cloud. So again, it's really down to the architect and team to make the right decision there. We can guide, we can help, we can point in same direction and give them information, but it's not like one size fits all. We very much rely on our architects to help us make those right decisions.
Emily Wearmouth (04:49):
And how much is there an advantage or a disadvantage from that dispersed decision-making approach that you're not mandating a particular, across this organization, this one thing has to carry. You're looking at a case by case, everybody's requirements are different. How much does that introduce risk or potential for an unwieldy stack where everything is tailored and unique to each business case?
Seb Leal Bennett (05:17):
Well, the way you get around that, not getting around how you address that, sorry, is through just good guardrails, good standards, good patterns. So you're not letting every team have the same conversation 30 times because the first team to get the right conversation through the architecture and governance process, that is the pattern that gets repeated. Otherwise, you've got about 30 teams, you're probably 60 different ways of doing the same thing and that's not very efficient and that's why architecture and governance is really important. People think that we slow you down, but the flip side is if we do let the cats out of the bag, so to speak, it's a bit hard to get back in again.
Emily Wearmouth (05:55):
You talked about sovereignty earlier, and I wanted to hit on sovereignty because it is the latest. We started the year and AI was the buzzword. AI is not going anywhere, but it feels like sovereignty has become the buzzword, whether it's relating to AI sovereignty or digital or data sovereignty more broadly. As an international organization, how are you looking at this growing interest in sovereignty?
Seb Leal Bennett (06:21):
I think actually we are okay where we are right now, by now because we've had the concept of where data can and can't be from the beginning of time in our organization. So this isn't anything that's new to us. We have regulations that control what we can and can't do, always have, always will. And so it's really important. You can't let your data get out of the zone in which allowed, where it's like the Swiss data, it could be Liechtenstein, it could be Taiwanese. You got to make sure that the services you're using have been signed off also by the regulator in that region to say they know that that cloud service provider gives you the right tools in place. Usually make sure that you do it properly with the applications. And if data is creeping outside the boundaries, you have to have the tools in place to find that and see that and address it and most probably self-report to regulators say, "Hey, we made a mistake.
Seb Leal Bennett (07:14):
We're sorry. Let's work this through." Never hide it.
Emily Wearmouth (07:17):
So you talked a minute ago about sovereignty, and I wanted to swoop around on this one because it feels like a really hot topic at the moment. There's been a few incidences on a macro political level recently where we've seen what it might look like if certain nations decided to control the trade export of some of its digital services. And it's become a bit of a resiliency conversation around sovereignty helping with that, that if you've got everything happening locally within your sovereign market, then you're not going to be pushed around by regulatory changes in other nations. But of course, the global nature of infrastructure is what gives it resilience in other ways that if you have outages in certain countries because certain black swan events as they're often called, you want that backup, that nearby, but perhaps across a border backup. How do you think about sovereignty and how you approach things?
Emily Wearmouth (08:12):
Is it resilience or is it not?
Seb Leal Bennett (08:14):
Interesting. The law will prohibit you from the data leaving a certain jurisdiction. You are not allowed to store it outside of the governing body. I mean, China very strict at the province level. Obviously the Swiss government are very strict and even the UK in some spaces. So you need to be resilient within the eye of the law. So there are multiple data centers or regions for a cloud service provider in UK, in France, in Sweden, in Norway. They're all there. So you've got to know where your data is and what zones it in and therefore act within law using those services because you can't store it somewhere else. So also you've got more than one cloud service provider and you've probably also got your on-prem data centers. So if it's really important that you couldn't survive a region or a zone going out, you can either back it up internally, that's possible.
Seb Leal Bennett (09:14):
Or taking multi-cloud approach, expensive. I know because your data ingress and egress cost, it really depends on the criticality of that service and how you need to architect that service to be able to withstand whether it be geopolitical or natural disasters where the data centers are. And that's why it's also really important to understand as you're able to, the locations of the zones or at least the distance between them with your cloud service provider. So if you know there's a flood in your zone one, you know that if your data is also replicated zone two or zone three, you're fine. But if you've got cloud service providers that have them all together quite close together or two of the three, you've got to know which two are close to make sure your backup's in the other one. And that's really important.
Emily Wearmouth (09:59):
And how are you getting that sort of information from your vendors? And do you think you get more information if you're at a large financial organization than perhaps some of our listeners may get in smaller organizations?
Seb Leal Bennett (10:10):
I think it depends on your relationship with the cloud service provider. Sometimes you can get information. The actual location, no, that definitely is impossible to get, but you can ask them what's the distance between them. And I don't think that's an unreasonable question to ask them. The service provider we use, because when you create a subscription, you can say the zones you want it in, but each subscription, zone one will be a different actual physical zone under the covers. So therefore you haven't got everyone going to zone one and zone three, for example. And that prevents everyone piling into the same zones. But they do offer API to actually undercovers, what is the physical zone? Is it zone one, two or three? So your zone three might actually map to physical zone two. So you can use that information to work out physically where it is.
Seb Leal Bennett (10:58):
And then with the other information, you can start making the right choices about where you're storing your data.
Emily Wearmouth (11:03):
It sounds almost unnecessarily confusing with the labeling. I feel like some clarity could be introduced there.
Seb Leal Bennett (11:11):
It is, but it's done for a very good reason. It's to stop it from piling into zones one and three, for example, and then zone two stays empty. So you can understand the reasons behind it.
Emily Wearmouth (11:22):
Yeah. I think that's a really useful question of ask if you know that there's certain things that has to be obscured for security reasons, asking about distance between could be a very useful question for some of our listeners.
Seb Leal Bennett (11:35):
And you don't have to have the exact, is it one or two kilometers? Is it more than 10? Is it more than 30? So you can really obfuscate the information that they need to give you so you can make the accurate and informed decision.
Emily Wearmouth (11:49):
And do you have for yourselves as an organization, or do you advocate for a guideline of what you consider to be acceptable or is it a bit more fluid than that and you see what they are offering and then determine risk based on the particular use case?
Seb Leal Bennett (12:05):
We have our own policies and procedures, so we know what is acceptable and the distance between data centers, because when we're all on-prem, we had distances between our data centers and we try and adhere the same standard or more when it comes to our cloud service providers.
Emily Wearmouth (12:21):
I guess in some markets with larger land masses, it might be easier than. I mean, we are both sitting in the UK. The UK is not one of the larger countries in the world. Landmass is quite restrictive.
Seb Leal Bennett (12:33):
It is. You end up being east or west of the country or either side of London, for example. It's just because you start looking at what are the events that could cause both data centers to go out. And in all honesty, if that happens, I think we've got bigger problems to deal with than working out how to stand up in a certain service.
Emily Wearmouth (12:50):
Yeah, absolutely. Can we talk about zero trust?
Seb Leal Bennett (12:55):
Yeah, we can try.
Emily Wearmouth (12:57):
So we've talked a little bit about you running this hybrid environment, and I wonder whether when you're looking at access and access infrastructures, whether you have to create a hybrid approach for that as well, and then whether you have zero trust policies or advocate for them and how you manage that across a hybrid environment.
Seb Leal Bennett (13:17):
So the underlying authentication and authorization systems are the same. We have our bank standards, we have our bank systems, and they integrate natively with the cloud sales provider ones. And therefore you haven't got entitlements being controlled in three different locations. You've got one, you've got one version of truth, one source of the truth, and you've got to make sure that you follow the principle of least privilege. So you don't just give everyone access because it's easy. You give them the information and access they need to do their role and that's it. Otherwise, 17 things can go wrong and you just don't want to be in that position. So yeah, don't split your entitlements, your systems up. You haven't got a cloud one, an on-prem one, you have one and that is your version of truth.
Emily Wearmouth (14:03):
Can I ask about AI? Some people groan when I say AI. It just seems an unavoidable topic because I'm intrigued to know how much in the ownership that you have over, uh, I'm guessing you work with a very large team with a lot of sliced up responsibilities. How much is AI impacting what you are looking off at the moment or changing the way you're planning for things?
Seb Leal Bennett (14:27):
AI is everywhere. You don't realize where AI can help. So completely off topic, I was speaking to someone the other day about AI and his daughter is into dance and singing. And I was like, "Well, where can AI help with that?" And he was saying actually for singing because it sees it as a tone. And all of a sudden his daughter is completely skeptical about anything that could even impact her career when it came to AI, all of a sudden starting to use AI to be more pitch perfect on her singing. Can't do video just yet because that's freeze frame, but you don't realize actually how AI can help and they should start playing with it. So, if you don't play with it in your professional life and also your personal life, there are things at home you can use AI for. Great example, recently I've got a load of log files for a CCTV system that keeps going offline.
Seb Leal Bennett (15:17):
I just uploaded in Claude and said, "What's going on?" I was able to get three failures and it's able to pinpoint that I mucked up a VLAN configuration, which is great. There's no way I would've even done that on my end. It would've been a support ticket. But back to work,
Seb Leal Bennett (15:31):
try it, tinker with it, play with it. What's important, what are you trying to find out? Because if you're doing something more than once or twice, pretty guaranteed that a decent prompt can help you out. And also what I think people miss is they try and write the prompt themselves, use AI to write the prompts, and that can really help you go forward as well. So in the architecture space, you can start and say, "Well, actually, if I've got all these principles and patterns and guardrails and enterprise requirements, can I codify those so therefore I can run a few agents across my code tree or my solution architecture documents or my design documents?" And the good thing there is rather than as an architect trying to find the weakness in design in a 30-page document, the AI agent can say, "Actually, we think you should focus on here, here and here because you're not there to rubber stamp really good behavior.
Seb Leal Bennett (16:22):
You're here to understand the exceptions and it's better to have a 10-minute conversation on why you're going against strategy versus a 40-minute conversation, the fact you've got BCM right.
Emily Wearmouth (16:33):
Yeah. And what about AI use within the team? Are you seeing it change your views on how you might resource the team longer term or what those models look like and how you might bring new talent into the team and what it might change how you're looking at that new talent?
Seb Leal Bennett (16:51):
I don't see AI as replacing the team. AI is there to augment the team be more efficient and effective and also giving an opposing view because sometimes you ask it a question, it gives you response and then says," And also. "And sometimes the and also makes you think," Oh, hang second, I can go different direction with this. "So you can use it either to do tasks like just writing emails for you or changing the email, or you can get it to be part of the teams are working with you and feeding back or even coming back with solutions and being more autonomous. So there are lots of different levels that you can integrate AI with. It's what you're comfortable with and then what you want to do next.
Emily Wearmouth (17:29):
I would argue sometimes it's what you're not comfortable with. Last week I was feeling a bit spiky and I used Claude and I asked Claude to stop being so sycophantic. It already got hang of me a while ago and wasn't too bad, but it was just really bugging me and I asked it to be downright rude. And for all of last week, it was so aggressively rude that I've had to change it up again and say," No, you can be a bit nicer to me. Thank you very much. "But during that week, it was suggesting things that I don't think it would've suggested before. Some of them were completely wrong. They were just argumentative for argument's sake. But sometimes that taking down the barrier of what I was comfortable with and how I was prepared to be spoken to, really, there were a couple of bits I thought, yeah, that wouldn't have happened this week had I not allowed it to swear at me, for instance.
Seb Leal Bennett (18:14):
Absolutely. So it's all in the prompt and how you want it to work with you. So you can say," Don't always agree with me. I'm not always right. Your job as this particular bot or agent is to not disagree with me, but work against me, but also find areas that we haven't explored. "And it's just remembering to ask those questions and ask those prompts, and sometimes it can be a bit time-consuming. So you've got lots of people asking the same things, have a prompt store, copy, paste it, bring it over sort of thing. So there's so much we can do in this space and we are literally just scratching the surface.
Emily Wearmouth (18:46):
Are you doing anything systematically with your team informally maybe even just to build up that knowledge across the team? Because what I'm finding is there's some people that are really comfortable and are running ahead, and then it's well worth putting some structures in place to help those who are less comfortable or have less time to just tinker. Maybe they have commitments that they can't spend four hours on a weekend upskilling to make sure that the team moves as one. Do you have anything that you're building for?
Seb Leal Bennett (19:12):
I think it's important to share. So with my team, I meet maybe two weeks without asking anything and I started saying, well, who's doing what about AI? Tell me what was interesting and tell me what you did sort of thing. And it doesn't have to just be in the workplace environment. It's also at homes, where have you been successful? Where have you failed? And what have you learned? So it's all about just talking about it, understanding what isn't working. And obviously there are people who will have a bit more free time or take the time to invest into it and go one step further. And again, they can come back and say, I did this, so you can all learn from it. So I think it's really important that you do it together as a team, not just one or two people running ahead, but I think that's the way forward.
Emily Wearmouth (19:54):
Yeah. I wanted to talk about security with the Security Visionaries podcast. It would be remiss if I didn't have a question specifically relating to security. And I know you are not the security team, you are working alongside security professionals, but as the architecture lead, I'm wondering whether the security team is in the room with you from the get-go or whether you bring them in, at what stage in the process you tend to bring security in and whether you consider your approach security by design or whether it perhaps isn't quite if you're bringing them in a bit later.
Seb Leal Bennett (20:31):
What you mean by bringing them in later? Because it's not like you're out on your own building application and go, I need to add authentication authorization now because being an organization, you have strict standards and reusable patterns in code that by default brings in security. I think when you're bringing in OSS or other commercial products, I think security is really important and they need to be from the very beginning. So you need to be saying, how should we be integrating this entitlement system into the bank system? How do we make sure that it's the least privileged so you don't over provision individuals? I mean, I've seen situations where people have omitted something by mistake and not quite understood the integration pattern, and because of that, they've been given entitlements where they can go and elevate their friends as admin privilege. Obviously it doesn't happen. They don't do it intentionally.
Seb Leal Bennett (21:31):
They just kind of missed it off. So I do think security is really important. I don't think there's a unified approach to it, but engaging with your CISO team and also making sure that the way you bring applications into the bank, have them built in from the very beginning is really important. Otherwise, you are going to end up with issues. But we've seen it when CloudFirst came about people accidentally leaving their blob store to public use with all the passwords on it or whatever it is. So it's really important that you got that sewn up from the beginning, otherwise you're going to have problems. And we have got that sewn up. The guys are brilliant. They are on it. They're in everything. And that's why when you are taking services from our service provider and you making them available, they are part of that and they're making sure you can lock it down, you can ensure that data doesn't leak and all these things.
Seb Leal Bennett (22:19):
And therefore when you're using it as an engineer, you've got confidence that you're using it in the right way.
Emily Wearmouth (22:25):
It's interesting because sometimes I'll put that question to someone and like you, they're slightly incredulous about how I've asked it. And then the reason I ask it that way is sometimes I put the question to say a security professional and they'll say, "It's so frustrating in my organization. Things are halfway down the line before security is brought in." So it does happen, but it is great to hear that's not your experience and it sounds like you move as one with security as you go.
Seb Leal Bennett (22:50):
Yeah, we have to. There's no room for getting that wrong.
Emily Wearmouth (22:55):
Cost. You work in financial services. I'm sure numbers are part of every conversation that you have, but when you're looking at your own budgets, has there been a change in tone at all around cost and the expectations for reducing inefficiencies and how the way you embrace technology even within your own team might drive down some of those costs as well?
Seb Leal Bennett (23:18):
Yeah, absolutely. So we've always got an eye on that. And as soon as the new technology comes along, cloud, everyone jumps in. It's like a kid in a sweet shop effectively. But if you don't have measures in place to make sure you're doing the right thing, then you're going to be spending too much. And you'll find that as organizations move to cloud, they'll be running their on-prem stack and also their cloud stack. So you're doubling up costs straight away. So you've got to get rid of the on-prem stack as soon as possible. However, even when you're in cloud, the cost can be expensive if your teams don't know what they're doing. So for example, if you look at getting some storage on-prem, you can ask, well, how much do you need? What type do you need? Where do you need it? And do you need backup? You've got about four or five questions that you get asked.
Seb Leal Bennett (24:02):
When you start looking about storage in cloud, they're about 15 to 20 questions. How many continuous read write IOPs do you need? Engineers
Seb Leal Bennett (24:11):
Are not historically designed to answer those questions, so we will get it wrong. And because of that, we over provision. And because we over provision, we pay for that. So you need to have some sort of governance or forum or mechanism where you're reviewing your costs. You're saying, have we over-provisioned? Can you identify where you can save money? For example, you've got all your storage and hot storage when actually cold is fine. There's a big price difference. It could be the fact that your non-production estate is running twenty four seven. It probably doesn't need to be running in the evenings or weekends, so turn it off and turn it on when you need it. And there's so many different ways you can look at how you save money. So therefore, because people are saying cloud's not a cost play, it's an efficiency play. Well, it can be a cost play if you're designing applications right and you behave correctly in the first place in cloud.
Seb Leal Bennett (25:02):
And so getting that magnifying glass out, finding those saves and sharing them. It's not just for one person, one team to do it themselves. You need to have mechanisms where let's say, actually, we just saved 10% of our annual cost. Who else can benefit from that? And then finding ways to automate that. So rather than say, do these five steps, you bring the data to the people saying, we think you've got a 10% saving there, and then track against it. Create an OKR, push it down from the top and you'd be amazed because I think on average, 30% of all cloud spend is waste.
Emily Wearmouth (25:34):
Wow.
Seb Leal Bennett (25:36):
So we are heavily invested in this. Every year we have an OKR that we set across the bank and we track it and we chase it and we looked at and we share, and that's the best thing to do.
Emily Wearmouth (25:48):
And do you think that the lion's share of that 30% is an over provision or is it services that just aren't being used at all?
Seb Leal Bennett (25:59):
It's a mix of both. Predominantly, it is over provisioning. I was actually looking at stats a bit the other day because we've been running ownership since 2023 about how much we saved and we categorized it. And the majority of it was actually say about a third, maybe more a third, was in the over provisioning. And now we're starting to turn things off. We're seeing that actually being quite a big factor as well. But also make your application cloud native. I mean, all the cloud providers saying make it well architect and make it cloud native, make it elastic, make it so it scales from zero to hero as required, which means that even with weekends, it will turn itself off. Simple as that. Don't spend where you don't need to spend.
Emily Wearmouth (26:37):
When people talk about overprovisioning, I always wonder, you've got a business narrative that tends to lean towards optimism. So the business wants to be projecting growth plans and intention to scale up, but within the business you need to be able to read through the lines and see how much of that is bravado and statements that you want to be making. And realistically, do you need to build and provision to an aggressive growth or can you build to a halfway point, but with scalability to cover you if the best case happens? How much should someone listen to the messages that their organization is putting out into the market and how much do you think you need to temper them a little bit to avoid over provisioning?
Seb Leal Bennett (27:18):
So our business know their market, absolutely. They know where they want to grow. We have the data historically, so we know where our high water marks are and we can see where it's generally going up. We know if a market impact event is going to create a new high water mark. I think the key thing is, not all teams are great at this in any organization, is your SLAs or your quality attributes. What do you need to design that application to do? Because that's pretty important when it comes to also your design, the cost. For example, if you have a website, does that page have to render it in half a second or is actually 30 seconds okay? Because the answer to that question will change your architecture. That architecture is what is the cost. And also how easy is it to scale it up and down?
Seb Leal Bennett (28:05):
And if you aren't asking those questions, you're not being curious, when you're having those conversations with the business, you're either going to overscale your application or under. And so you've got to have that conversation to make sure you hit the nail on the head and then work from there. But do just get those SLAs and the quality attributes for your business. They know what they want to do with it, but you can push back as well. But use data, that's key from there. Don't have a subjective conversation, "Well, I think this is actually looking at the data, we can prove this. We think in the current state that we can scale to this. And if we need more, that's advanced to cloud, it should just elastically scale up if you can.
Emily Wearmouth (28:46):
The point you said about does this need to load in half a second or could it take 30 seconds?" My mind immediately went to agentic AI and how that might be changing things. Because if you are building architectures for humans to navigate, we know that our patience, maybe just my patience, is pretty small and we want things to happen very, very quickly. But if that's no longer a human process that's interacting with that architectural journey, it's an agent, you perhaps can accept a greater tolerance for areas where it doesn't. As long as the end product doesn't need to be super fast, if it's not time-bound, the agent might have more tolerance for a slower path and you can make greater allowances for less costly services.
Seb Leal Bennett (29:30):
You could do. And that all comes back to what's the user experience expected for that particular function. Agentic or not, that's going to dictate the architecture. But yeah, that's an interesting point.
Emily Wearmouth (29:41):
Yeah. Yeah. Just that's a free one from me, Seb, you can take that.
Seb Leal Bennett (29:45):
I'll write that
Emily Wearmouth (29:47):
Down. Adding value every day. Brilliant. Well, I'm conscious, but we've stolen a lot of your time and I do know you've got another meeting to go to. So I'm going to say thank you very much, Seb. I've hugely enjoyed this conversation. Hopefully our listeners have as well.
Seb Leal Bennett (30:02):
That's great. Thanks for having me. Really enjoyed it and happy to appear in future ones.
Emily Wearmouth (30:06):
Brilliant. You've been listening to the Security Visionaries podcast, and I've been your host, Emily Wearmouth. If you enjoyed this episode, do please share it, but also make sure to follow us on your favorite podcast platform or YouTube, and then you'll never miss an episode in the future. And we'll catch you next time.