Microsoft Fabric IQ explained: business meaning for agents

Fabric IQ is the part of Microsoft Fabric that teaches AI agents what your data means. Its centre is the ontology: a model of your business (stores, products, freezers, customers), how those things relate, the rules they follow and the metrics you already trust, each bound to the table or semantic model that holds the data. An agent that reads the ontology can answer "which stores had a freezer run warm last week?" in your terms, instead of guessing which of 400 columns means "store". All of it is in preview as of October 2026.

The name covers more than the ontology. Microsoft describes Fabric IQ in 3 layers: OneLake for the data, Power BI semantic models for business intelligence, and ontologies for what it calls operational intelligence. The first 2 already existed. The ontology, the graph built from it and the agents that read it are what's new, and they are what this page is about.

What goes into an ontology

The fastest way to see what an ontology holds is a small one. Take a grocery chain with freezer sensors:

The rule is Microsoft's own example, and it shows what is different here. Rules are not code; the ontology doesn't run them against data or act on them. They are text an agent reads so its answer follows how the business actually works. Metrics are the opposite: the semantic model keeps the DAX, and the ontology only points at it, so an agent asking for revenue can recognize and use the defined measure instead of writing its own SUM.

The newer ontology model also allows entity types with no key, namespaces for when 2 domains both have a "Customer", and inheritance, so a Walk-in Freezer can extend Freezer.

The data does not move

An ontology is a semantic layer with relationships and rules on top, and like a semantic layer it stores definitions, not data. Microsoft is explicit that it "isn't itself a general-purpose data-query engine". Each entity type is bound to a source, and a question runs against that source:

• lakehouse tables (managed Delta tables), eventhouses and KQL databases, warehouses, SQL databases and mirrored databases
• Power BI semantic models
• data outside Fabric reached through OneLake shortcuts, referenced in place with no pipeline

Security follows the data. Building and querying an ontology respects OneLake security and the row, object and column-level security of the source, and the ontology agent acts as the person using it, so a Viewer gets read-only answers and only what their own access allows.

4 ways to build one

From a semantic model. Open a Power BI semantic model and press Generate Ontology. Tables become entity types, the model's relationships become relationship types and its DAX measures become metrics. You need Read and Build permission on the model. This is the quickest start if your business logic already lives in Power BI. One catch decides whether it works: a model in Import mode generates the ontology but leaves every entity type with no data bound. Microsoft's own fix is to change the model's mode and generate again.

With the ontology agent. Start an empty ontology and choose Start with Ontology agent. It looks through the workspace, samples a few rows of each table, drafts entity types, relationships and bindings, validates the draft and shows it on the canvas. Nothing is written until you switch it from Plan mode (the default, read-only) to Act mode. You can attach up to 10 files of 5 MB each, such as a data dictionary, and it uses them for names and relationships. For now it is also the only way to add a second semantic model to an existing ontology. Microsoft's advice on preparing for it is worth following anyway: move unrelated items out of the workspace, and give tables and columns clear names, and time-series data a clear UTC timestamp column.

From an open standard. Import RDF, Turtle or OWL into an empty ontology, and export as RDF or Turtle. That matters if you already keep a domain model in a knowledge graph tool, or want one that outlives Fabric.

By hand. Add entity types, bind each to a table and draw relationships in the editor.

In practice these mix: generate from a semantic model, then ask the agent to add the eventhouse that holds the sensor readings.

Which agents can read it

An ontology on its own answers nothing. Six kinds of agent can use one:

The ontology agent picks its query language by binding: KQL for an eventhouse, SQL for a lakehouse, DAX for a semantic model, and GQL (graph query language) when the question follows relationships. That last one is why the graph exists.

The MCP route is the one that reaches outside Microsoft. The server address is built from 2 IDs in the ontology's own URL:

https://api.fabric.microsoft.com/v1/mcp/dataPlane/workspaces/<workspace-ID>/items/<ontology-item-ID>/ontologyEndpoint

Add it as an HTTP server in any MCP client and sign in with your Fabric credentials. It needs a paid F2 capacity or larger (or Power BI Premium P1 or larger with Fabric turned on), so the free trial won't do. A service principal can't connect yet, which rules out unattended agents for now. Before you point an outside agent at business data, check the server the way you would any other; we compare it with the other platforms' servers in MCP servers for data platforms.

The graph is opt-in, and it costs capacity

Every ontology can be turned into a graph in Fabric: each entity becomes a node and each relationship an edge, so a question like "which products were in any freezer that a store reported warm, and which suppliers sent them?" is a walk along edges instead of a 4-table join. You don't have to build it. Microsoft's own advice is to materialize only when you have relationship-heavy questions, and only the entity types those questions need.

It is a copy, with the costs of one. Materializing loads the bound data and "might take several minutes to several hours". After that it does not follow the source: source changes reach the graph only when a new ingestion runs: a refresh by hand or on a schedule, or a re-ingestion after you change the ontology's schema, and those refreshes are billed to your Fabric capacity. If the ontology canvas stops loading with a message that capacity has "exceeded its limits", Microsoft's first suggestion is to cut back the graph's refresh schedule. Fabric's capacity billing, smoothing and throttling are explained in our Microsoft Fabric vs Databricks comparison.

What doesn't work yet

Most of the preview's rough edges come from one fact: semantic models, the graph and the data agent don't all accept the same sources. Check this before you pick how to build:

So the quickest way in, generating from Power BI, is also the one the graph and the data agent can't use. If either matters to you, bind entity types to lakehouse tables instead, or to tables mirrored into OneLake.

The smaller traps are in the troubleshooting page:

• Decimal columns come back as nulls in graph queries. Graph has no Decimal type; cast to Double.
• Delta column mapping breaks the graph, and Fabric turns it on by itself for tables whose column names have a space, comma, semicolon, brackets or =, and for the tables behind Import-mode semantic models.
• Duplicate relationship names break data agent queries; make each one unique.
• Aggregations can come out wrong in the data agent; adding Support group by in GQL to its instructions enables better aggregation.
• An entity type bound to 2 tables can't go into the graph.
• The ontology agent forgets the conversation when you refresh the page, and keeps its data for up to 2 days.

Two tenant settings must be on before anyone can create an ontology: Users can create Fabric items and Users can create ontology (preview) items. If your ontology was made before the current editor, copy it to the new experience; the old one retires on 31 January 2027.

Fabric IQ or Databricks Genie Ontology?

Genie Ontology is mostly about which definition wins: metric views and domains you write in Unity Catalog, plus snippets Genie learns from your dashboards and queries, ranked by authority so "revenue" means one thing. A Fabric ontology is about what things exist and how they connect: entity types, relationships and rules, which a graph can walk and an operations agent can watch. Fabric takes its numbers from Power BI measures, much as Genie takes them from metric views.

If you run both platforms, that difference is a fair guide to where each piece of meaning belongs: certified numbers in the semantic model or metric view, and the map of things and rules in the ontology.

Should you build one now?

Build one if your agents keep getting the joins wrong, or if 2 teams use the same word for different things and you're tired of fixing the prompts. Start small: one domain, generated from a semantic model that isn't in Import mode, then tested with the ontology agent's Test the ontology suggestion, which writes 5 questions and answers them from the bound data.

Hold off on two things until general availability: an unattended agent through MCP (no service principals yet), and any design that relies on semantic-model bindings in the graph or a data agent. Both are current preview limitations; we'll update this page when they do.