Data Fabrics for AI Agents and MCP: The Foundation Most Organizations Are Overlooking

There’s no shortage of momentum around AI agents right now. They’re moving quickly from proof-of-concept into production, taking on real responsibilities such as resolving service issues, generating insights, and even initiating actions across enterprise systems. At the same time, the Model Context Protocol (MCP) has emerged as one of several approaches – alongside agent-to-agent protocols like A2A and direct CLI and API integration – to standardize how these agents connect to and interact with data. But standardizing the connection is not the same as standardizing the context, and that distinction is where most enterprises will succeed or fail.

On the surface, it looks like the hard part is being solved.

It isn’t.

Because underneath the progress is a more fundamental issue. Most enterprise data environments were never designed for autonomous systems that rely on context to make decisions. And the failure mode isn’t obvious. Agents don’t crash when something is wrong. They produce answers that are coherent, confident, and occasionally incorrect.

That’s not a model problem. It’s a data problem.

From Visibility to Decision-Making

For the better part of the last decade, data architectures have been optimized for analytics. The goal was visibility, getting the right numbers into dashboards so humans could interpret them and decide what to do next.

AI agents change that model. They don’t just present information. They interpret it and act on it. That subtle shift, from informing decisions to making or influencing them, puts entirely different pressure on the data fabric.

When humans consume data, they instinctively question inconsistencies. They recognize when something feels off. Agents don’t. If the data appears structured and complete, they proceed. That makes consistency, quality, and context far more important than they were in traditional analytics environments.

The Myth of the Single Fabric

There’s a recurring idea in enterprise data strategy that everything should be unified into a single, centralized data fabric. It’s an appealing concept, but it rarely survives contact with reality.

Most organizations already operate across multiple data ecosystems. SaaS platforms, cloud warehouses, and operational systems each maintain their own data layers, often optimized for specific use cases. Trying to consolidate all of that into a single fabric tends to introduce latency, increase complexity, and slow down delivery.

A more pragmatic approach is to accept that multiple fabrics already exist and focus instead on how they connect. The goal is not full centralization. It is coherence. That typically means adopting a federated model, where systems retain ownership of their data while shared layers provide consistency in definitions, identity, and lineage.

It is also worth being honest about where these fabrics already live. Modern SaaS platforms such as Salesforce and ServiceNow have embedded data fabric capabilities of their own, and resisting that reality tends to be costly and slow. So when organizations ask whether they need one fabric or many, the honest answer is usually both: a connective layer that provides shared identity, definitions, and lineage across the embedded fabrics that already exist.

This distinction matters because the real risk for AI agents is not distributed systems. It is fragmented context. When agents assemble information from multiple sources that are not aligned, the result is not necessarily failure. It is plausible but incorrect outcomes.

MCP can help standardize how agents retrieve data, but it does not solve inconsistency underneath. That still comes down to how the data fabric is designed and governed.

Zero-ETL and the Illusion of Simplicity

Zero-ETL has become one of the more compelling narratives in modern data architecture. The promise is straightforward. Eliminate complex pipelines, reduce latency, and make data available in near real time.

Those benefits are real. But they come with an assumption that often goes unexamined. The data being accessed is assumed to be fit for purpose.

Traditional ETL or ELT processes made transformation visible. Data was cleaned, normalized, aligned, and enriched before it was consumed. In a zero-ETL model, that responsibility does not disappear. It shifts. And when it shifts without corresponding controls, it introduces risk.

For AI agents, that risk is amplified. Agents do not evaluate whether data is semantically consistent or aligned with business definitions. They operate on what they are given. If that input is flawed, the output will be too, just in ways that are harder to detect.

The practical takeaway is that zero-ETL should be treated as an integration pattern, not a quality strategy. Organizations still need strong observability, including continuous profiling, anomaly detection, and monitoring for schema drift, if they want to trust the data flowing through these systems.

Speed without validation is simply a faster path to the wrong answer.

Governance Has to Operate in Real Time

Governance has traditionally been applied after the fact, documenting lineage, defining access policies, and ensuring compliance for reporting use cases. That model does not hold up when decisions are being made dynamically by AI agents.

What is required instead is governance that operates at runtime.

This starts with more granular access control. It is no longer sufficient to determine whether an agent can access a dataset. The question is whether it can access specific attributes, under specific conditions, for specific actions.

Lineage also needs to evolve. Static documentation does not provide much value when trying to understand why an agent made a particular decision. What is needed is real-time traceability, an ability to track exactly which data was used, in what form, and how it was transformed.

Just as important, data needs to carry context with it. Information about sensitivity, freshness, and reliability should be embedded directly alongside the data itself. Agents do not just need access. They need signals about how much they can trust what they are using.

Framed this way, governance becomes less about restriction and more about enabling safe automation.

The Quiet Risk of Data Quality

Data quality has always been a concern, but AI changes the nature of the risk. In traditional systems, bad data often led to visible issues such as broken reports or obvious discrepancies.

AI agents behave differently. When data is incomplete or inconsistent, they still produce outputs. Those outputs are often well-formed and believable, even when they are blatantly wrong.

That makes quality issues harder to detect and more likely to propagate.

Addressing this requires a shift from periodic validation to continuous assessment. Data needs to be profiled in real time, with quality measured dynamically rather than assumed. More importantly, systems need to expose confidence alongside results. Not every answer should be treated equally, and agents should be able to signal when uncertainty is high.  And when confidence is low, that should trigger human review, not autonomous action.

Equally critical is the role of semantics. Agents do not reason effectively over raw schemas or loosely defined fields. They rely on consistent definitions and clear relationships between data elements. Without that layer of meaning, even high-quality data can be misinterpreted.

In that sense, the semantic layer is not just a convenience. It is what allows agents to operate with reliability.

Unstructured Data Is No Longer Optional

If structured data defined the first generation of enterprise data platforms, unstructured data is defining the next. Organizations increasingly expect AI agents to work with documents, conversations, images, and other forms of content that do not fit neatly into tables.

This is where many data fabrics begin to show their limitations.

Supporting these use cases requires more than just ingestion. Unstructured data needs to be processed, segmented, and embedded in ways that make it retrievable and usable. It also needs to be governed, subject to the same controls around access, lineage, and lifecycle as structured data.

Context becomes particularly important here. Many AI systems rely on retrieval-augmented generation, where outputs are based on retrieved content. If that content is outdated, incomplete, or poorly sourced, the resulting outputs will reflect those issues.

And unlike structured data, where inconsistencies are often easier to detect, problems in unstructured data tend to surface more subtly. Outdated information can appear authoritative, making it more likely to be trusted by both agents and users.

Where Things Actually Break

It is useful to make this concrete.

Consider a relatively simple use case. An AI agent handles customer billing inquiries. To do its job, it needs to pull information from a CRM system, a billing platform, and a set of policy documents.

Individually, each of those systems may be accurate. But if they are not aligned, if the CRM reflects a recent upgrade that the billing system has not processed, or if the policy document is outdated, the agent will still produce an answer.

Nothing fails in a technical sense. The system works exactly as designed.

But the outcome is wrong.

That is the core challenge with AI agents. Failures are rarely the result of broken systems. They are the result of misaligned context.  Most of what determines whether an agent succeeds sits below the waterline – in the alignment, identity, and quality of the data it draws on – not in the visible system that appears to be working exactly as designed.

The Bottom Line

There is a tendency to focus on the most visible aspects of AI, including models, interfaces, and capabilities. Those elements matter, but they are not what will determine success at scale.

The limiting factor is more familiar and less exciting. It is the state of the underlying data.

Organizations that get this right will not necessarily have the most advanced architectures. They will have done the foundational work, establishing clear definitions, maintaining trustworthy lineage, measuring quality continuously, and embedding governance into the fabric itself.

Because in the end, AI agents do not create insight. They reflect the data they are given.

And whether that reflection is useful or misleading depends entirely on the strength of the data fabric supporting them.