Enterprises spent the last few years building data platforms for two kinds of consumers: applications that read and write transactional data, and analysts who query curated tables and dashboards. A third consumer has arrived, and it behaves differently from both. AI agents issue many unpredictable queries, need to understand business meaning without asking a colleague, act on behalf of specific users, and can turn a small semantic misunderstanding into a confident, wrong answer delivered at scale.
The Model Context Protocol (MCP) has become the common way to connect agents to tools and data, and a wave of “MCP servers for your warehouse” followed. Connecting an agent to a database is easy. Connecting it in a way that respects ownership, data contracts, purpose limitations and cost is not. This is where data mesh, often criticized as organizationally heavy, turns out to be unusually well suited. This playbook explains why and shows how to make a data mesh agent-ready.
Why Agents Break Traditional Data Access
Most early agent-to-data integrations follow the same pattern: give the model a generic tool that lists schemas and runs SQL, then let it figure things out. It demos well and fails in production for predictable reasons.
- Semantic ambiguity. “Active customer” means different things to sales, finance and support. A model reading column names will pick one interpretation and rarely say so.
- Over-broad access. A service account with read access to a warehouse lets the agent reach data the end user is not entitled to see, unless identity is propagated and enforced.
- Purpose blindness. Data that may be used for service quality analysis may not be permitted for marketing. Generic SQL tools have no notion of purpose.
- Cost and performance. Agents can generate expensive exploratory queries and large result sets that also inflate token consumption.
- No accountability. When an answer is wrong, there is no owner for the tool, the query or the underlying dataset.
At QCon AI Boston in August 2026, Fabiane Nardon of TOTVS made the underlying point crisply in her talk on enterprise data architecture for agents, as InfoQ reported: transactional data was optimized for applications, and lake data for analysts and dashboards. Neither was designed for agents.
Why Data Mesh Fits Agents Surprisingly Well
Data mesh was designed to solve a scaling problem for human consumers: too many datasets, too few central engineers, and no clear ownership. Agents amplify exactly that problem, and the mesh’s building blocks map neatly onto what agents need.
- Domain ownership gives every tool an owner. If each agent-facing tool belongs to a data product, someone is accountable for its correctness, performance and evolution.
- Data products give agents a curated surface. Instead of thousands of raw tables, agents see a catalog of products with descriptions, output ports and documented semantics.
- Data contracts give agents machine-readable meaning. Standards such as the Open Data Contract Standard (ODCS) capture schema, business definitions, quality rules, SLAs and usage terms in YAML. Thoughtworks notes that this declarative format helps both humans and AI agents interpret and validate contracts.
- Federated computational governance gives agents guardrails. Policies that are already expressed as code, such as classification-based masking or purpose restrictions, can be enforced automatically at the moment an agent requests data.
Do not give agents a database. Give them data products, each with an owner, a contract and a small set of governed tools.
The Pattern: Data Product MCP
A concrete reference for this pattern appeared in a 2026 paper, “Data Product MCP: Chat with your Enterprise Data,” by researchers from Eindhoven University of Technology, Tilburg University, King’s College London and Entropy Data. The authors describe an MCP server integrated with a data product marketplace that exposes four tools: search for data products, get a product’s details (including output ports and inlined contracts), request access to an output port with a stated purpose, and run a query on a port the user can access. An open source implementation, dataproduct-mcp, works with Data Mesh Manager and lists Snowflake, Databricks and BigQuery as supported platforms.
Three design ideas in that work are worth adopting regardless of which tools you use:
- Discovery before access. Agents first find and read product metadata and contracts, so they reason about meaning and terms before touching data.
- Purpose-bound access requests. Access is requested for a declared purpose that the product owner, or an automated policy, evaluates against contract terms. Sensitive products can require human approval while low-risk ones are granted automatically.
- Query-time evaluation and audit. Each query is checked for consistency with the contract’s terms of use and logged. In the paper’s demonstration, a query was blocked because its stated marketing purpose conflicted with the contract, even though the user had access to the data.
The paper is candid about limits: its evaluation is qualitative, based on feedback from sixteen governance experts, and the authors are involved in the underlying marketplace. Experts’ main concerns were metadata quality, security, scalability, cost and trust in LLM-based checks. Those concerns are a good checklist for any implementation.
Design Principles for Agent-Facing Data Products
Prefer domain-specific, parameterized tools over generic SQL
For high-traffic or sensitive use cases, expose tools such as get_order_status(order_id) or monthly_revenue(region, month) implemented in code that enforces access rules and uses vetted queries. Nardon’s talk made the same recommendation: domain tools owned and governed like data products, rather than generic schema-reading tools, avoid unmanaged tool sprawl. Generic, contract-checked SQL remains useful for exploratory analytics, but it should be the exception path, not the default.
Propagate the user’s identity
Agents should query with the permissions of the person they act for, not a privileged service account. Use OAuth-based delegation where your platforms support it so that row- and column-level policies apply to agent queries exactly as they do to human ones.
Make semantics explicit and scoped
Business definitions belong in contracts and semantic models, not in prompts. Where terms differ by department, give them distinct identifiers. Nardon described using ontologies filtered per data product to resolve such ambiguity while keeping context small. Even without a formal ontology, a governed semantic layer with metric definitions is a large step up from column names.
Design for cost from the start
Cap result sizes, return aggregates rather than raw rows where possible, cache frequent answers, and load tool definitions dynamically rather than presenting an agent with hundreds of tools at once. Track query and token costs per data product so owners see what their agent consumers cost.
Separate deterministic and probabilistic work
Calculations, entitlement checks and business rules belong in deterministic code. Use the model for interpretation, orchestration and explanation. The more a tool does deterministically, the easier it is to test and the less a model’s variability matters.
Choose the right data source per workflow
Not every agent question should hit the analytical platform. Fresh operational facts, such as whether a payment just went through, and any write action belong with the transactional system and its APIs. Historical analysis, enrichment, semantic search and data that can tolerate minutes of delay belong with the data platform. Making that choice explicit per tool avoids two common failures: agents giving stale answers from a nightly table, and agents hammering a production database with analytical queries. Some teams add a small low-latency serving store, such as PostgreSQL with vector search, fed from curated data products specifically for agent queries.
Version tools like APIs
An agent-facing tool is an interface with consumers you cannot easily see. Version tool signatures and descriptions, publish deprecation timelines, and keep old versions running during a transition. Tie each tool version to the contract version it reads, so a contract change triggers a review of the tools built on it. This is ordinary API hygiene, but it is often forgotten because tools are created in an afternoon.
A Step-by-Step Rollout Playbook
- Pick one agent use case with measurable value. Examples include a support assistant answering order and entitlement questions, or a finance copilot explaining variance. Identify the three to five data products it needs.
- Bring those products up to agent grade. Each needs an owner, an ODCS contract with clear business definitions and usage terms, quality checks running in production, and freshness that matches the use case.
- Publish products to a catalog the agent can search. Product descriptions should be written for a reader with no tribal knowledge, because that is what an agent is.
- Implement MCP tools per product. Start with discovery and a small set of parameterized tools; add governed query access only where exploration is needed.
- Wire in identity and purpose. Propagate end-user identity, require a declared purpose for access requests, and define which products auto-approve and which need owner review.
- Instrument everything. Log every tool call with user, purpose, product, query, latency, rows returned and cost. Feed failures back to product owners.
- Evaluate before scaling. Build a test set of real questions with known answers, measure accuracy and refusals, and review blocked requests to tune policies.
- Expand domain by domain. Use the first products as templates. The platform team turns repeated work, such as tool scaffolding and audit logging, into self-serve capabilities.
Worked Example: A Support Assistant on a Mesh
Picture a software company whose support team wants an assistant that answers questions such as “Why was this customer charged twice?” and “Which features does this account have?” The relevant data lives in three domains: billing, subscriptions and product usage.
Each domain publishes a data product with a contract. Billing exposes an invoice-and-payments port with a contract that classifies card fragments as restricted and allows use for customer support and finance reconciliation, but not for marketing. Subscriptions exposes entitlements with a precise definition of “active plan.” Usage exposes daily feature usage aggregates, with no raw event data.
The assistant gets five tools: product search, product details, and three parameterized tools (invoice_history, entitlements and feature_usage_summary), each owned by its domain. Queries run with the support agent’s identity, so a tier-one agent sees masked payment fields while a billing specialist sees more. When a product manager later tries to reuse the assistant to build a list of customers for an upsell campaign, the purpose check flags that billing data is not licensed for marketing and routes the request to the billing owner instead of returning data.
Over the first months, logs show which questions fail. Most failures trace to an ambiguous refund status in the billing contract, which the billing team clarifies in a new contract version. Accuracy improves without touching the model or the prompts, because the fix happened where it belongs: in the data product.
Risks and How to Manage Them
- Metadata quality. Agents are only as good as product descriptions and contracts. Treat documentation defects as bugs with owners and SLAs.
- Prompt injection through data. Free-text fields can contain instructions. Sanitize or label untrusted content, and keep authorization in code rather than in model judgment.
- LLM-based policy checks. Automated purpose evaluation is helpful but probabilistic. Use deterministic rules for hard constraints and reserve model-based checks for triage, with human review for sensitive products.
- Tool sprawl. Without ownership, teams create overlapping tools. Register tools in the catalog as part of the product, with lifecycle states and deprecation.
- Regulatory exposure. Where agents support decisions in regulated areas, keep audit logs and lineage that show which data products and versions informed each answer.
Outlook
Over the next two years, expect data product marketplaces and catalogs to ship agent interfaces as standard, contracts to carry richer usage and purpose terms, and platform vendors to converge on MCP as the way agents reach governed data. The harder, slower work will remain organizational: getting domains to own agent-facing products with the same seriousness as customer-facing APIs. Organizations that already invested in data mesh principles have a head start, because the ownership model, contracts and computational governance are exactly what agents need.
Conclusion
AI agents are not just another BI tool; they are high-volume, semantically naive, identity-sensitive consumers that magnify every weakness in data ownership and governance. Data mesh, with domain-owned products, machine-readable contracts and policy as code, offers a structure that fits them well. Expose products, not databases. Give each product a small set of owned, parameterized MCP tools. Propagate identity, bind access to purpose, log everything, and fix wrong answers in the data product rather than the prompt. Done this way, agents become a reason to finish your data mesh rather than a threat to it.
How Hanoi Technology Can Help
Hanoi Technology helps organizations turn domain data into governed, agent-ready data products with contracts, MCP tools and audit-ready access controls.