“Why did margin fall for this customer after the promotion?” A lakehouse can hold the sales rows, but those rows do not explain which customer identity, margin formula, promotion window, or access rule the question means.
Medallion architecture is a data-design pattern for improving records in three successive layers, not three separate Fabric products. Bronze retains source-aligned records and load history; Silver cleans and reconciles them; Gold publishes a curated data product for a defined business use.
The layers matter for AI because an agent needs traceable, consistent facts rather than a collection of unrelated source tables. Bronze preserves the original sales and promotion evidence; Silver reconciles customer IDs, dates, currencies, and duplicates; Gold gives the agent a curated sales dataset to query.
Clean Gold data still cannot tell an agent which margin formula the business accepts. A Power BI semantic model can define that calculation, while an optional Fabric IQ ontology (preview) can describe entities such as Customer and Promotion and their relationships. Permissions, freshness, and answer tests remain separate work.
In the wider Microsoft agentic AI stack, this foundation is the data and context layer that agents query. If your organization is still deciding where Fabric should start, adopting Microsoft Fabric for business and AI covers that earlier choice.
Records, metrics, and entities do different jobs.
Medallion Architecture Prepares the Records
In Fabric, these layers can use lakehouses, warehouses, or a combination. A lakehouse stores structured and unstructured data in Delta format and is developed mainly with Apache Spark notebooks, with a read-only SQL endpoint for queries. A warehouse is a relational store developed with T-SQL and supports multi-table transactions, which can suit SQL-centered curation.
OneLake is the shared storage foundation under both, not a fourth medallion layer. Fabric materialized lake views offer a declarative way to express some bronze-to-silver-to-gold transformations, including quality constraints and dependency-aware refresh. Notebooks and Data Factory pipelines (formerly data pipelines) remain valid when the workload needs orchestrated ingestion or custom code.
The useful design question is not “Do we have three folders named bronze, silver, and gold?” It is “What contract does each layer fulfill?” For the promotion question:
| Layer | Required contract | Failure if absent |
|---|---|---|
| Bronze | Preserve source order, account, and promotion records with load history | No way to reconstruct the evidence |
| Silver | Resolve account IDs, dates, currencies, returns, and duplicate events | The same customer or sale is counted inconsistently |
| Gold | Publish a documented sales and promotion product at an explicit grain | Downstream consumers each rebuild the business logic |
Raw and intermediate layers usually need narrower access than curated outputs, and each gold product still needs its own access decision per agent and user group.
A Semantic Model Defines the Analytical Answer
Gold tables may expose sales amount, cost, rebate, and date, but “margin” is not self-defining. A Power BI semantic model can define the accepted measure, its relationships, dimensions, and security. It gives reports and compatible agent experiences a common analytical vocabulary.
For example, finance may approve a contribution-margin measure that handles rebates and returns on a particular accounting basis. The model makes that calculation inspectable and testable, with its time grain, account hierarchy, and roles. Without that work, two agents can query the same clean gold table and return different, internally plausible numbers.
Endorsement helps people find authoritative items: a certified semantic model has passed the organization's certification process. That is a useful ownership signal, not a guarantee that every future question is answered correctly.
A metric definition is not an entity relationship.
An Ontology Adds Entity Context, Not a New Formula
Fabric IQ ontology represents business entity types, properties, and relationships, so a customer, a promotion, and a product become explicit concepts rather than table names an agent must infer. That is most valuable when a question crosses domains or depends on relationships that do not fit neatly into one report.
Microsoft documents two starting paths for ontology (preview): generate one from a Power BI semantic model, or build it directly over OneLake data. Generation creates entity types, properties, some data bindings, and relationship types. Keys, time-series bindings, relationship bindings, and the resulting domain model still require review and, often, manual completion.
In the promotion question, the semantic model calculates the measure by customer and period. An ontology can represent that a customer belongs to an account group, bought products in a campaign, or is associated with an operational event. It does not establish that the promotion caused the change; a causal claim needs a separate analytical design and evidence.
How a Fabric Data Agent Uses This Context
A Fabric data agent is a Fabric item that answers natural-language questions by generating read-only queries over up to five selected sources, such as lakehouses, warehouses, and semantic models. It can use a semantic model as a source and an ontology as a preview source.
That gives business context a consumption route, but the agent's source selection, permissions, generated queries, and final wording still need testing. For the agent routes and their controls in depth, see talk to your data with agents in Power BI and Microsoft Fabric.
What a Trustworthy Answer Needs
A plausible sentence is not the same as an evidenced answer, so make the required evidence visible before any agent is deployed.
The agent should show what it knows and what it cannot infer.
Each check has a different fix. Silver reconciliation fixes Identity; the semantic model fixes Metric and, with a governed promotion calendar, Period; an ontology may help with both when those concepts span domains. Access needs tested permissions for both the user and the agent, and Freshness needs a visible refresh time and an inspectable query or source.
Build One Domain Before an Enterprise Knowledge Graph
Start with a decision the business already cares about, such as promotion margin, inventory availability, or service-level performance. Name the business owner and accept the metric definition before building an agent around it.
A useful first release has:
- raw source traceability and tested silver transformations
- a gold data product with an explicit grain
- an approved semantic model and access tests
- a small question set with expected answers
Add an ontology only if entity relationships materially improve those questions, and verify its preview tenant settings, supported sources, and support before making it a production dependency.
Reliancy recommendation: Treat the first agent as a test of the foundation. When an answer is wrong, identify whether the failure was source quality, identity resolution, metric definition, permission, retrieval, or reasoning. A bigger prompt or a bigger lakehouse is rarely a substitute for a missing business contract.
Discuss an AI-ready Fabric data foundation with Reliancy.
Sources and Product Documentation
- Medallion architecture in OneLake
- Implement medallion with materialized lake views
- Warehouse and lakehouse decision guide
- Pipelines in Fabric Data Factory
- OneLake overview
- Fabric IQ getting started
- Generate an ontology from a semantic model
- Fabric ontology tutorial
- Fabric data agent concepts
- Fabric data-agent sources
- Semantic-model best practices for data agents
- Fabric endorsement overview
- Fabric security scenario