Fabric Ontology and Data Agents: Where Business Meaning Should Live

"Which customers are overdue?" looks like the easiest question a credit controller could type into a data agent. Now imagine a typical mid-market setup: the lakehouse has a due date column, the semantic model has an overdue measure that leaves out disputed invoices, and the collections team works with a grace period nobody wrote down. The agent has to pick one reading of "overdue" before it writes a single line of SQL, and nothing in the table schema tells it which.

Most of what Microsoft shipped for Fabric IQ around FabCon Europe is aimed at that moment of interpretation. The ontology item got a rebuilt authoring experience, data agents can now take an ontology as a context source, and there are new places to put instructions. The useful question for a finance or BI lead is where each definition belongs.

What a data agent does with a question

A Fabric data agent is a generally available item that answers plain-language questions over data in OneLake. According to the documentation it works in a fixed sequence: it checks the question against security and responsible AI policies, reads the schema of its configured sources using the asking user's credentials, decides which source fits, and then calls the matching tool to generate a query. That means natural language to SQL for lakehouses and warehouses, to DAX for semantic models, and to KQL for KQL databases. The query is validated, executed, and turned into an answer.

Two design choices are worth knowing before any of the new features. The agent is strictly read-only, and it runs with the permissions of the person asking, so row-level and column-level security continue to apply. An agent can hold up to five data sources in any combination, and authors steer it with instructions and example question-query pairs.

Everything in that pipeline depends on the step where the agent maps business words onto tables and columns. Until now the only help it had was the schema and whatever the author typed into an instructions box.

What the ontology adds

The ontology item, still in preview, is Microsoft's answer: a shared, machine-readable description of the business. It holds entity types (Customer, Invoice, Cost Centre), their properties, the relationships between them, metrics, natural-language rules, and data bindings that say which source supplies what. The documentation is careful on one point that is easy to miss in the keynote framing. An ontology stores definitions and bindings and is not a general-purpose query engine. Data stays in the system that owns it, and whichever experience consumes the ontology runs its queries against the bound source.

With the new "ontology as context source" preview, a data agent can use an ontology's entities, relationships, definitions, mappings, synonyms and source bindings when it generates SQL, KQL or DAX. In this first release the ontology is a read-only context source, and Microsoft says authors get clearer visibility into the associated data sources, the run steps and the generated queries. That last part matters as much as the accuracy claim, because a query you can read is a query you can review.

A few of the authoring changes remove old objections. Entity types no longer need a unique key in the source, relationships can be defined without a dedicated join table, and bindings now cover semantic models, lakehouses, eventhouses, warehouses, SQL databases and mirrored databases. Building a graph from the ontology has become optional: the schema graph does not load instance data unless you opt in for questions where the path between entities is the point.

Measures stay where they are

The part most relevant to an existing Power BI estate is that an ontology can be generated from a semantic model. Tables and relationships become the starting structure, and DAX measures appear in the ontology as metrics attached to the relevant entities. The semantic model remains the owner of the DAX expression. The ontology keeps the metric's source and business context, so an agent can recognise the organisation's own calculation and use it instead of composing a new one.

For anyone who has spent years getting a margin or an allocation measure agreed, this is the reassuring design. In the activity-based expense allocation I built in Power BI and DAX at Morgan Stanley, the value was that every region and business unit read the same number from the same definition. A second semantic layer that asked us to restate those formulas would have been a step backwards. The ontology approach treats the model as the calculation authority and adds what a model does not express well: which things exist, how they connect across sources, and what the words mean.

Rules in plain language

Ontology authors can now attach natural-language rules to entity types, relationships and properties. Microsoft's examples come from retail, such as a store inventory position being "at risk" when projected on-hand stock falls below safety stock before the next scheduled delivery. A finance equivalent might read: "An invoice is overdue when it is unpaid past its due date and is not flagged as disputed", or "A variance is material when it exceeds the threshold set for its account group".

One caveat belongs next to every rule you write. The documentation describes rules as context that supported consumers can use during reasoning. That is guidance for an agent, which is different from a constraint the platform enforces. A rule tells the agent what "overdue" means; it does not guarantee the generated query applied it. Which is why the visible run steps and queries are the control, and why evaluation questions with known answers are still needed.

Four places to put a definition

Topics are the other new piece here. They accept up to one million characters of guidance per supported data source, organised into sections, and the agent retrieves only the sections relevant to the question before handing them to the SQL generator. Data source instructions, by contrast, are sent every time the source is used, so Microsoft positions them for rules that have no exceptions.

The trap is using the lower rows for what belongs in the upper ones. A definition typed into one agent's instructions helps that agent only. The same definition in the ontology is available to every agent, dashboard and tool that reads it, and it has version history: authors can create named versions and restore an earlier one.

Reaching the same context from outside Fabric

A published data agent can be consumed as an MCP server with a single tool, and that server now supports MCP Tasks, so a long-running question does not depend on the connection staying open. The Fabric IQ MCP server reached general availability with support for Power BI reports and semantic models, including running DAX against models the user is authorised for, and Microsoft says ontologies and data agents will follow. The ontology also has its own MCP tools for definition management and querying.

Access control follows the data. Ontology authoring and querying respect OneLake security and source-enforced row-level, object-level and column-level security. On the Power BI side, semantic model editors got a new setting that blocks read-only users from reaching a model through Copilot, data agents and Microsoft's MCP servers. It is enabled by default to preserve existing behaviour, so restricting AI access is an explicit decision per model.

What to check before relying on it

Preview status applies to the ontology item, to ontology as a context source, and to Topics. A few documented limits will shape a pilot. Data agents do not currently support non-English languages, for questions or for instructions. The standard runtime returns at most 25 rows, with up to 1,000 available on the preview runtime. An agent cannot query a source whose capacity sits in a different region from its own. And if you built an ontology in the earlier experience, it has to be copied into the new one, with rules recreated and downstream consumers reconnected; the old experience retires on 31 January 2027.

On the Fabric lakehouse work I do now, the governance effort goes into row-level security and data quality standards well before anyone asks an AI a question. The ontology does not shorten that work. It gives the result of it a place where agents can read it.

A reasonable pilot is narrow: generate an ontology from one well-governed semantic model, keep a handful of entities, write down the three definitions people argue about most, and run the same twenty questions with and without the ontology attached. Microsoft's announcement, Trusted AI starts with Microsoft Fabric, Real-Time Intelligence, and IQ, lists the full set of ontology changes, and the ontology overview and data agent concepts pages on Microsoft Learn carry the limits in detail.