Originally published Nov 5, 2026.
How Do Power BI Semantic Models, Fabric IQ Ontologies, and Agents Work Together?
Key takeaway: Power BI semantic models, Fabric IQ ontologies, and AI agents play different but complementary roles. Semantic models provide trusted analytical logic and metrics, ontologies provide shared business meaning across domains and data sources, and agents use that context to answer questions and take action. Generative BI works best when these layers reinforce one another, not when one is expected to replace the others.
There’s No One Architecture
My most recent article focused on what happens when Power BI Copilot has access to multiple semantic models. In response to the article, a commenter asked an important question:
“Where do ontologies fit?”
Answering this question delivers an important realization to Power BI teams wanting to deploy Generative BI using Microsoft Azure:
There’s no “Generative BI stack to rule them all.”
The Generative BI architecture you choose depends entirely on the experience you want to provide to your business users:
Sometimes they are inside Power BI.
Sometimes they are in Teams talking to an agent.
Sometimes the user is in Microsoft 365 Copilot Chat.
So, your business users will often receive the desired experience via Power BI semantic models - no Fabric IQ ontology required.
Rather than asking where the ontology sits in the architecture (i.e., assuming an ontology is required), I think the better question Power BI teams should ask is:
“When does an ontology enter the architecture, and what role does it play when it does?”
Power BI Semantic Models Still Matter
Architecturally speaking, Power BI semantic models are the trusted analytical layer for many Generative BI scenarios. Semantic models contain dimensions, measures, hierarchies, relationships, business calculations, etc.
Consider a business user asking Copilot the following question:
“What’s gross margin by distributor last quarter?”
If Copilot has access to a well-designed semantic model, the model may already contain everything Copilot requires to answer the question.
In other words, there’s no reason to introduce an ontology simply because AI is involved.
Keeping this front of mind matters because Fabric IQ doesn’t make all those years investing in Power BI semantic models obsolete.
Microsoft continues to position Power BI semantic models as a core part of Fabric IQ. Semantic models provide curated analytical meaning and trusted calculations that Generative BI experiences can reuse.
So, my default position with clients remains:
Start with the Power BI semantic models you already trust.
Next, determine whether the business problem extends beyond them and requires an ontology.
An Ontology Solves a Different Problem
Let me be crystal clear. A Fabric IQ ontology isn't a semantic model the way Power BI teams think of it.
Fabric IQ ontologies model the business in terms of entities, properties, relationships, rules, and metrics with far more detail than a traditional Power BI semantic model.
For example, concepts such as Customer, Product, Order, Shipment, Asset, etc. can be modeled independently of the physical structures (e.g., tables) that store their data.
Ontologies also elevate relationships beyond simple foreign keys into first-class concepts Copilot uses to understand how the business functions.
When modeled correctly, ontologies give Copilot the graph-based structure it needs to understand the business.
This explicit business modeling becomes especially useful when Copilot receives business questions across analytical domains.
Imagine a business user asks Copilot the following question:
“Which high-value customers have delayed shipments involving products that are currently below safety stock?”
This question might involve customer data from a semantic model, orders from a warehouse, shipment status from an operational system, and inventory from another domain.
Power BI teams will often combine all of these data into one large semantic model. But that is not necessarily the best Generative BI architecture.
This is where Fabric IQ ontologies come in.
Fabric IQ ontologies can provide a shared business vocabulary and explicit relationships across concepts that live in different semantic models, warehouses, and IT systems.
Does the Ontology "Sit Above" the Semantic Model?
In short - not necessarily. It’s very tempting for Power BI teams to tell a Generative BI architecture story like this:
Data → Semantic Model → Ontology → AI
However, this is too simplistic and can lead to poor architectural decisions.
Yes, Fabric IQ can generate ontologies from existing Power BI semantic models. This is a useful way for Power BI teams to bootstrap an ontology from data and measures they already trust.
But ontologies can also bind to other supported Fabric data sources.
So, you should think of the architectural relationship more like this:
Power BI semantic models provide trusted analytical semantics.
Fabric IQ ontologies provide shared business context across entities and relationships.
Think of each as a Generative BI architectural layer that can work with the other.
Neither one has to replace the other.
And neither one has to be present in every Generative BI experience.
The User Experience Changes the Architecture
In my experience, many business users don't want to open Power BI just to ask a question. They greatly prefer to work where they already are.
That might be Microsoft 365 Copilot Chat. It might be Teams. It might be a purpose-built agent.
From that perspective, different paths emerge in the Generative BI architecture.
Power BI App-Scoped Copilot
Inside a Power BI workspace app, the experience can be modeled roughly like this:
Business user → App-scoped Copilot → Reports → Semantic models
App-scoped Copilot relies on the reports and semantic models you include in the workspace app.
Using these assets, app-scoped Copilot can identify relevant content, ask clarifying questions, and use the included semantic models when needed.
However, at the time of this writing, Fabric IQ ontologies aren’t supported in the app-scoped Copilot experience.
This experience remains fundamentally a Power BI report-and-semantic-model path.
This greatly raises the requirements for the quality of the Power BI reports and models used.
Microsoft 365 Copilot Chat With Power BI Data
Assume that your users want to move the Generative BI experience outside Power BI. For example, they want to use Microsoft 365 Copilot Chat instead.
Microsoft 365 Copilot Chat can answer your business users’ questions using Power BI reports and semantic models via Fabric IQ.
To be honest, this is a common user experience my clients want.
As hard as it is to believe, most business users don’t love Power BI. 😆
In my experience, business users see Microsoft 365 Copilot Chat as a seamless, productive way to get the answers they need.
So, this experience can be roughly modeled as:
Business user → Microsoft 365 Copilot Chat → Fabric IQ → Power BI semantic model
This is a critical architectural concept for Power BI teams to incorporate in their Generative BI planning.
Power BI can remain the analytical foundation without being the user interface.
For many organizations, that is much closer to the desired end state.
Where Do Ontologies Enter the Experience?
This is where the answer becomes more nuanced. Fabric IQ can expose ontologies to built-in Fabric agents, Copilot Studio and Foundry agents, and custom AI agents or applications.
Notice what’s not listed: Microsoft 365 Copilot Chat.
At the time of this writing, Microsoft 365 Copilot Chat can’t consume a Fabric IQ ontology directly. Instead, ontologies need to be surfaced through an agent, such as one built with Copilot Studio.
By way of comparison, Power BI reports and semantic models can participate directly in Copilot Chat.
In other words, ontology-grounded experiences in Copilot Chat currently require an agent layer, while supported Power BI content does not.
So, this experience can be roughly modeled as:
Business user → Microsoft 365 Copilot / Teams → Agent → Fabric IQ ontology / data agent → enterprise data
In the above experience, the Fabric IQ ontology becomes the agent's grounding layer, and the user will never know the ontology is being used.
For Power BI teams interested in Generative BI, this is an important idea.
Crafting Fabric IQ ontologies is non-trivial work. Work that is invisible to business users.
So, when your desired experience requires an ontology, set delivery expectations (e.g., budget and timelines).
Agents Are the Bridge
For the Power BI teams I help, agents are often the missing piece in architecting their Generative BI experience.
While semantic models and ontologies provide different forms of business meaning, agents provide the user experience that uses that meaning.
To be clear - not every organization needs a custom agent.
For example, Microsoft 365 Copilot Chat can already answer many analytical questions directly from Power BI reports and semantic models.
If that provides the experience business users want, job done.
However, when an experience needs broader business entities, operational relationships, multiple domains, etc., an agent grounded in a Fabric IQ ontology is often what’s needed.
When Is a Semantic Model Enough?
This is one of the most frequent questions I get when I speak to BI leaders about helping them implement Generative BI:
“What can I do with my existing Power BI semantic models?”
It’s the 100% correct question to ask early in a Power BI team’s Generative BI journey, and it's where I spend most of my time with clients right now.
In short, using your existing semantic models may be enough when:
The question is analytical.
Trusted measures already exist.
The relevant data fits naturally within one model.
The required relationships are already represented.
The Power BI semantics provide enough business context.
This can be a bit abstract, so let me cement it with an example question from a business user:
“Which distributors had the lowest gross margin last quarter?”
That is exactly the kind of question a strong semantic model should handle well.
A strong model will have a Distributors table and trusted DAX measures that are well-named and include business-friendly descriptions.
Don’t add the architectural complexity of Fabric IQ ontologies and data agents unless you need it.
When Does an Ontology Become More Valuable?
Start considering Fabric IQ ontologies when your desired user experiences cross multiple semantic boundaries.
For Power BI teams invested in semantic models, a common example is needing multiple semantic models that share overlapping business concepts (e.g., marketing, sales, and finance models will typically overlap).
But it doesn’t stop there. Crossing semantic boundaries also includes:
When operational and analytical systems need to be connected.
Relationships between business entities are central to the question.
The same concepts need to be reused across agents and applications.
Copilot needs to reason in terms of enterprise concepts rather than source-system structures.
This cross-boundary requirement is a different class of Generative BI problem.
It’s no longer about whether or not Copilot can arrive at the right answer.
It becomes whether Copilot understands the important concepts in your business and how they relate to one another in an explicit, unambiguous way.
This is where Fabric IQ ontologies become a necessary layer in your Generative BI architecture.
There Is No Requirement to Use Everything
A big risk for Power BI teams moving into Generative BI is assuming every new Microsoft Azure capability needs to be part of every business user experience.
This is absolutely the wrong way to approach Generative BI using Microsoft Azure.
Instead, start with the desired business user experience:
Do users not want to access Power BI?
What are the questions are they trying to answer?
Can an enriched semantic model answer those questions reliably?
If the answer to that last question is, “Yes!” then starting with Fabric IQ is likely more complexity than you need.
However, if the problem requires shared business concepts and relationships across broader domains, then you’ll need to step up to a Fabric IQ ontology.
When users need that ontology-grounded context through Microsoft 365 Copilot, Teams, or another conversational experience, an agent becomes the bridge.
The Bigger Generative BI Picture
To sum up, all of this is why I see Power BI semantic models and Fabric IQ ontologies as complementary rather than competing technologies.
Semantic models give AI trusted analytical meaning, ontologies give AI broader business context, and agents give users a way to interact with that context via their preferred interface.
Oh, and increasingly, the interface may not be Power BI at all.
That does not diminish the importance of Power BI. It just changes Power BI’s role.
Power BI semantic models become part of the analytical foundation behind Generative BI experiences surfaced through Microsoft 365 Copilot Chat, Teams, agents, and other applications.
Fabric IQ ontologies come in when the business problem requires meaning beyond the boundaries of your semantic models.
An agent becomes the bridge when you need that broader cross-boundary context to provide reliable answers to your business users.
This is how I currently think about the Microsoft Azure Generative BI stack.
Greetings! I’m Dave Langer
Author | Microsoft MVP | LinkedIn Top Voice
I help Power BI teams move past dashboards to Generative BI using Microsoft Fabric and Fabric IQ.
If your organization is serious about enterprise-class conversational analytics, we should talk.