Enterprise Data Governance Becomes the AI Agent Bottleneck

AI Leadership Insight Series. I'm your host, Mike Bizos. Today we're with Tim Bond, who's chief product officer for Adeptia, and we're having a little chat about, well, all this amazing stuff that was supposed to be happening around agentic AI seems to be running into the same roadblock over and over again.

I think it has something to do with data and the way we govern it or the way we haven't been governing it. Tim, welcome to the show. Mike, thanks for having me on.

Happy to be here. You talk to a lot of customers and I hear the same things over and over again. Everybody's really excited about the potential of AI agents in the enterprise, but we're running into the same kind of hurdles over and over again.

And a lot of it has to do with, well, the AI agents and the data they are accessing. The quality of that data, shall we say, may be suspect, and the rules for how it is accessed are even, shall we say, not especially rigid and, well, AI agents, not surprisingly, are exposing all these weaknesses. So what are you seeing and what are we going to do to fix this issue?

Yeah. Certainly, people have a lot of expectation for what they're going to get out of these AI agents that they think they ought to be able to build with some ease. But I think companies that are blessed to have a more modern technology stack and be very cloud first are having an easier time.

However, the companies that are dealing with some more of the legacy technology, the very first thing people are running into a challenge is just simply how do I get an agent to connect and understand the capabilities that my ERP system has or my CRM system has, just so they can simply connect and start to communicate and maybe at first just read some data and understand it. But then more importantly, where the value comes in is actually being able to write and do operations in that. So that's one of the biggest initial hurdles.

There's a new-ish technology, probably emerged about a year ago, called Model Context Protocol, MCP, which is the way that the agent wants to connect to your system. And if your application has that, that's great. But if it doesn't, then you're up against it, and back to the drawing board a bit.

So to your point, do I need to drop an MCP server in front of everything now? Is that the next logical conclusion from all of that? Some of the vendors of systems are establishing MCP servers.

Your legacy mainframe is, well, it doesn't even have an API right now, so it sure as heck isn't going to get an MCP server. So there's absolutely-- I think you're going to see companies introducing a new layer in their technology stack, which is, you might call it like a data product, essentially. If you think about companies for the last 10 years or so have been using data warehouses and data lakes to aggregate information and make it available, primarily for analytics purposes.

I see companies now are building what they're calling a data product, which is essentially a bunch of data integrations behind the scenes connecting into these systems that may or may not have the authentication that you would want for your agents, or may or may not just have an API surface that's easily connectable to, but a way to bring all of your internal systems together, and normalize that data to an extent, and then make that data accessible. So it's really like a data warehouse is for analytics. We're seeing these data platforms, data products come to be for the data operations, if you will, and actually writing back to systems and making the agents capable of doing things that employees are doing today.

One of the things you also hear from folks is AI agents may rapidly be turning into too much of a good thing. And the issue is, well, each vendor who provides a platform, whether it's SAP or Salesforce or whatever, is making available AI agents. But businesses also want to create AI agents that are assigned a function or a task, whether it's some element of an order-to-cash process or whatever that touches multiple back-end systems.

So how do you think this is going to play out at the end of the day? Are the AI agents the customers bill going to talk to the AI agents that the vendors provide, or will they supersede the ones that the vendors provide? And how does this whole kind of, from the outside at least, looks like a potentially chaotic workflow going to play out?

Yeah. Certainly, you think about Salesforce right there. They've come out with their own agent and it's on top of their MCP server.

And like you said, every major cloud vendor is going to have their own version of an agent. And that might be helpful if you're trying to work just within that system. But as soon as you get to a situation where you need to do a multi-step workflow, I need to log into one system and get a list of all my available part numbers, and then I need to go to another system and I want to create an order.

And you're jumping between systems. That's where I think that the companies will build agents that have access to either directly to the system through the MCP server or through this data platform data product, which has the integrations behind the scenes to do that, we'll say cross-application, cross-functional job and not have to go through SAP's agent, Salesforce's agent. That'll turn into an unnecessary step in a multi-system process.

The other thing that you hear people struggling with is cost, and a lot of them are trying to figure out, well, how do I optimize the consumption of tokens using these AI agents? Because there's going to be a lot of them. And I think a lot of that has to do with this notion of context engineering and what exactly do I need to expose to those AI agents when and where, and there's an art to that.

So are people wrapping their heads around that? Yeah. Certainly, tokens are on every CFO's radar at this point, for any company more than dipping their toes in AI.

And what we're seeing, even just internally out of Adeptia, what we're seeing is we're trying to use AI more intelligently where we want it to actually help us make decisions. But once we've got the framework, if you will, of how we want to operate, we like to operate more as code. So in cases like let's just say as an example, your agent wanted to initiate a refund for some order that was placed.

You could have an agent have access to maybe 10 different tools available to it, and if it knew how to call all those tools in the right order and have the right outcome, that order would successfully be refunded. What you could also do is you could build a more traditional workflow of, hey, I need you to go into this system and do this task, then this system and this task, but have that be operated as code in production so that the agent just triggers one thing, and behind the scenes, you're handling all of the rights to the system, all the updates, et cetera. And then you're reporting back to the agent that, hey, we just ran that code.

You told us to run the code because that was your job to initiate the refund. But we have a deterministic code behind the scenes that's running, so it didn't really cost us anything to run it, but the agent made the decision to trigger that workflow. So use the agent for decision making.

But if you want a really solid process, and again, that goes into governance as well, you can have code behind the scenes that executes that on behalf of the agent. Do you think that that approach also will prevent people from maybe getting locked into a particular LLM? Because, to your point about cost, sometimes I might want to use one LLM versus another, and I think ultimately, the AI agents are going to want to dynamically route prompts to different LLMs based on how much does it cost and maybe which one of these LLMs is better at a particular task.

Yeah. One thing that, just as a side note, I think interesting about LLM models is that they are not sticky by any means. Like today, everyone thinks maybe Anthropic has the best models available, but tomorrow that might be a different model that comes to take over.

And it's quite easy, actually, to swap out and use different models. Whereas you think about other software that a company has, it's a pain to go and rip out a system of record, but it's very easy to actually swap models. So I think we'll see cost be a driving factor for companies as they're deciding which models they ought to be using.

But also just keep in mind that, I guess design it in a way where you have the flexibility to swap in a different API key for a different LLM model and have it keep going, certainly. There are very few companies in my experience that would really get a Good Housekeeping Seal of Approval for the way they manage their data. So is this rise of agentic AI finally forcing them to confront that issue and there's just a need to go back and deal with some fundamentals that, frankly, we just skipped for many, many years when it was only end users accessing data because maybe they could deal with the context.

But AI agents, they take things as they find it, for better or worse. So do we need to go in and clean everything up now? Yeah, I think there's a couple pieces to it.

Data quality is certainly very important. Like you alluded to, if I look at a report and I can maybe identify like, oh, that doesn't seem quite right, let me go dig into the details before I go and announce something or reply to an email or whatever I might be doing. An agent's going to take the data at face value, so the quality of that data is of utmost importance, and that's data warehouses tried to do that from an analytics perspective.

But when you're talking about real-time operations, if you don't have clean data, it's going to be a problem. One, you can certainly work to clean that data up, but oftentimes the data is what it is. The second piece to it is make sure that a lot of times an agent is acting on behalf of a user, and in that case, it can take on the role of that person.

And my agent can see the information that I'm able to see and take the actions that I'm able to take within a particular system, and that's all good and well, but at some point, agents are going to be their own level of a user, and you're going to need to handle authentication differently there. But bottom line is you're going to need a way to control which capabilities or tools you would call in an MCP server that a given agent has access to and have very fine-grained controls over that. So it's not able to call and retrieve information, or maybe even worse, modify data that it shouldn't be able to.

So have that agent-to-tool security aspect of it pretty well defined. To your point about that, I think a lot of people are assuming that the permissions that I have as an end user, I'm just passing those over to the AI agent and everything will be fine. But as you said, do we need to come up with these more granular sets of controls for AI agents because, well, they will do things, to be honest, they don't really have a conscience.

So they will do things that end users would never dream of doing just because, well, they can. Yeah. And right now, again, the most common scenario that we see right now as an agent is a user, but a true agent, not acting on behalf of Mike or myself, is something that can change its behavior dynamically.

And in those cases, this isn't actually even a fully solved problem in my mind, but when you have agents that can change their shape, or change their behavior dynamically, that means that your security and identification of these has to be something that's on demand. So things like workload, and agent identities or managed identities, you're going to have much shorter-lived credentials. People are going to have more of their policies written as code to try to be as flexible as possible, because you're going to need to be able to answer, if I have an agent and another company has an agent, and those agents start talking to together, it's going to get very complicated.

You will have to be able to answer the question, do I trust this agent acting on behalf of this organization requesting to do this action or requesting to get this information right now? And so you'll need to have, again, policy as code, managed identities, workload identities, short-lived credentials to handle all that. So there's a big security aspect to everything when these agents start talking to each other.

So what is your best advice to folks about how to get ready for all of this in a meaningful way? " Yeah. I would say, well, always my recommendation is if you haven't started with something, definitely try something small first to get a feel for what it's like to build an agent and what success and failure looks like.

If you haven't started anything, I would say go speak with your business stakeholders and ask them something that they do that's very repetitive, that feels like something that they could have an agent help them out and do, and go build a one-off for that. And you're going to learn a heck of a lot about how we're going to connect, how we're going to handle the security, what context the agent's going to need about the data and the systems that it's going to connect to. And that's a good proof of concept.

When you're ready to go at more of a company-wide or enterprise-wide scale, I would start to think about a data product and what that would mean as far as exposing all of the technology that you have, all your systems of record, turn those into systems of action by making them accessible through some type of data integration platform, data product that is making, then the agent can call into that. And what that does is the data product itself, not only will it expose your underlying systems in a clean way, but it will also handle all of the complexities around asynchronous messaging and workflow orchestration. You can't just expect that your core systems are able to handle a load that an agent's going to put on it.

So there's a lot of just infrastructure, asynchronous jobs. What happens if in the middle of a workflow, something fails? You need to have that kind of reliability there.

So a data product, data platform is something that you should be thinking about adding into your tech stack. All right, folks. Well, you heard it here.

There is really no substitute for trial and error and a little hands-on experience, but just be careful because if you promise people that all this is magically going to happen overnight, you may have a leg on your face soon. Hey, Tim, thanks for being on the show. Thanks so much, Mike.

AI Leadership Insight series. You can find this episode and others on our website. By all means, check them all out.

Until then, we'll see you next time.