What’s in this podcast?
Agentic AI is moving beyond experimentation. Organisations are beginning to explore how autonomous agents can automate decisions, orchestrate complex processes and unlock new levels of productivity. But how do you build these systems in a way that is scalable, secure and trustworthy?
In this episode of Hub & Spoken, Jason Foster, CEO & Founder of Cynozure, is joined by Matt Clarke, Director of Architecture at Cynozure, to explore what it really takes to design and govern agentic AI architectures in enterprise environments.
They discuss how agentic systems differ from traditional software, the growing importance of governance-by-design, and why trust, observability and control are becoming critical architectural principles. Matt shares practical examples of how agents are already being used to automate decision-making, personalise experiences and streamline operations, while highlighting the challenges organisations face as they move from proof of concept to production.
The conversation also explores how governance can accelerate rather than hinder innovation, why every organisation needs an effective “off switch” for AI systems, and why flexibility may be the most important design principle as agentic AI continues to evolve.
The following interview transcription has been edited for length and clarity.
Introduction
Jason Foster
Hi, everyone. Welcome back to the show. Super excited to have you all here with me and also my guest today, excellent chap called Matt Clarke. He’s our Director of Architecture at Cynozure. He’s been with the company for a long time, recently took on that role. And he’s been working at the leading edge of modern data, analytics and AI systems design and build for a long time. And I’m super excited to have him here. And we’re talking about how to build and govern an agentic AI architecture, which is one of the things that lots of our clients are grappling with and lots of organisations are grappling with in terms of how do you really turn the idea of AI and agents into a genuine system that works and is integrated into your organisation.
So, Matt, I’m absolutely delighted to have you on the show. First time as a guest on the show, so welcome along.
Matthew Clarke
Brilliant. Thank you so much for having me. I’m very excited to be here.
Jason Foster
It would be great to introduce you to everybody a little bit better than I’ve done, a bit about who you are and your background and where you’ve spent most of your time actually.
Matthew Clarke
Yes, so I’ve been associated with Cynozure for seven or eight years now. I started as an associate and am now, obviously, Director of Architecture. I work across all forms of architecture. So I do data, I do cyber security, I do infrastructure. As you said, more recently, I’ve been doing a lot of AI architecture, both the model and the kind of platform that sits around it. I guess my background prior to Cynozure was very heavily rooted in data science. I worked a lot in human rights, some defence-related work, doing open source intelligence analysis for a charity. But my bread and butter has always been data science and the practical elements of data: how companies can use it and build it.
I’ve worked across many large companies, many small companies, charities, to help them on their journey to really see value from data and machine learning and software more generally.
Jason Foster
What’s really interesting, and you say sort of architecture in the broadest sense, and often I see architects sort of sitting in a, you know, almost a camp, an enterprise architect or a solution architect or a, you know, data architect or a cyber architect, but actually you’ve got quite good experience and breadth across those different lenses, which I think is quite unusual.
Matthew Clarke
Yeah, I guess I see it as: I solve problems, and I happen to use technology, data, AI to solve those problems. But at my core, if you give me a problem, I get wrapped up in it, absorb it, research it, and come back with an answer. And I think that’s true for most architects, but obviously people develop a specific domain typically. I just had the fortunate position, I guess, of working across a variety of clients, a variety of customers, a variety of companies. That has given me that breadth. One call might be a cyber security review and then roll off it onto another call to have an enterprise data architecture conversation.
And mixing between them has always been kind of something I found quite interesting because different problems within a similar space.
What is agentic AI?
Jason Foster
Nice. Yeah, well, I like that view and obviously a man of many talents, but let’s bring it to this conversation about agentic AI and I think we are really talking about the sharp end here of what is currently happening and we’re recording this June 2026. What’s currently happening is that people are really trying lots of experimentation with this, you know, proofs of concept, minimum viable products, people trying to work out where they can apply agentic AI. Sometimes that’s a little bit more like just what can we do with an LLM and sometimes that’s more sophisticated.
I see many organisations trying to kind of move from this or certainly have the aspiration to move from experimentation and trying things out to genuine, you know, impactful transformation. And building a single agent to do a thing is one thing, but building a scaled architecture that can support dozens, if not hundreds of agents, that is secure, that is done in a responsible way, that creates genuine value, that is something else entirely.
So what I’m really keen for us to talk about is sort of how we pull that apart and in thinking through this state we want to try and get to, or that some organisations are trying to get to at least, there are a number of tensions that I think emerge when thinking about designing and governing these agentic AI systems. Your experience on the front line of thinking through these problems and doing it, you know, genuinely doing it and implementing this stuff in organisations, I think it’s going to be a fascinating conversation. But we should probably kick off with sort of defining what we mean a little bit about agentic AI and how it compares with traditional software or traditional application development because there are some unique things there.
Can you frame that up for us first? What do we actually mean by this?
Matthew Clarke
Of course. We’ve got obviously software development and database development as two separate disciplines. Sitting alongside that is the development of what we call machine learning algorithms, where effectively we’re feeding in a set of inputs and data and the model and the algorithm is figuring out what weight to apply to different parts of the input to give us an output. Traditionally, twenty years ago, it was feeding a picture of a number and it tells you what the number is, or the picture of a dog, and it tells you it’s a dog.
Over the last twenty years or so, that’s developed into machine learning in the broader sense I just described, but also LLMs, which are incredibly large models, huge, billions, trillions of parameters, where you give it an input, some text, you ask a question, it draws upon all of its knowledge and it comes back with an answer. I know the big breakthrough that most people are aware of, you know, ChatGPT kind of coming to the market with ChatGPT-3 in whenever it was, 2021 or 2022. Since then, we’ve seen a dramatic increase in the use of AI, and particularly of agents. So an agent in the broadest sense is that interface that you’re talking to.
But due to various limitations, it can only access some information and work on one single thread at a time, and so we’ve now moved into this agentic world where the orchestrator might be a ChatGPT interface or another custom-built bespoke component. It spins up versions of itself to go off and do specific subtasks. And those versions may spin up subtasks of their own. For example, if you go now to ChatGPT and you ask a question, it may spin up three or four agents that will go and get information from the internet, from an MCP server that’s connected to a database, or from somewhere else, and reason over that information.
And those agents will return a result, which will be part of the input to the overall orchestrator, which then comes back with a full answer. So when we’re in this space, what we’re really trying to do is both build out better machine learning models, in that broadest sense, but also figure out ways in which we can optimise the input of data to the model, and spin up new interfaces for it to enable us to process more information at the same time. So that’s really where AI is at the moment. And I think when we talk about agents, we’re really talking about the sub-processes and the orchestration that sits above them, as well as the kind of recurring, repeating loop of being able to give an input and get an output without a chat interface.
How agentic AI is being used today
Jason Foster
Got it. And if we just think about that through the lens of how that manifests itself in the real world, so you’ve explained how ChatGPT works, but what are some of the applications of agents that you’ve seen or that we’re likely to see in real-world, everyday interactions either in businesses or in personal lives of people.
Matthew Clarke
One I saw about a year ago, which is a very small example, but quite interesting, is a camera as you drive into a car park, reading the registration plate and converting the picture into an actual registration number that then it can go off and search the database to return information. So that is one agent turning the picture into a string, into a set of characters, which is the number plate, and then another agent taking that as an input to go off and find, you know, search the context and the knowledge graph that you may hold: does this car have the right to park here? How long has it been here? All of that kind of information and returning it to the automated system to process payment for someone parking in a car park.
And you can take that concept, quite a simple input to return some value and apply it to everything. I’ve seen companies that are using an agentic loop so that whenever someone submits a pull request in a DevOps environment, they’re making a code change, they’re pushing the change to GitHub. An agent is watching that, doing a code review and reviewing the code and saying, ‘Yes, this has passed the various tests. It is up to the standard we expect,’ or, ‘It has a vulnerability here.’ It passes that over to a person to review and move it forward in the code review process or passes it back to the developer so they can carry on with it. I think over the next maybe five years, we’re going to see more and more of this.
We’ll see more of the decision-maker taking in that input, making a decision on the information and passing out an output. For example, as you walk into a supermarket, can you scan the people walking in and see if they’re already a loyal customer? As you submit some work you might have done to your boss, you know, send off the e-mail and an agent could check it to make sure that you haven’t put any confidential information in there before it is sent. Those kinds of things being built in to remove mistakes that can happen or add value, where there’s quite a simple input and then quite a simple output expected from that.
But where traditional software engineering would have to come up with a vast array of if-this-then-that statements, which wouldn’t really work. That would be very hard to architect and figure out upfront, and very costly to develop. Agents can step into that gap and, in a few days, build something that works almost every time and creates value for the business.
Jason Foster
What’s really interesting about all those ideas is this point about, you know, there’s some automation in there, but there’s also some smarts in there that’s making a decision about what to do based on information. And you can imagine, and you’ve seen, you know, that rolled up across multiple processes, across complex and simple processes that would typically require manual intervention, where humans need to do something or administration needs to happen, and remove it by bringing and stringing these agents together to take on some of that activity. So I can see how that rolls up to being quite impactful when you think about how an organisation is set up and the work they do and the change that could bring about.
Matthew Clarke
Absolutely. And I think if you take another example, if you’ve got all of your policies for your employees or your finance system or whatever it is, Traditionally, you would have a search function where you could ask how much time you get off and receive quite a generic answer. What we’re seeing now is that a group of agents is able to pull in vast amounts of information. They can then provide personalised results. So: ‘John Smith, you have twelve days of holiday left,’ rather than, ‘The company policy is thirty days; go away and work out how much holiday you have left.’ We’re seeing that personalisation built into more and more external products, but also the internal products that enterprises are building.
So whether it’s the HR interface, whether it’s the expenses system, whether it’s product insights, where I’ve built a product and my software engineer needs to know what’s gone wrong and where. All of that involves synthesising a large body of information into quite an accurate single answer that can point the person in the right direction. That’s another use case that isn’t really about the admin side, but opens up a whole world of opportunities for a business team writing a bid or an operations team, making sure the operations are working in the correct way. All of that kind of work can also be done by agents.
Of course, you need the right controls around them to make sure that what they’re building works well and kind of sticks to the standards we would expect. Within that environment, and there are various ways we can get into it, but there are various ways to go about doing that, both for developing and using it. A business can try to create those controls itself, with varying degrees of success, or rely on developing industry best practice. A lot of the work I’ve been involved in over the last few years has been working towards defining for businesses what those best practices should be. So it’s been quite an interesting time.
Balancing autonomy and control
Jason Foster
You touched on control at the end there, but equally, the examples you gave were about how we hand over decision-making authority to a thing, a system, an agent, which needs to act in a relatively autonomous way so it does not constantly, you know, not constantly have to go back to a human all the time, because then actually you’re just adding steps in a process rather than freeing people up. So it strikes me that this is one of the tensions in architecting these solutions: we want to hand over decision making. We want to hand over some autonomy to an agent to do something, take an action, review a thing, share something with somebody, block something, enable something.
But equally, we want some level of control so that things don’t get out of hand, things don’t become unpredictable. So how do we do that? Where’s the line, and how do we architect the solution so that both of those things can be true at the same time?
Matthew Clarke
There are two parts to this, right? There’s everything before the model has been produced as you develop it. It’s a safe, walled-off environment where a developer can work with relative autonomy as they’re building it out. But then there’s also the runtime environment, where we make sure we’ve got the right controls around that. So we’re protecting against the consequences of it making a poor decision rather than restricting every action it can take. I recently built a governance framework for a large company.
That framework effectively divides all use cases into buckets of the consequences of the decisions it can make, the consequences of the actions it can take, the difference between it deciding to do something and it actually being able to do that thing. And then what’s the consequence of it misspeaking? So if it gives a toxic answer, what’s the consequence of that? Where we effectively end up is controlling what the model can access. A model has the data it was trained on, and then it has information that the user or the system injects into the model at runtime. And so we control what that information can be. We’re building what’s called guardrails between the agent receiving an input and the agent responding. We screen the answer.
Maybe the agent responds and then a second agent reviews that response to make sure it does not contain toxic content. Maybe we apply different thresholds to how the model works under the hood to make sure it’s more truthful or more creative. By applying those types of controls and having layers upon layers of controls, we mean that the agent can act with full autonomy. It can do what it needs to do within reason and within the boundaries of the controls in the walled garden we’ve placed it within.
Jason Foster
It’s almost giving it a scope of what it can and can’t do, and defining the consequences.
Matthew Clarke
Yes, a mandate for how it can work. By going through those controls, we can filter and change what the model can respond with or how it responds. So if a prompt goes into a model as some form of input, and then the model returns in a way we don’t want, we can then filter out that content. We can say, no, you shouldn’t have responded with that. Try again. Or perhaps the user has put in a prompt that contains lots of personal information. And we should strip out that information if it shouldn’t be there. We can also control what the model can access in terms of the database. It can read this table or this graph, but it can’t read that information. And therefore we’re changing the input to the model itself.
The controls we put in place are almost a write-once, use-many-times control. We build these layers in, and you can have centralised teams building them in. This is actually what a lot of the work that happens at Anthropic or OpenAI around their products is doing: building controls in. But you’re not limiting what the model can do. Instead of having a human in the loop reviewing the model, you’re writing code: do this, do that, do this, to offset those negative consequences, thereby creating a safe environment for the model to have full autonomy. So you’re balancing the two.
Governance without slowing innovation
Jason Foster
Fascinating. I mean, governance is interesting. So essentially, I think what you’re saying, if I try and play that back, is essentially we build a model to do the thing and we make it autonomous and it can essentially do what it wants. And then we apply some controls and a rule book of what it can actually do off the back of that. And so that stops it from delivering something that it shouldn’t, or taking an action that it shouldn’t, or driving a decision that it shouldn’t, or taking in some inputs that it shouldn’t have access to. I think that’s really clear and it puts that kind of governance around it. Governance, though, is quite a scary thing for many people. It can often feel and be seen as slowing things down.
And I can see in the way you’ve explained it there, actually it helps to enable and not hinder in terms of like the detail of how an agent works. But at the macro level, if we govern the hell out of this stuff, doesn’t it slow us down? And if it does slow us down, how do we get around that? How do we stop ourselves from putting in all these bottlenecks that actually end up meaning we’re, you know, stifling innovation or stifling the work that an agent can really do?
Matthew Clarke
I think we have to be clear on where those governance controls are super important and where we can give a bit more flexibility. If I’m working in a development environment, we want to place very strong governance controls around how that environment works. So what access to data does it have? What access to the outside world does it have? What access to libraries which may contain malicious code does it have? But once that boundary is drawn, we’re placing a silo around each agent or around the development of each agent. Within that kind of lab environment, the development teams have a lot of autonomy because we’ve removed the consequences of it going wrong. And so from a development perspective, we can very quickly make changes.
We can update a model. As long as the access is controlled, we can provide it with the right level of access to the information to make better decisions. So we can test out new ideas, put in the right tools and create that kind of lab environment where we’re very much able to build out the model at pace. The problem, as we’ve recently come across with a client, is how you then move from that lab into that runtime environment where you’ve got the playbook of controls that sits around the model.
Jason Foster
Yes. You suddenly move it into that environment and it can’t do anything that it’s been trained to do because of all of the controls that are in place.
Matthew Clarke
What we’ve done and the approach we’ve taken is we’ve taken away a lot of the ability to change stuff from developers. So we’ve developed automated CI/CD pipelines. We’ve defined the tests that need to be run on every model and the thresholds that need to be reached within those models. We’ve defined how security scanning works. We’ve defined deployment of the platform using infrastructure as code. So the ability of the agent or the model to make wider macro changes is removed. You can therefore build within your lab, within your walled environment, a solution, press build, and the system takes over.
Because you’ve written the system as code, because all the governance controls are code, the governance teams, the cyber teams and the legal teams can review that pipeline once. And it takes a while to build that pipeline, but once you’ve built it, you can then use it every day. So the time between building something and it being put into production is minutes rather than months. And that breaks a barrier to governance being a blocker. Instead, governance becomes about building out those automations. Then developers and agents can use those automations in a really secure way. We’ve got the controls built around it. So when it ends up in that runtime environment, it’s got access to the playbook, it’s got access to the right data.
We’ve already done the security review, so we know that it’s secure. It’s not really a speed-versus-governance question. It’s more of a question of how we have both.
Jason Foster
It’s almost both.
Matthew Clarke
We can have both, but that means we need to invest in the governance frameworks and we need to invest in the governance teams so that they’ve got the skills to build out those automations and to review what’s happening, which raises the technical requirements of the governance team. But it’s a worthwhile investment if you can do it. It’ll pay off in the long run.
Jason Foster
Yeah, I feel there’s a whole separate conversation about what needs to be true to be able to do all the things that we’re talking about on this episode and what skills you need and what appetite you need and what investment you need, all those good things. But I think it’s really interesting that, on this point, the way to handle speed is to build some reusable governance and pipelines that make it more consistent, more auditable, more transparent, not less of any of those things, which is the opposite of the thing that would really slow you down.
Matthew Clarke
Absolutely. What we’re really talking about building is a standardised approach to go from a development environment into a production environment and a standardised approach for being able to interact with that model either from a chat interface or on some sort of loop. Once we build out those standardisations, we remove the trade-off between governance and speed. The difference from traditional software development environments is that an agent will follow the same rules. If you give it twenty-five rules, it will execute all of them. If you give a person that, they may not. And therefore we have to build out the checks to make sure that it has followed those rules, because they’re a person and people don’t always follow every rule.
So what we’re able to take advantage of is the fact that an agent is just code running, and therefore we know how it will execute.
Observability, rollback and the off switch
Matthew Clarke
It’s really about making sure that we’ve also got that observability, so we can trust that the code will run. But then we’re able to look back and say, it did run. And if it didn’t, if something went wrong in our process, we’re able to very quickly roll back. So one of the architecture patterns we’ve developed is the model always sits behind an API. The API allows the chat interface to talk to the model. When a new model is produced and promoted, it goes through that automated process. After it’s been released, we can look back at it and say, ‘It actually failed this check.’ And for whatever reason, the pipeline didn’t run. The expectation and the hope is that would never happen. But then we can just repoint the API to the old version.
It’s a five-minute change. Our ability to roll back is enabling us to move at speed and innovate very, very quickly within the business. If you look at what’s happened with Claude 5 at Anthropic, clearly they’ve got a very similar pattern because the American government has placed export controls upon Claude 5, so it can’t be used outside of America. All they’ve done is turned off the API. If you go into Claude, the model is still there, selectable, but it won’t run if you try and run it. And so by them having those controls, when something unexpected happened outside their governance-as-code framework, they were very quickly able to undo it.
And it’s about both having those automated controls and standards, but also having the mechanisms to undo the change you’ve just made. They can undo the change very easily and at pace.
Jason Foster
Yeah, I think the off switch for agents, I think everyone wants that big red button somewhere. The ability to say, ‘No, no, no, no, you shouldn’t have done that.’ And now please stop for the minute while we just take stock and, you know, course correct in some way.
Matthew Clarke
Absolutely. But that red button is crucial, right? It’s what gives us trust as an organisation. And it means we know that we can experiment, and as long as we’ve placed those controls, as long as those walled gardens are built, the governance code is there. We can trust that if anything unexpected happens, we can just roll back. It’s a button click away. It’s not a two-week process to undo the changes, and during that time, the model is behaving in a way we don’t want.
Making AI decisions auditable
Jason Foster
You also mentioned auditability, the ability to look at what happened and what took place. Is that also at the level of why a decision was taken as opposed to whether it ran or not? For example, it decided to approve the insurance claim or it did not, or it decided to turn left rather than right. Is there something that allows you to understand that and have real clarity about why it took certain decisions?
Matthew Clarke
Absolutely. And it’s quite a crucial part, particularly within regulated industries. So whether it’s government, large industry, big tech, big pharma or finance. That ability to know why it’s made a decision is absolutely crucial. You could have a regulator come along and ask a question. You could have a court of law come along and ask a question. Ultimately, the model is making decisions, but accountability can’t live with the model. Accountability lives with the company. The company therefore needs to be able to answer ‘The model did X because of Y.’. So the pattern that we’ve really developed is this idea of data versioning. Earlier I talked about how the model is really two things.
There’s a model version that’s got a training history attached to it, a set of data inputs when it was trained, and then it’s got the data that’s been introduced to the model. If you turn what’s called the temperature right down on the model, it will always produce the same output if given the same input. If you don’t let it be creative, it will always, given the same input, produce the same output. So if we can understand the data that was introduced, both the prompt or the question, the data that it had access to through a RAG architecture, all of those different factors that went into making that decision, we can reconstruct that decision and reconstruct the reasoning behind that decision after the fact.
There’s a large body of academic research in this area. Within industry, a major question we’re exploring with clients is: can I version what’s in my data lakehouse so we know this is the information that was fed to the model and therefore this is the decision it arrived at. If a regulator says the decision was wrong, we can understand exactly why the decision was wrong and then come back to either make reparations or update the model so that in the future it doesn’t make that same decision. So it’s really that data versioning and the model versioning.
Jason Foster
And it’s able to do that even on non-deterministic solutions. So like an LLM will possibly give you a different result every time you ask it, even if you ask it the same way.
Matthew Clarke
An LLM will give you a different answer based on the temperature setting. Every LLM has a temperature, and it’s a setting that you can set between zero and one, which is effectively how creative the answer should be. In that sense, it’s not really changing the answer. It’s changing the content that it produces. But the underlying answer is still very, very similar. So if you set temperature to 0 and give a model the same input, it will always return the same output. So the non-deterministic element is being introduced by that setting. And therefore, by understanding that setting and how that setting is applied, we’re therefore able to better understand how the model reached that conclusion.
Jason Foster
Okay, interesting.
Matthew Clarke
The difficulty comes with products where you don’t necessarily have that temperature setting. So if you make a request to an OpenAI API, it will have that setting. But if you ask ChatGPT, it won’t. And in that case, it’s very much more about making sure that we’ve built the testing infrastructure around it, so we know that what’s returned is within a threshold we’re happy with. We can’t necessarily create exactly the same answer, but we can still measure the inputs and whether it was within our testing thresholds. We can make sure that we’ve controlled for as much as possible.
The point here is that if you’re in a highly regulated industry, maybe you’re not using those tools, maybe not using ChatGPT, but using the API behind ChatGPT, and those are some of the decisions that architects, governance teams and businesses have to make when they’re coming up with their rule set, depending on the industry they’re operating in.
Building trust in AI systems
Jason Foster
It’s really interesting because that all points to, you know, that observability thing, the ability for those managing, looking after the systems to know what it’s done and be able to unpick it. But equally, there’s also the element of people interacting with and working alongside agents, you know, you’ve got human employees and agent employees. And we need to trust what it’s doing, trust that it’s producing good results, trust that it’s working in a way that we believe is right, trust that it’s a good colleague in the same way we would hopefully trust a human colleague. So, trust is like a big deal, I think. And it’s always been a big deal for any, you know, data or insights work or analytics. Do we trust the data? Do we trust the numbers?
Do we trust the insight we’re being given? I think this takes a whole new level. You also have to choose to trust a real human employee. But the level of expectation on a system is so much higher in some ways. So I suppose the question in there is from an architectural and design-principles point of view, how do we make sure we build that trust in by design so that we give people the confidence that the decisions and actions that are taken are the right ones.
Matthew Clarke
It’s a hard question, and it comes down to the individual organisation’s risk appetite. We can, again, within some of the controls we can place within the model itself, we can determine how creative it is, as I said. We can also determine how much it generates ideas versus uses information. We can set it so that a model is only returning well-referenced answers. One way we go about solving this problem is to make sure that the model is always returning a reference along with the fact. So it says, yeah, profit was up 12%. Let’s provide a reference to that so we can look it up and independently verify that the result is true. Another part is making sure that the people interacting with it are also trained on how to use it.
Let’s not give ChatGPT or Claude or whatever it is to all of our employees and say, go off and have some fun. Let’s put training in, let’s put checks to make sure that they have understood how to use it. We should verify that they’re using it in the right way and that their interaction with it is understood and well documented and they’re clear on what they can and can’t try and use it for. Because, as you say, it’s a system that’s running. It doesn’t have any internal motivation to do stuff except for what we tell it to do.
If we’re controlling how we interact with it and we’re making sure that it’s always referencing where it’s got the information from, we’re then able to build that level of trust that the answer is verifiable and we’ve interacted with it in a responsible way.
Jason Foster
I mentioned the bar being high on systems because we don’t measure individuals’ decisions or, you know, if someone says, oh, we did really well this weekend or last week, we don’t go, oh, what’s the reference for that, please? Or show me the data or anything like that. So the level of transparency about how these things produce the results or decided to take an action, you know, that almost has to be proven. You have to build the trust over time.
And that comes partly from what you have talked about here: the governance, the controls, the reusability, the standardisation across all the things that we do, but equally from education and time, frankly, the time people spend working with these things, understanding what it’s done, seeing the results to build up confidence that it is as good as it needs to be. And in some ways, people are trusting, you know, the answer out of ChatGPT too quickly. So they’re being very trusting. But in other ways, as the horror stories come out about, you know, rogue decisions and silly things being done by these systems, that trust could get eroded.
So, you know, I think there’s an architectural thing you talk about, but there’s also the real human thing and process and cultural thing that we need to build into the way we approach this so that trust builds properly and sustainably over time.
Matthew Clarke
Absolutely. And it’s about trusting that the model is correct, the conclusion it has reached is sound and the information it has given is reliable. But the analogy I always reach for is driverless cars. We can test it, we can verify it, we can know that it drives very well. But it’s going to take a long time for people to fall asleep while it’s driving them. And therefore, it’s natural for us to be skeptical, it’s natural for us to want to test it out in different scenarios, as we test them, we’ll come across edge cases which don’t work. So if something has access to information it shouldn’t and it does something wrong, that’s part of building trust, right? That’s part of understanding where the limitations are.
Within an enterprise, the real challenge here is how you make sure you’ve got those controls that sit around it so you know what it can do. We understand the limitations of it. This is a cutting-edge technology. Many, many people use it and don’t understand how it works, the ways it works, and how the model under the hood is operating. I’ve met very, very experienced engineers who don’t know what temperature is. Those kinds of concepts are still quite new to organisations and quite new to people. And until we’ve got people within positions of authority within the business that really understand how it works, we’re never going to have that trust. Therefore, we have to rely on governance.
We have to rely on observability while trying to educate people within a business on how it works, in the same way that twenty years ago data was largely misunderstood and now it’s quite well understood. It’s a similar process.
Staying flexible as agentic AI evolves
Jason Foster
It’ll take some time to get there. So I guess just bringing all that together, there aren’t that many organisations that have really jumped in properly to agentic AI, I think lots of dabbling, as I said at the start, and trials and hopes and expectations and fears about it, but not that many that have really made a proper step forward. Certainly, that is our experience across large corporates and enterprises. So if you had a piece of advice for an organisation, what would be the kind of headline piece of advice you’d give it when they’re thinking about agentic AI or architecting agentic AI solutions?
Matthew Clarke
I would actually say: stick to quite a flexible solution. Build out the governance controls, be stringent with them, build them out, build out the standardisations, build out the automations, but keep the underlying architecture quite flexible. We’re in the early days of agentic AI. How it looks today will be vastly different to how it looks in five years’ time. And the mistake that I think companies make is becoming wedded to a single view: “This is how it’s going to work.” And they spend five years building something, two years building something, whatever it is, and then end up having made a set of architectural decisions which didn’t necessarily pay off.
So maintain that flexibility and build a platform where it can shift and change over time as new capabilities come to market. We haven’t yet answered the question: are we going to have an artificial general intelligence, some ultra-smart machine that can do everything? Or are we now effectively fine-tuning where we’re going to reach? Those are vast questions that still need to be answered, and until we answer those questions, I’d say organisations need to be relatively flexible in how they work, while also making sure they have the controls to trust the model without necessarily being wedded to one view of how all the architectural decisions should work under the hood. But maintaining that flexibility is crucial.
Jason Foster
Great. Love it. Given the change we’re likely to see, the unknowns and the pace of acceleration, I think that’s a fair piece of advice. So, listen, thank you so much for joining me on the show. It’s been great unpicking this and you are at the leading edge, the sharp end of designing and putting these platforms and solutions in place. So it’s great to talk that through with you and I hope everyone enjoyed it. I’m sure they did.
Matthew Clarke
Brilliant, thank you very much.
Jason Foster
Thanks for coming on the show, and thanks everyone for listening to today’s episode. I hope that struck a chord with you as you’re thinking about agentic AI and how that works and what we need to consider when deploying those solutions. I hope you enjoyed it and catch you again sometime.
