The data mesh gave the organization ownership and structure. The missing piece was giving non-technical users a direct line to that data – without compromising quality or governance.
Johannes Bitsch, Principal IT Architect
Background: From Data Mesh to Data Access
The customer, a major player in the automotive industry, had already embraced a data mesh architecture – with data products managed across many domains. Data ownership is decentralized, metadata is cataloged, and the technical foundation is built on an established data platform. The data mesh itself had been architected and co-developed with MMK DIGITAL.
However, while the organizational and technical groundwork for scalable data management was in place, accessing that data remained a challenge. Business users who needed insights – whether for production planning, configuration analysis, or cross-domain reporting – still had to rely on analysts writing SQL queries. This created a familiar bottleneck: requests piled up, turnaround times stretched to days, and data access – while technically possible – remained bottlenecked by analyst availability.
The question became: How can we bring the power of the data mesh directly to the people who need the answers?
Read here how MMK DIGITAL operationalised Data Mesh for the organization.
Pain Points: Data Available, But Not Accessible
The data mesh had solved the problem of data ownership and quality at scale. But a new friction point had emerged: the last mile between structured, governed data and the business users who needed it.
Analysts served as intermediaries – receiving requests, translating them into SQL, running queries across one or more data products, and delivering results. For simple lookups this was manageable, but for cross-domain queries – combining data from different data products of various organisational units and domains – the complexity grew quickly. Queries often required joins across multiple data products, deep knowledge of the data model, and careful handling of edge cases such as distinguishing between model variants or excluding specific configuration codes.
The result: time-to-insight was measured in days and required a ticket. Business users lacked autonomy, analysts were overloaded with repetitive requests, and the full potential of the data mesh remained locked behind technical expertise.
Product Owner Data Analytics, ClientGoals & Strategic Guidelines: Portable, Reusable, LLM-Agnostic
The goal was clear: enable business users to query data products using natural language, enabling self-service and minimizing time-to-insight.
But beyond the immediate use case, MMK DIGITAL and the customer defined a set of strategic design principles:
- Platform independence – the solution must not be locked into a single LLM, agent framework, or cloud provider. Core logic and data access should be reusable across environments.
- Separation of concerns – data discovery (finding the right data products) and data querying (retrieving actual results) should be cleanly separated to allow independent evolution and reuse.
- Context efficiency – the agent must intelligently select only relevant data products to avoid overloading the LLM’s context window – which would degrade response quality.
- Leverage existing infrastructure – the solution should build on the established data platform and data catalog rather than introducing parallel systems.
- Observability – agent behavior and latency must be traceable and monitorable for debugging and continuous improvement.
Alexander Rengers, Senior IT ArchitectOur Contribution: Architecture, Prototyping, and Proof of Portability
MMK DIGITAL was responsible for the end-to-end architecture design as well as the POC and prototype implementation. The solution centers on an AI agent built with the Strands Agents SDK using Claude Sonnet 4.6 on AWS Bedrock as the underlying LLM and Chainlit as the conversational frontend. This technology stack provides a mature foundation for enterprise-ready agentic systems. Users can interact with the system through natural-language questions, while the agent automatically identifies the relevant metadata, interprets the user’s intent, and generates the corresponding SQL query. Before execution, the query is presented to the user for review and approval, ensuring full transparency and control. Once confirmed, the query is executed and results are returned within seconds. Observability is provided through Phoenix tracing, enabling full transparency into agent reasoning and execution paths, while Plotly is available as a custom tool for generating business-friendly visualizations directly from query results.
From the user perspective it goes like this: The user asks the agent a question. The agent automatically identifies the relevant metadata, interprets the user’s intent, and generates the appropriate SQL query based on the available data structure. Before execution, the query is presented to the user for review and confirmation through a handoff step. Once approved, the query is executed, allowing the user to receive accurate results within seconds.
The core architectural innovation lies in the two-MCP-server pattern.
1. Dataproducts MCP Server (Discovery & RAG):
This server connects to the vector database Qdrant, where metadata from the data catalog is indexed. When a user asks a question, the agent first uses this MCP server to discover which data products are relevant – performing semantic search to retrieve only the necessary context. This keeps the LLM’s context window lean and responses accurate. At the same time it allows business users to discover and understand available enterprise data without needing deep knowledge of the underlying data landscape.
2. Query Engine MCP Server (Data Retrieval):
Once relevant data products are identified and their metadata understood, the agent uses the Query Engine MCP server to construct and execute queries via Impala. This includes complex operations such as joins across multiple data products, filtering by specific attributes, and handling exclusion logic – all generated from natural language input. This enables business users to perform sophisticated cross-domain analyses without requiring deep SQL expertise or support from data engineering teams which reduces dependency to others and increases the teams flexibility.
Additional MCP servers for Datasphere and DuckDB extend the architecture for multi-platform querying capabilities.
Proof of portability: When the customer’s AI strategy evolved to adopt Copilot Studio as the standard agent platform, MMK DIGITAL ported the solution by reusing the same MCP servers and adapting the system prompt. Despite switching from Claude Sonnet 4.6 to GPT-5, the results were near-identical – validating the architecture’s independence from any single LLM or framework.
Efstratios Baxivanelis, Professional IT ArchitectImpact: From Days to Minutes
The most immediate impact is measured in time: queries that previously required analyst involvement and took up to two days can now be answered directly. The agent handles the complexity of data discovery, query construction, and cross-domain joins – tasks that previously demanded deep technical knowledge.
Apart from the increase in speed, the solution shifts the operating model. Analysts are freed from repetitive query work and can focus on higher-value analysis. Business users gain autonomy and can explore data iteratively – asking follow-up questions, refining queries, and drilling into results in a conversational flow.
The successful port to Copilot Studio demonstrated that the architecture delivers on its portability promise. The organization is not locked into a single technology stack, and as LLMs and agent frameworks evolve, the core investment in MCP servers, metadata indexing, and query logic remains fully reusable.
The first version of the agent is now approaching production readiness.
