Ontology-Driven Data Agents in Microsoft Fabric IQ: A Practical Guide
Learn how Microsoft Fabric IQ combines semantic models, ontologies, and MCP to move enterprise AI agents from data retrieval to governed business reasoning.
This article is published in English.
Sources: Microsoft Fabric IQ and Data Agents for Ontology based Consumption
TL;DR Enterprise AI is going through a meaningful shift. The first wave of enterprise generative AI was mostly focused on retrieval. The next wave of enterprise agents will go further than fetching data — they will reason using governed business meaning.
Question
↓
LLM
↓
Vector Search / RAG
↓
Documents
↓
Answer
The emerging model centers on reasoning over business meaning:
Business Question
│
▼
Agent / Planner
│
┌─────────┴─────────┐
▼ ▼
Semantic Model Ontology
"How measured?" "What does it mean?"
│ │
└─────────┬─────────┘
▼
Enterprise Data
│
▼
Insight / Decision
│
▼
Action
This difference matters a great deal.
A plain database can tell an agent something like:
customers.CustomerId = sales.CustomerId
An ontology, by contrast, can tell the agent:
Customer ── PURCHASES ──> Product
And a semantic model can go one step further and tell it:
Total Revenue = governed enterprise measure
These represent three completely different depths of understanding.
Microsoft is weaving these ideas together under Fabric IQ, where the semantic model supplies trusted analytical measures, the ontology supplies a shared enterprise vocabulary and relationship structure, the graph layer supplies connected-data traversal, and Data Agents surface all of that intelligence through conversation. Microsoft frames Fabric IQ as the business-context layer that turns raw analytical and operational data into business concepts an agent can actually reason about.
The architectural twist that makes this genuinely interesting is this:
You can publish a Fabric Data Agent and expose it through the Model Context Protocol (MCP), so that Microsoft Foundry agents — or any other MCP-compatible agent — can consume governed enterprise intelligence as just another tool.
Microsoft now supports exactly this flow: a published Fabric Data Agent can show up to a Foundry agent as an MCP tool, and a single Foundry agent can then coordinate several Fabric Data Agents alongside other tools and knowledge sources.
1. Why Ontology Is Suddenly Important Again
Ontology is not a new idea.
Knowledge graphs are not new either.
Neither are semantic models.
What has actually changed is who is using them.
Historically, enterprise semantic technology was consumed mainly by:
- search platforms
- BI tooling
- data integration systems
- taxonomy management
- graph-based applications
- domain experts
Now there's a new consumer in the mix:
AI agents.
And agents run into a real obstacle here.
Large language models reason well over the information handed to them, but enterprise databases almost never describe the business the way people naturally think about it.
For example:
CUSTOMER_MASTER.CUST_ID
SALES_TXN.CUST_ID
SALES_TXN.PROD_NM
SALES_TXN.NET_REV
A person, however, thinks in terms like:
Customer
│
│ PURCHASES
▼
Product
│
└── generates → Revenue
The distance between these two representations is where a large share of agent uncertainty comes from.
Lacking semantic grounding, the agent is forced to guess:
- which tables correspond to which business concepts
- which joins are actually valid
- what a given column really represents
- which metric definition should be treated as authoritative
- how entities relate to each other
- whether two differently named fields actually mean the same thing
That's a tolerable problem in a five-table demo.
Across hundreds of enterprise data products, it becomes genuinely risky.
Fabric's Ontology feature is built specifically to act as a machine-readable, shared business vocabulary made of entity types, properties, relationships, constraints, and bindings back to real OneLake data. That vocabulary can be consumed equally by human users and by agents.
2. But "Knowledge Graph" Does Not Mean One Architecture
A visual decision flow accompanying this discussion helps clarify why picking a graph and ontology approach isn't a one-size-fits-all choice.
[Insert: Graph & Ontology Solution Decision Flow]
There is no single correct way to architect a graph.
The landscape can roughly be split into five patterns.
Pattern 1 — RDF / Semantic Knowledge Graph
This is the traditional semantic-web approach:
Subject ─ Predicate ─> Object
It's usually paired with:
RDF
RDFS
OWL
SPARQL
Advantages: rich expressive semantics, standards-based interoperability, mature approaches to ontology modeling, and support for formal reasoning.
Tradeoffs: heavier modeling complexity, a need for specialized skills, and infrastructure that frequently exceeds what the actual application requires.
3. Labeled Property Graphs
The labeled property graph (LPG) model takes a more application-first approach:
(Customer)
│
│ PURCHASED
│ {date, quantity}
▼
(Product)
Both nodes and edges can carry their own properties.
Tools like Neo4j popularized this model because it fits naturally with traversal-heavy applications.
Advantages: intuitive graph modeling, strong traversal performance, mature graph algorithms, and a solid application-development experience.
Tradeoffs: the graph schema on its own doesn't turn into a governed enterprise semantic vocabulary — that layer of meaning still has to be modeled and governed separately.
Microsoft Fabric Graph follows this LPG approach, mapping OneLake tables into node and edge types and exposing traversal through GQL. Microsoft's implementation of GQL follows the ISO-standardized Graph Query Language.
4. A Lighter Path: Ontology Plus an In-Memory Graph
Not every agent requires a full enterprise graph database.
For chat-style applications, edge scenarios, narrowly-scoped assistants, or proof-of-concept work, you can represent a simple ontology as plain JSON:
{
"entities": {
"Customer": {},
"Product": {}
},
"relationships": {
"Purchases": {
"from": "Customer",
"to": "Product"
}
}
}
Your application layer can then load that definition into NetworkX, Memgraph, an RDF library, or any other in-memory graph structure.
This route is quick to set up and cheap to run.
The catch is that governance, security, lineage tracking, scaling, keeping data in sync, and shared ownership of the semantic definitions all become things you have to solve yourself.
5. Why Microsoft Fabric Stands Out Here
Fabric approaches the problem from a different angle.
Rather than beginning from the premise that all enterprise data must be migrated into a graph database, the architecture can instead start from the premise that enterprise data stays where it lives, in OneLake, and semantic and relationship intelligence gets layered on top of it.
In diagram form:
Fabric IQ
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Semantic Model Ontology Graph
│ │ │
trusted metrics business meaning traversal
│ │ │
└─────────────────┼──────────────────┘
│
OneLake
Microsoft draws a clear line between these responsibilities: semantic models supply trusted KPIs and analytical structures, the ontology supplies a shared business vocabulary, the graph handles traversal across connected data, and data or operations agents supply intelligent interaction and action built on top of that context.
That separation of concerns matters architecturally.
6. Semantic Model, Ontology, and Graph Are Three Different Things
These terms often get used as if they were synonyms. They are not.
A useful way to think about it:
DATA
"What happened?"
│
▼
SEMANTIC MODEL
"How should it be measured?"
│
▼
ONTOLOGY
"What does it mean?"
│
▼
GRAPH
"How is everything connected?"
│
▼
AGENT
"What should I investigate or do?"
A Power BI semantic model might define measures like:
Total Revenue
Average Order Value
Customer Count
Revenue by Segment
An ontology might define entities and relationships such as:
Customer
Product
Customer ── PURCHASES ──> Product
The graph is what actually instantiates and traverses those connections:
Customer A
│
├── PURCHASES → Laptop
│
├── PURCHASES → Monitor
│
└── PURCHASES → Dock
The data agent then surfaces all of that intelligence through natural-language interaction.
Fabric also lets you derive an ontology directly from an existing semantic model: tables turn into entity types, columns turn into properties, and the relationships already defined in the semantic model become ontology relationships.
7. Building It: A Minimal Sales Data Product
To keep the focus on architecture rather than data engineering, the example deliberately stays simple.
Only two source tables are used:
NP_SalesDataProduct_LH
customers
──────────────
CustomerId
CustomerName
Segment
City
State
Country
sales
──────────────
OrderId
OrderDate
CustomerId
ProductName
ProductCategory
Quantity
UnitPrice
DiscountPct
Revenue
SalesChannel
The relationship between them is straightforward:
customers.CustomerId
1
│
*
sales.CustomerId
This is enough to walk through the full architecture without letting modeling complexity get in the way of the underlying lesson.
8. Step 1 — Create the Fabric Data Product
The two CSV files are loaded into a Fabric Lakehouse:
NP_SalesDataProduct_LH
│
├── Tables
│ └── dbo
│ ├── customers
│ └── sales
│
└── Files
├── customers.csv
└── sales.csv
[Insert screenshot: Lakehouse showing customers and sales]
At this stage you already have a functioning Fabric Data Agent.
It can answer questions like what total revenue is, which product categories generate the most revenue, and how revenue breaks down by customer segment.
But something worth noticing is happening under the hood.
With no additional semantics defined, the agent has to infer the join itself:
customers.CustomerId
=
sales.CustomerId
and it also has to infer that:
Revenue → SUM(Revenue)
That gives you a baseline to compare against.
9. Step 2 — Add the Semantic Model
Next you introduce the analytical contract.
Customer
1
│
*
Sales
with governed measures such as:
Total Revenue =
SUM(sales[Revenue])
and:
Total Orders =
DISTINCTCOUNT(sales[OrderId])
At this point the agent no longer has to guess what "Total Revenue" means.
That definition belongs to the semantic layer.
This points to an important principle for enterprise agents:
Agents should consume governed metrics rather than reconstructing enterprise calculations from raw columns every time a question comes in.
10. Step 3 — Add the Ontology
From here you shift from analytical definitions to business-level meaning.
The ontology in this exercise defines just two entity types:
Customer
Product
Customer maps to:
customers.CustomerId
customers.CustomerName
customers.Segment
customers.City
customers.State
customers.Country
using:
KEY = CustomerId
Product, meanwhile, is derived straight from the existing sales table:
sales.ProductName
sales.ProductCategory
using:
KEY = ProductName
Once again, there was no need to create a separate physical Product table for this to work.
11. Define the Business Relationship
Next, a relationship is added:
Customer
│
│ PURCHASES
▼
Product
The interesting piece here is how the data binding works.
The sales table itself acts as the bridge for this relationship:
Customer.CustomerId
↑
sales.CustomerId
sales.ProductName
↓
Product.ProductName
So a raw sales row like:
sales row:
CustomerId = C001
ProductName = Laptop Pro
turns into:
Customer(C001)
│
│ PURCHASES
▼
Product(Laptop Pro)
This is the moment where a plain relational record turns into something the business actually recognizes as knowledge.
Fabric's ontology model is built specifically for this workflow: you define entity types and their relationships first, then bind those abstract definitions to concrete data sitting in OneLake.
12. What Changes for the Agent?
Take this question:
Which products are purchased by Enterprise customers?
Without an ontology in place, the agent has to reason through something like:
Find customers table
↓
Find Segment
↓
Filter Enterprise
↓
Determine CustomerId join
↓
Join sales
↓
Find ProductName
With the ontology available, the reasoning collapses to:
Customer
│
Segment = Enterprise
│
└── PURCHASES ──> Product
The question maps almost directly onto the model itself.
Microsoft frames this shift as moving agents away from thinking in terms of individual tables and toward a governed view built from entities, relationships, definitions, rules, and source mappings.
13. Step 4 — Build the Fabric Data Agent
The Data Agent is what turns all of this into a natural-language interface:
User
│
▼
NP_Sales_DataAgent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Lakehouse Semantic Model Ontology
│ │ │
raw facts trusted KPIs relationships
│ │ │
└─────────────┼─────────────┘
▼
OneLake
Microsoft describes Fabric Data Agents as a natural-language question-answering layer scoped to a defined data domain, with the ontology supplying the deeper business context those agents draw on.
14. Then Comes the Important Architectural Move: MCP
A Fabric Data Agent isn't required to stay locked inside Fabric.
You can publish it.
Once published, Fabric exposes that agent as a Model Context Protocol server.
Conceptually, the flow looks like this:
Fabric Data Agent
│
│ Publish
▼
MCP Server
│
├── tool description
├── input schema
└── governed execution
At that point, your enterprise data intelligence becomes something reusable — an agent tool other systems can call.
15. Microsoft Foundry Becomes the Orchestration Layer
This unlocks a considerably more interesting architecture.
USER
│
▼
Microsoft Foundry Agent
│
planning / orchestration
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
CRM Tool Search Tool Fabric MCP
│
▼
Fabric Data Agent
│
┌───────────────────┼───────────────┐
▼ ▼ ▼
Semantic Model Ontology Lakehouse
│ │ │
└───────────────────┼───────────────┘
▼
OneLake
The separation of concerns here matters.
The Foundry agent owns workflow reasoning.
The Fabric Data Agent owns data reasoning.
In its current form, Microsoft's Foundry integration lets a Foundry agent discover published Fabric Data Agents via the Fabric IQ / OneLake Catalog and treat them as MCP tools. A single Foundry agent isn't restricted to one domain either — it can pull in and consume several Fabric Data Agents at once.
16. A Working Example
Imagine a user submitting a request to the Foundry agent along these lines: find the customer segment that contributes the largest share of revenue, work out which products are driving that segment's performance, and turn the findings into a recommendation the sales team can act on.
Here's how execution might unfold:
USER
│
▼
Foundry Orchestrator
│
│ "I need enterprise sales intelligence."
│
▼
Fabric Data Agent MCP Tool
│
├── Semantic Model
│ → trusted revenue calculation
│
├── Ontology
│ → Customer → PURCHASES → Product
│
└── Lakehouse
→ transaction data
│
▼
Result:
Enterprise customers generate...
Laptop category contributes...
│
▼
Foundry Agent
│
├── reasoning
├── CRM lookup
├── recommendation generation
└── potentially action
│
▼
Sales recommendation
What matters here isn't that a language model produced a recommendation. What matters is that the recommendation was anchored in a governed business representation, not improvised from raw tables or guessed semantics.
17. MCP Changes the Enterprise Agent Architecture
Without MCP, teams typically end up wiring things like this:
Agent A → custom Fabric integration
Agent B → another custom Fabric integrationAgent C → another SQL implementationAgent D → another Power BI integration
Over time, every single agent accumulates deep, brittle knowledge about the underlying data platform.
With MCP in place, the picture looks different:
Enterprise Agents
┌───────────┼───────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└───────────┼───────────┘
│
MCP Tool
│
▼
Fabric Data Agent
│
▼
Governed Data IQ
The Fabric Data Agent turns into a data intelligence product built for agents to consume, rather than a bespoke integration each team has to rebuild. That's a small-looking but architecturally significant shift.
18. Another Option: Expose the Ontology Directly
There's a second path worth considering.
Instead of routing everything through a Fabric Data Agent, the Fabric Ontology itself can be exposed via MCP to any compatible external agent. Microsoft documents an Ontology MCP server that ships with tools for discovering ontology entity types and running queries against the ontology.
That gives you two distinct patterns:
PATTERN A
External Agent
│
│ MCP
▼
Fabric Data Agent
│
▼
Ontology
versus:
PATTERN B
External Agent
│
│ MCP
▼
Fabric Ontology
Choose the first pattern when you want to lean on Fabric's own conversational and data-agent reasoning layer. Choose the second when the external agent already has its own sophisticated planning logic and just needs more direct access to the enterprise semantic model.
19. Pros and Cons of the Fabric Pattern
Advantages
Centralized semantics. Business definitions live in one governed place instead of being copy-pasted into every prompt.
Built on OneLake. There's no strict requirement to duplicate your entire data estate into a separate graph platform.
Three layers working together. Analytical metrics and relationship-level semantics can coexist across the semantic model, the ontology, and the graph.
Designed for agents. Both Fabric Data Agents and the Ontology layer were built explicitly to act as grounding sources for AI agents.
Open through MCP. The resulting intelligence layer can be consumed by Foundry as well as by custom MCP clients.
Clear separation of concerns.
Fabric → data intelligence
Foundry → orchestration intelligence
That split creates a notably clean boundary at the enterprise level.
20. Tradeoffs
A few important caveats apply.
Much of this is still preview technology. Ontology support, several Fabric IQ and Foundry integrations, and related MCP capabilities remain preview features, so you should check them against Microsoft's current preview terms before relying on them in production.
Ontology governance is real, ongoing work. Once several domains start defining their own Customer, Account, Product, Contract, and similar entities, someone has to own naming, versioning, and cross-domain alignment.
Ontology can't fix bad data. Wrapping elegant business semantics around a low-quality dataset still yields low-quality answers.
Ontology isn't always necessary. For straightforward KPI aggregation, querying the semantic model directly may be simpler and sufficient.
Not every graph use case fits here. Heavy graph algorithms, specialized RDF-style reasoning, or highly custom graph workloads may still call for a dedicated graph platform instead.
That's exactly why a staged decision framework is useful.
21. The Roadmap I Would Use
Rather than launching straight into an enterprise-wide ontology effort, it makes sense to build up in stages.
Phase 1 — Data Products
Sources
↓
OneLake
↓
Domain Data Products
The goal here is establishing trusted, clearly owned domain data.
Phase 2 — Analytical Semantics
Data Product
↓
Semantic Model
↓
Measures / KPIs / Dimensions
This phase defines how the organization measures things.
Phase 3 — Business Semantics
Semantic Models + Data Products
↓
Ontology
↓
Entities / Relationships / Rules
This phase defines what those measured things actually mean.
Phase 4 — Connected Intelligence
Ontology
↓
Graph
↓
Traversal / dependency / impact analysis
At this stage, you bring graph structures into play only where traversing relationships genuinely earns its keep.
Phase 5 — Domain Data Agents
Ontology + Semantic Model + Data
↓
Data Agent
Here you convert that accumulated domain knowledge into something conversational.
Phase 6 — MCP
Data Agent
↓
Publish
↓
MCP
This step converts the conversational product into a capability that other agents can consume.
Phase 7 — Enterprise Agent Orchestration
Foundry Agent
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Sales Data Agent Supply Agent Finance Agent
│ │ │
└──────────────────┼──────────────────┘
│
Fabric IQ
Microsoft is already heading in this direction: Foundry agents can pull from several published Fabric Data Agents through Fabric IQ, with each of those agents exposed as an MCP tool.
Where This Is Going
The larger architectural shift looks like this:
GENERATION 1
LLM + RAG
│
Documents
evolving into:
GENERATION 2
LLM + Tools + Data
│
SQL / APIs / RAG
and eventually into:
GENERATION 3
Agent Systems
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Documents Tools Enterprise IQ
│
┌──────────┼──────────┐
▼ ▼ ▼
Semantics Ontology Graph
│ │ │
└──────────┼──────────┘
▼
Enterprise Data
The edge in this space will increasingly stop being about which model is strongest.
It will instead come from whichever organization has built the richest enterprise context layer for those models to draw on.
Microsoft frames its overall direction as Microsoft IQ, where Fabric IQ supplies context about business entities and data, working alongside Work IQ, Foundry IQ, and Web IQ.
That framing holds up.
An agent can't be trusted to run parts of a business simply because it's good at pulling up documents.
It needs to understand:
What things are.
How they relate to one another.
How the organization actually measures them.
Which definitions carry authority.
What state those things are currently in.
And, ultimately:
What actions make sense given all of that.
Conclusion: From RAG to Enterprise Reasoning
RAG handed enterprise AI a way to reach knowledge.
Tool use handed agents a way to reach systems.
Ontology hands them something else entirely:
meaning.
Once that meaning is layered together with governed metrics, graph relationships, live operational data, and agent orchestration, you end up with a considerably more compelling architecture:
DATA
│
▼
SEMANTICS
│
▼
ONTOLOGY
│
▼
CONNECTED INTELLIGENCE
│
▼
DATA AGENTS
│
▼
MCP
│
▼
ENTERPRISE AGENTS
│
▼
DECISIONS
│
▼
ACTIONS
That, ultimately, is the real value proposition behind ontology-grounded agentic analytics.
It isn't just another chatbot bolted onto a database.
It's an enterprise intelligence architecture in which data products supply the facts, semantic models supply trusted measures, ontologies supply meaning, graphs supply relationships, domain agents supply intelligence, and MCP makes all of that intelligence composable across the wider agent ecosystem.
That combination is what makes the next generation of enterprise AI considerably more interesting to build.