Agentic AI is here: how to get your database ready

Summary:

• Rather than exploring the capabilities of LLMs, businesses are now focused on how AI can connect to their operational systems
• Databases now support autonomous software as well as humans and predictable applications, representing a shift in data demand
• The increasing centralisation of AI models is transforming the questions at the centre of database design and modern architecture planning
• Instead of building custom integration for every AI application, many organisations are using the model context protocol (MCP) to dramatically reduce complexity and ease development 
• Auditing readiness should focus on core data management principles and building governance, access control and auditing into the fabric of the architecture

Over the past year, I’ve noticed a fundamental shift in the conversations I have with software architects, developers and IT leaders. A year ago, almost every discussion about artificial intelligence revolved entirely around large language models. The questions were predictable and focused heavily on capability: which model performs best on benchmarks? How accurate is it for specific tasks? Which provider should we choose for our upcoming project?

Today, the questions landing on my desk are entirely different. While organisations still care about the underlying models, they are increasingly preoccupied with a much more practical challenge: how those models connect to the operational systems that run their business. They want to know how an AI agent can retrieve live, dynamic information, interact safely with enterprise applications and make decisions using trusted internal data rather than static training material. In other words, the conversation has moved rapidly from ‘which model?’ to ‘how does it work in the real world?’ From my perspective, that’s precisely where the truly interesting architectural challenges begin.

AI agents behave differently

To understand why this shift is happening, we have to look at how our data infrastructure was built. Most enterprise databases were designed to support traditional applications with highly predictable behaviour. These applications issue specific requests, receive structured responses and complete well-defined transactions. Even analytical workloads, while heavier, generally follow well-understood queries and patterns.

AI agents don’t behave this way at all. An agent might retrieve a piece of information, evaluate it against a goal, ask a follow-up question based on that evaluation, compare the two answers, call an external business tool, and then return to the database several more times before finally deciding what to do next. This iterative looping isn’t a flaw in the system; it is simply how computational reasoning systems operate. The consequence for IT leaders is significant: databases are no longer supporting only human users and predictable applications. They are increasingly supporting autonomous software capable of making its own independent decisions about what information it needs next. This represents a profound shift in data demand.

The database is becoming part of the AI conversation

One lesson I’ve learned throughout my career in technology is that infrastructure rarely attracts attention until a new type of workload exposes assumptions we didn’t know we were making. We have seen this cycle play out multiple times over the last few decades.

Virtualisation changed how we designed storage networks, the cloud completely transformed how we thought about systemic resilience, and containers forced us to reinvent our entire approach to software deployment.

I believe agentic AI is beginning to do something very similar for enterprise data platforms. For years, the industry focus has been on making databases faster, more resilient and easier to operate at scale. While those fundamental objectives remain critically important, AI introduces additional, complex considerations into the mix. Architects must now ask themselves: can the database provide enough rich context for an agent to make sensible, autonomous decisions? Can multiple independent agents safely access and lock information at the same time without causing deadlocks? Perhaps most crucially, can we audit the data path to understand why an agent performed a particular action? These questions rarely arose in database design discussions a few years ago, but increasingly, they are becoming central to modern architecture planning.

Connectivity matters more than ever

When it comes to implementation, one of the biggest practical hurdles isn’t the sophisticated model itself, but the messy reality of connecting that model to legacy enterprise systems. To solve this, many organisations are currently experimenting with the model context protocol (MCP), an emerging open standard that gives AI agents a consistent, secure way to discover available tools and access underlying data.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

The technical protocol itself isn’t the most interesting part of this trend; what’s fascinating is what it enables. Instead of building a bespoke, custom integration for every single AI application or use case, organisations can begin exposing their data capabilities in a unified, standard way. This dramatically reduces architectural complexity and makes it significantly easier to develop advanced systems that combine multiple disparate data sources and business services.

Whether MCP ultimately becomes the dominant industry standard is less important than the broader direction of travel it represents. Enterprise AI fundamentally needs standard, secure and highly observable ways to interact with operational data systems.

Performance is only part of the story

When people think about databases, performance is usually the first topic that comes to mind, and it certainly matters here. If an agent performs dozens of micro-interactions with a data layer while completing a single human task, latency issues will compound quickly. However, I suspect that data governance will ultimately become equally, if not more, important than raw speed.

As AI agents gain more autonomy to act on behalf of the business, organisations will need absolute confidence that they can answer straightforward operational questions. If a system fails or behaves unexpectedly, leaders will demand to know why an agent made that specific recommendation. What exact information influenced its final decision? Which data or systems did it access? Could the same decision be reliably reproduced tomorrow given the same data state? These aren’t really AI questions; they are timeless questions about operational trust, compliance and enterprise accountability.

So how do you prepare?

The good news is that I don't believe organisations need to panic and replace perfectly good, stable databases just because they are experimenting with agentic AI. Most of the preparation work is likely to involve asking different questions of your existing setup rather than buying entirely different technology.

As you audit your readiness, focus the conversation on core data management principles: can our current data platform expose trusted information securely to non-human actors? Do we have visibility to understand exactly what data our AI systems are accessing in real time? Can we observe and log the complex interactions between autonomous agents and enterprise systems? And finally, are governance, access control and auditing built into the fabric of the architecture from the very beginning, rather than treated as an afterthought to be added later? These are conversations worth having right now, well before these AI workloads become business critical.

Looking ahead

Technology rarely changes as abruptly or dramatically as tomorrow's headlines suggest. In my experience, lasting change usually happens much more quietly. Architectures gradually evolve, operational practices improve, new standards emerge, and eventually, those hard-fought changes simply become the new normal.

We are at the very beginning of that normalisation process with agentic AI. The initial wave of excitement around large language models naturally focused public attention on what the models themselves could do. Over the next few years, I believe we will spend just as much time thinking about the unglamorous infrastructure that allows those models to work. For database professionals, this shift isn't something to worry about. It is a remarkable opportunity to rethink how one of the most important parts of enterprise IT continues to evolve.