Note: The Fabric Ontology is currently in preview as part of the Fabric IQ workload. Features and behaviour may change before general availability.
I have been spending a little time with the Microsoft Fabric data agent documentation lately, and one pattern keeps showing up, and it is not just in the official guidance but in community posts from people who have actually tried to deploy these things: the demo runs beautifully. The AI answers questions in plain English, leadership gets excited, the pilot gets approved. Then it hits production. Real users send real questions. The answers start drifting. Numbers that should match do not. The same question returns different results on different days. Trust evaporates faster than it was built.
And almost every time, the root cause is the same thing: the semantic foundation was not solid enough before anyone pointed an agent at it.
That is exactly the problem the Fabric Ontology is designed to address. It is the piece I think most teams will underestimate right up until the moment they need it.
Why the Data Agent Gets It Wrong
Generative AI is genuinely good at working with language and meaning. What it cannot do is fill in documentation that was never written.
Most enterprise databases were built for systems, not for consumption. Column names follow technical conventions an engineer settled on years ago. Business logic lives in a stored procedure nobody has touched since SQL Server 2014. Which customer table is the authoritative customer table? Documented nowhere. The abbreviation cust_rev_ytd_adj was obvious to the person who named it. To everyone else, including an AI agent, it is a puzzle.
When you connect an agent to that data and ask it to answer business questions, you are asking it to decode a language it was never given a dictionary for. It is not going to find meaning that was never documented. Someone has to build that foundation deliberately, before the agent gets anywhere near it.
This is not a new problem. It is the same problem that made undocumented semantic models painful for analysts, made onboarding new BI developers slow, and made “what does ‘active customer’ mean?” a recurring meeting agenda item. The AI just made it impossible to paper over.
What the Fabric Ontology Actually Is
The Fabric Ontology operates above the table and column level, at the concept level, the level where business people actually think and where agreements actually need to live.
Three building blocks:
Entity types are the real-world objects your business runs on. Customer, Order, Product, Shipment, Store. Defined once, with a stable name, description, and identifiers. Not four slightly different customer tables with different primary keys depending on which source system populated them first.
Properties are named, typed facts about an entity. Instead of a column called cust_rev_ytd_adj, you publish a Customer property called Adjusted Year-to-Date Revenue with a declared unit, a data type, and a binding to the underlying source column. Something a new analyst can understand without asking someone who remembers the original intent. Something an AI agent can reason about without guessing.
Relationships are explicit, directional, typed links between entities with cardinality rules. Customer places Order. Order contains Product. Shipment originates from Plant. Made reusable and visible, rather than buried in join logic spread across three different pipelines and a Power BI measure that no one wants to open.
Those concept definitions then bind to your actual data in OneLake: lakehouse tables, Eventhouse streams, Power BI semantic models. The data bindings handle schema drift, enforce data quality checks, and track provenance at the concept layer.
The result: a shared vocabulary that both people and AI agents can reason over. When an agent is grounded in a well-defined ontology, it is not reverse-engineering meaning from raw tables. It is working from a context that someone owns and maintains.
The Ontology Graph: Relationships as Queryable Data
The Fabric Ontology also builds an ontology graph from your data bindings and relationship definitions: a queryable instance graph where entity instances are nodes and relationships are edges, each carrying metadata and data source lineage, refreshed on a schedule.
For anyone who has spent time making implicit relationships explicit and queryable, this is worth understanding. Context that previously only existed as join logic, tracing which customers are tied to which orders and which products trace back to which suppliers, becomes something you can traverse, analyze, and govern. Path finding, centrality analysis, community detection: graph algorithms applied to your actual business data.
On top of that sits a Natural Language to Ontology (NL2Ontology) query layer that converts plain-language questions into structured queries across your bound sources, routing automatically to GQL for graph queries or KQL for Eventhouse. Not a best-effort guess at what a column might mean. Consistent answers that follow the definitions you published in your ontology.
Three Things That Actually Matter Before You Build the Agent
I have not shipped a production data agent grounded in a Fabric Ontology end-to-end yet. The feature is still in preview and I am still working through it. But the guidance is consistent enough across documentation and early community experience that I think these three things are worth naming before you start.
Build the semantic foundation first
This is the step that gets rushed. The agent is only as reliable as the context it has to work with. If your semantic model has undocumented measures, ambiguous column names, and definitions that three different teams would answer three different ways, an ontology built on top of that inherits all of it.
Before connecting an agent to your data:
- Audit your semantic model. Are measure names self-explanatory? Are the terms your business uses defined anywhere?
- Generate a Fabric Ontology from your semantic model as a starting point. Fabric can auto-generate one to give you something concrete to refine, rather than starting from a blank canvas.
- Write descriptions for the columns and measures that currently only make sense to the person who created them.
- Resolve the definitions that lack consensus before rollout, not after. “What counts as an active customer?” is not a technical question. It is a business alignment question. It needs an answer before the agent encounters it at 9am from a business stakeholder.
Keep each agent’s scope narrow
The temptation is to build one agent that answers everything. It almost always underperforms. The more data an agent has to reason over per question, the harder it is for it to return consistent answers.
A sales agent. An inventory agent. A finance agent. Each one is easier to configure, easier to test, and easier for the people who rely on it to trust, because the scope is legible and the owner is clear.
Start with one domain. The one where trust matters most and the semantic definitions are clearest. Do it properly. Let that one earn credibility before expanding.
Write the instructions like you are briefing a smart new colleague
Data agents are probabilistic: they use statistical reasoning to determine the most likely answer. Business users expect deterministic behavior, meaning the same question should return the same answer every time. Detailed agent instructions are the primary lever for closing that gap.
Think of it as the standing brief you would write for a new analyst on their first day: here is what matters, here is how we define things, here is what belongs out of scope, and here is what to do when a question is ambiguous.
For your most critical business questions, Fabric data agents support sample questions with pre-defined SQL, DAX, or KQL behind them, removing the probabilistic element entirely for those specific scenarios. Use it. Treat the instructions as a living document and update them as you learn how people in your organization actually phrase questions.
Where I Am On This
The hard part of building reliable AI over enterprise data is not the model. It is the semantic gap between raw data structures and the meaning business users expect the model to already know. The Fabric Ontology looks like the most direct thing Microsoft has shipped to address that gap at the platform level. That is what makes it worth paying attention to, even while it is in preview.
I am still early in exploring this and plan to dig further as it moves toward GA. If you have already started building with it, whether you found a workflow that clicked, hit a wall, or worked around something unexpected, I would genuinely like to hear about it in the comments.
