Agentic AI Enterprise Data & Analytics Platform
A reference architecture for agentic AI over enterprise data, with a semantic layer, hybrid retrieval and governed OLTP and OLAP stores beneath it.
The challenge
Letting AI agents answer questions over enterprise data without handing them raw tables — and keeping every answer governed, traceable and consistent with the metrics the business already agreed on.
The instinct when connecting an agent to enterprise data is to point it at the warehouse and let it write SQL. That works in a demo and fails in production for one reason: two agents asked the same business question will compute it two different ways, and neither matches the number the finance team reports.
How it works
The semantic layer is the centre of this architecture, not an optional convenience. It holds the agreed definition of every metric and dimension, the transformations that produce them, and the lineage back to source columns. Agents call it through the semantic interface — APIs and an MCP interface — rather than reaching past it to the tables underneath.
Retrieval is hybrid because enterprise questions are hybrid. “Show me invoice INV-4471” is a lexical lookup; “which accounts look like they are about to churn” is a similarity search. A platform that offers only one of the two fails half its questions, and which half is not predictable in advance.
Beneath both sits the enterprise data store, split between OLTP systems of record and OLAP warehouses, lakes and lakehouses, increasingly on open table formats so the same physical data serves more than one engine.
The two rails are drawn vertically on purpose. Data quality, observability, governance, security and metadata management are not a layer with neighbours above and below — they apply to every layer at once, and an architecture that files them as a box at the bottom tends to implement them that way too.
What to get right
- Define metrics once. If the semantic layer is optional, it will be bypassed, and the platform becomes a very expensive way to disagree about revenue.
- Expose the semantic layer over MCP, not the warehouse. Giving an agent raw table access is the fastest route to confidently wrong answers.
- Lineage is what makes an answer defensible. When someone challenges a number, the path from answer to source column is the whole argument.
- Cache at the metric, not the query. Agents ask the same handful of business questions in endless phrasings; a metric store absorbs that, a query cache does not.
- Put quality checks in the pipeline, not in a dashboard. A failed expectation should stop a load, not decorate a report nobody reads.
How it fits together
Agentic and intelligence layer
Data products, data apps, BI and analytics agents, and domain-specific agents. This is the only layer an end user or an LLM interacts with directly.
Search and retrieval layer
A hybrid solution combining lexical search for full-text and keyword matching with semantic similarity search, so exact identifiers and fuzzy questions both resolve.
Semantic interface
APIs and an MCP interface — the contract agents call. Exposing the semantic layer over MCP is what lets an agent ask for a governed metric rather than write SQL against raw tables.
Semantic modeling and lineage
Modeling, transformation and lineage tracking. One definition of revenue, churn or active customer, versioned, with the path back to source columns recorded.
Semantic query engine
Compiles a semantic request into physical queries and optimises them — caching, pushdown and result reuse — so a question is answered without a full scan.
Metric storage and analytics
Pre-computed and cached metric results, so repeated agent questions hit a metric store rather than recomputing the same aggregate every time.
Data integration and connectors
Batch and streaming ingestion from operational systems and SaaS applications into the stores beneath, with schema handling at the boundary.
Enterprise data store
OLTP systems of record — relational, NoSQL and graph — alongside OLAP warehouses, data lakes and lakehouses built on open table and storage formats.
Data quality and observability rail
DataOps and the data SDLC, quality checks, monitoring across metrics, events and traces, and SRE ownership — running the full height of the stack, not bolted to one layer.
Governance, security and metadata rail
Identity and RBAC, catalogue and metadata management, storage management, and open table formats — the controls every layer above is subject to.
Typically built with
- dbt
- Apache Iceberg
- Trino
- Model Context Protocol
- OpenLineage
- Great Expectations
