When a human encounters a data swamp, the consequence is a delayed report. When an autonomous AI agent encounters one, the consequence is an automated business failure — executed at scale.
55% of enterprise data is never used (Gartner, 2024). Not looked at. Not analysed. Not trusted enough to build a single report on. And this number has not improved in five years — despite billions spent on cloud platforms, data lakes, and tools that promised to fix exactly this.
Historically, this was an expensive nuisance. A human analyst would open a ticket, wait three weeks, notice a discrepancy, and manually fix it in a spreadsheet. Humans adapt. We compensate for messy centralised data architectures using tribal knowledge, emails, and guesswork.
But we are no longer just building dashboards for humans. We are entering the era of Agentic AI — autonomous AI agents designed to perceive, plan, and execute business actions independently. And this is where the old model hits a brick wall.
I have spent close to a decade helping enterprises build data infrastructure. I have seen organisations invest in world-class platforms. I have sat in rooms with impressive architecture diagrams on the screen — modern, cloud-based, well-designed. And I have watched, again and again, as those same platforms quietly stopped delivering. The data team was buried in requests. Business teams were still working off old spreadsheets. And the newly deployed AI agents sat completely paralyzed — unable to safely automate a single workflow because the data underneath them could not be trusted.
The platform was not the problem. The way it was run was.
of enterprise data is never analysed or used (Gartner, 2024)
of enterprise data considered completely unused or underused (Splunk, 2023)
of government data stored but never applied to decisions (Forrester, 2023)
How We Got Here
To understand why modern AI is breaking on legacy infrastructure, it helps to trace how enterprise data management has evolved.
It started with data warehouses in the 1980s and 1990s. Bill Inmon — widely known as the father of the data warehouse — had a clear idea: collect data from all your systems, clean it up, bring it together in one place, and use it to make decisions. For a long time, this worked.
But companies kept growing. And so did their data. The warehouse handled clean, organised information well. It struggled with everything else — website logs, emails, social media posts, sensor readings, documents. This newer type of data did not fit neatly inside it.
So the data lake was born. The idea was simple: store everything in one place — organised or not — and figure it out later. No strict rules upfront. Just pour everything in. It sounded like the perfect solution for both big data and machine learning.
In practice, it created a structural bottleneck nobody expected.
It was Zhamak Dehghani — a software engineer and architect at ThoughtWorks — who first put a name to why this kept failing. In a 2019 article that became a foundational text in the data industry, she argued that the problem was never the technology. It was the model. Centralising data, she said, creates the same bottlenecks and quality problems that centralising software development once did. Her answer was a different way of organising data entirely — and she called it Data Mesh.
"We called it a data lake. What we actually built was a data swamp — a place where data goes in, and nothing useful comes out."
How a Lake Becomes a Swamp
In most enterprises, data is organised this way: every department — Sales, Finance, Operations, HR, Customer Service — generates data as part of their daily work. That data flows into a central data lake, managed by a single central data team. Once it arrives, that team owns it completely. They build the pipelines, define the structures, answer the requests, and maintain the quality. The business domains that generated the data move on. They consider their job done.
The central team is typically made up of skilled data engineers and analysts. But they are generalists. They understand technology. They do not always understand the business deeply enough to know what the data actually means — and that distinction matters more than most people realise.
A swamp is not a lake that was built badly. It is a lake that was never looked after. And the journey from one to the other follows the same path — in every industry, every country, every size of organisation.
The first few months feel exciting. Data comes in from the ERP, the CRM, the finance system. The central team works hard. Early reports look good. Leadership is happy.
Then more teams join. More sources are connected. The lake gets bigger. But nobody set clear rules about who is responsible for what. Who checks the quality? Who keeps the definitions consistent?
Slowly, the problems appear. One department calls something a "customer." Another calls the same person a "client." One system shows gross revenue. Another shows net. Which number is correct? Nobody can say for certain.
Human teams go back to their spreadsheets. Meanwhile, the data science team tries to connect an AI agent to the lake — only for the agent to hallucinate or break because it cannot reconcile the conflicting data definitions.
The lake is full. The lake is useless. A new platform is proposed.
Three Reasons Centralised Data Fails — and Why It Kills Agentic AI
After years of watching this pattern, I believe centralised data management fails for three core reasons. None of them are technical. But all of them are fatal to autonomous AI.
The Latent Context Gap — no one truly owns the data. When a central IT team is responsible for all data pipelines, no business team feels responsible for the data itself. The Sales team sends their raw data to the lake and considers their job done. When you centralise data, you strip away its latent context — the business knowledge behind the numbers. A human analyst can call a colleague to ask why a field was overridden. An AI agent cannot. It reads the data literally. And it acts on it — at speed, at scale, without hesitation.
API Blindness and Stale Data — one team cannot serve everyone. Every new report, every schema change, every new data source goes to the central team's backlog. As the organisation grows, this becomes a serious bottleneck. But there is a deeper problem for AI. Centralised platforms are engineered for historical, batch-processed data — pipelines running overnight. Agentic AI operates in continuous, real-time loops. An agent trying to optimise supply chain routes or flag fraud using a 24-hour-old data snapshot is essentially acting blind.
Structural Misalignment — the builders do not understand the business. Central data engineers are technically skilled. But they do not deeply understand each individual business domain. A metric can be technically flawless according to database rules and completely wrong in business context. Autonomous agents require precisely defined, programmatically enforced interfaces — known as Data Contracts — to function safely. A central team simply cannot maintain hundreds of distinct data contracts for domains they do not intimately understand.
A Pattern That Plays Out Everywhere
I have seen this in large government entities. I have seen it in global banks. I have seen it in fast-growing technology companies. The geography and the industry change. The pattern does not.
In many of the large organisations I have worked with — especially the incumbents — where approval chains are long and decisions travel upward, teams naturally avoid taking on data ownership. Accountability without real authority is a burden, not an opportunity. If something goes wrong with the data, the team that raised their hand will be answerable. If nothing goes wrong, nobody notices. That is not an incentive to volunteer.
The same dynamic plays out in organisations everywhere. Hierarchical structures, centralised IT functions, and procurement models that reward platform purchases over organisational change — these are global patterns. The platforms keep getting better. The ownership model stays the same. And now, with AI agents depending on that data to take autonomous business actions, the cost of that unchanged model is no longer just slow reports. It is automated decisions made confidently on wrong information.
So What Is the Answer?
There is a better way to think about enterprise data. Instead of asking "where does the data live?", ask "who is responsible for it — and who benefits from it?" Instead of treating data as an IT storage problem, treat it as an organisational product that must be owned, maintained, and delivered by the people who understand it best.
That way of thinking has a name: Data Mesh. It was conceived by Zhamak Dehghani, and it is the subject of Part 2. I have learnt a great deal from her writing and her work — and this series owes much of its intellectual foundation to her thinking.
Data mesh is not a magic fix, and it is not right for every organisation. I will cover its real limitations later in the series. But its central idea — that data should be owned and delivered like a product by the people who understand it best — is the most important shift in data thinking of the past decade. And in a world of autonomous AI agents, it is no longer optional.
Understanding why the old model breaks is the first step. We carry that understanding into Part 2.
Further reading: Zhamak Dehghani's original 2019 article — How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh — is the piece that started this entire conversation.
Coming next — Part 2: Everybody Is Buying Data Mesh. But Are They Implementing It? where we explore what data mesh is.