Dieser Blogpost ist auch auf Deutsch verfügbar
TL;DR
- When AI agents fail, it is rarely the model’s fault but the data: semantics, quality, and context are documented nowhere and instead live in the experience of the business units.
- Data Mesh solves this problem conceptually, but organizationally overwhelms mid-sized companies: missing domain teams, data cut along standard software, IT as a mere support process.
- A Minimum Viable Data Mesh (MVDM) adopts the core (data as a product, business ownership, explicit contracts, consistently oriented toward consumers) and simplifies or postpones everything that presupposes an organizational restructuring.
- The entry point is use-case-driven and incremental, using established tools (dbt, MCP, Git, a contract format); Part 2 shows the implementation in four layers.
This post is part of a series.
- Part 1: The Data Dilemma, Part 1 (this post)
- Part 2: The Data Dilemma, Part 2
In discussions about agentic systems, the focus is often on models, frameworks, and orchestration. Data quickly appears as an existing resource that you just need to plug in. Anyone who wants to implement agentic use cases in a mid-sized company usually experiences something else: the model is rarely the biggest problem.
Agents need more than table access. They need data with a good signal-to-noise ratio, clear semantics, examples, and metadata about meaning, timeliness, and access rights. They have to know what the data is intended for, what gaps it has, and when it is not reliable. A field like kunde_aktiv = true is only helpful if it is clear what “active” means in business terms: last order in the past year, an ongoing contract, a non-archived CRM entry, or something else. This exact information is not documented in many data landscapes.
Data Mesh as the target picture
Conceptually, Data Mesh provides a convincing answer to this problem. Responsibility for data moves to the producers, analogous to DevOps and API-first. Domain teams understand their own data best, know about migrations, and document the semantics. They deliver data as a product: with an owner, a contract, and a quality promise.
A platform enables data discovery, ideally in a way that agents can work with too. Contracts are explicit, owners are named, and annotation is mandatory. Anyone who needs a new data source finds it via a catalog, reads the description, checks the quality indicators, and consumes it. Responsibilities are clearly distributed, and producers actively communicate changes to their consumers.
In such an environment, agents can work well. Many companies, however, are far from this.
Why most companies do not get there
Anyone who wants to introduce Data Mesh in mid-sized companies quickly runs into practical limits.
In most companies, data is not cut along business lines, but along standard software. What lives in Salesforce belongs, organizationally, to Salesforce, not to the Customer domain. What lives in SAP belongs to SAP, not to Logistics or Finance. The data cut follows the license agreement, not the business domain. Alongside this, there are often grown custom solutions: old, barely maintained, but important to the business. The knowledge about these systems lives in the heads of the employees. When a customer number looks odd, a colleague knows that this customer dates back to before Salesforce and that their contract details are found in another system. This exact implicit knowledge is what an agent lacks.
And this knowledge is more fragile than you might like to assume. It is often fragmented: sales knows what “active customer” means in business terms, but not how the field is populated in the Salesforce replica. The developer who built the custom solution left the company three years ago. Some linking rules exist only as the habit of individual people who are about to retire.
The business teams that understand their data semantically often lack the engineering know-how to deliver it as a product. They know what aktiver_kunde means, but cannot build a dbt model. The engineering teams, in turn, often lack the business knowledge to interpret the data correctly. The domain-team constellation that Data Mesh presupposes does not exist in many companies.
On top of this comes an organizational argument that is often underestimated. In many manufacturing companies, IT is a support process. Critical, yes, but not value-adding. Anyone who proposes a transformation that delays or burdens value creation will find it hard to get support for it. A data initiative therefore has to legitimize itself through concrete, short-term visible benefit. Data Mesh remains a sensible direction, but for many mid-sized companies it is hard to reach. It requires a size and an organizational maturity that many simply do not have.
The question restated
This article is not aimed at companies with functioning domain teams and platform engineering. It is aimed at all the others: at companies that want to implement agentic use cases but cannot wait years first, until their data landscape is transformed. The question is therefore: how do we supply AI systems with data that agents can find, understand, and classify safely? What is a Minimum Viable Data Mesh (MVDM) that takes over the core of data contracts without restructuring the organization first? The goal is a feasible entry point: use-case-driven, incremental, and without the ambition of first building the perfect target architecture.
What we adopt from Data Mesh, what we simplify
A Minimum Viable Data Mesh is not just any light version of Data Mesh. It is a selection: what from the original concept is indispensable for agent-ready data, and what can be simplified for now? If you make this distinction cleanly, you get an approach that is both viable in business terms and feasible organizationally.
What we adopt. The core concept Data as a Product stays. Every curated view we build is a small product with an owner, a description, a quality promise, and named consumers. A quickly assembled SQL query for the next use case is not enough. The view is an explicit contract with the agent as the main consumer.
Business ownership is also preserved. Business authority over the meaning of the data lies with the domain, even if the technical implementation stays with IT. What aktiver_kunde means is decided not by the database administrator but by sales. The engineering work can be centralized. With authority over definitions, that would be a mistake. This separation is decisive for the quality of the data products.
The self-service idea stays, but is oriented toward agents. The original concept aimed at self-service BI for end users. For agents, what counts above all is structured metadata and clearly described data products. A well-described data product is easy for an agent to use. For humans, it often additionally needs a UI.
Federated computational governance, in Data Mesh the approach of negotiating governance rules federally between the domains and enforcing them automatically in code, is reduced to a minimum. There are standards for view metadata, naming conventions, and mandatory tests. But no governance board and no regular committee meetings. Governance is moved into the development process as far as possible: templates, linters, tests, and code reviews replace additional coordination rounds.
What we simplify. Complete domain teams with their own platform engineering and data POs are unrealistic in most mid-sized companies. The engineering work stays with a small central team, the domains deliver semantics and validation. That costs autonomy, but makes implementation more realistic. If you cannot build ten engineering teams, you should not plan your architecture that way either.
Polyglot persistence, that is, the freedom of each domain to choose its own storage technology, we likewise simplify. In an MVDM you take what is established in-house. A central Postgres or Snowflake instance is enough to start. That is less idealized, but considerably lower-maintenance. The diversity of storage technologies usually pays off only above a certain organizational size. We also do without a complete domain cut of the data for now. As long as standard software dictates reality, data cannot be cut along business domains at the source. We abstract in the view layer and leave the source systems as they are. The business abstraction instead arises in the curated views.
We also do not put the platform as a product at the beginning. A real data platform with self-service onboarding for new data products is a large project in its own right. To get started, a combination of established tools is enough: dbt, MCP, Git, and a contract format. Anyone who later wants to build a real platform out of it has the right building blocks. A platform investment only pays off once there are enough data products to use it.
This preserves the relevant core of Data Mesh: explicit contracts and semantic responsibility close to the domain, both consistently oriented toward the consumers as the recipients.
What is explicitly not on the critical path
A Minimum Viable Data Mesh is based on deliberate reduction. It should therefore be clear what is not on the critical path:
- No central data warehouse as a prerequisite. Maybe one will emerge later, maybe not.
- No blanket schema migration of the source systems. The sources stay as they are; the abstraction lies in the view layer.
- No data governance organization with boards and stewards.
- No complete lineage across all systems. Maybe for the curated views, certainly not for the whole landscape.
- No self-service BI for end users. That is a different problem with different requirements.
Agent actions, write access, and transactional safety are also outside the focus. Here it is first about the foundation: agents have to be able to find data and classify it correctly in the first place. Anyone who puts the more advanced topics at the beginning increases the risk of long preparatory work without visible benefit.
Outlook
With that, the framework is staked out. A Minimum Viable Data Mesh adopts from Data Mesh what matters for agents: explicit contracts and business ownership. Everything that presupposes an organizational restructuring is replaced by simpler means or postponed. How this framework can be filled in is shown in the second part. There, a purchasing agent that compares suppliers and evaluates price histories guides the approach through four layers: from an inventory of the existing sources, through curated views with ODCS contracts and unified access via MCP, to feedback from live operation.