Fabric IQ Explained: Ontology, Data Agents and What’s Actually GA

Last updated: November 3, 2026

By ZapAI Team

Fabric IQ is the business-context layer that lets AI agents read OneLake data in business terms instead of table names. As of November 2026, data agents, graph and operations agents are generally available, while the ontology item, its MCP server and the Foundry IQ connection are still preview. Our Microsoft Fabric consulting team suggests a simple order. Ship a data agent over one trusted semantic model now, then pilot an ontology on one domain.

Picture a hypothetical. You ask an AI agent to count the refrigerated shipments that broke temperature limits last week. It sees a table called fact_shipment_evt and a column called tmp_max, but it has no idea that your operations team only counts a breach after a reading stays above the limit for 30 minutes straight. So it guesses. Confidently.

That gap is what Fabric IQ exists to close. Microsoft announced it as generally available at Build in June 2026. But the piece most people picture when they hear Fabric IQ, the ontology, still carries a preview banner. Third-party posts call the whole thing GA. Microsoft Learn still labels the workload preview. Nobody agrees.

This guide sorts it out. We cover each piece, a dated GA versus preview table, the data agent caps, what it costs in Fabric capacity, and when a mid-market company should actually start spending time on it. Need the platform basics first? Our Microsoft Fabric primer covers OneLake and the core workloads, so we won’t repeat them here. Every product fact below was checked against Microsoft Learn and Microsoft’s Build announcement on November 3, 2026.

What Is Fabric IQ?

Fabric IQ is the part of Microsoft Fabric that describes your business, not just your tables. It sits on OneLake and uses two core items, the ontology and the Power BI semantic model, to give agents shared definitions, relationships, rules and metrics.

Microsoft’s Fabric IQ overview places it inside a bigger umbrella called Microsoft IQ. Work IQ brings context on how employees work in Microsoft 365. Foundry IQ brings policies and documents. Web IQ brings the web. Fabric IQ’s slice is business entities and the data behind them, things like Customer, Shipment and Asset.

In Fabric itself, IQ is a workload, which is Microsoft’s word for a group of related items. Six items sit in it. Ontology, semantic model, planning, graph, data agent and operations agent. Several are shared with other workloads, so graph and operations agents also appear under Real-Time Intelligence, and data agents also appear under Data Science, which is why you’ll find the same item documented in three different corners of Learn.

So it’s a bundle. Not one product.

OneLake is the floor under all of it. Learn says every item in the workload relies on OneLake tables, and data stored elsewhere comes in through shortcuts or mirroring. That’s why a clean lakehouse matters more here than any AI feature, and why our Fabric lakehouse services come up in almost every Fabric IQ conversation we have, usually before anyone mentions an agent.

What’s Actually GA in Fabric IQ as of November 2026?

Data agents, graph, operations agents and the Fabric IQ plugin in Copilot Cowork are generally available. The ontology item, its MCP server, the Foundry IQ ontology knowledge source and the Copilot Studio data agent connection are still preview.

Blame one blog post for the confusion. In Microsoft’s Build 2026 announcement from June 2, 2026, Arun Ulag called Fabric IQ, graph and operations agents generally available. The same post said ontologies were “expected to be generally available in the coming months.” Five months later, the ontology page on Learn still says preview, and the workload overview, last updated in late September, still titles the whole workload IQ (preview) at the top of its item table. Annoying, but true.

Our read? Treat anything ontology-shaped as preview until Learn drops the banner. Microsoft’s own preview notice on the Copilot Studio ontology page says preview features have restricted functionality and aren’t meant for production use. That’s not legal fine print you can wave away when a regulator or an auditor asks why an agent gave a wrong number, because a preview label is exactly the thing they’ll point at.

How Does the Fabric Ontology Work?

An ontology in Fabric defines entity types like Customer or Machine, their properties, relationships, rules and metrics, then binds them to live Fabric data. It doesn’t copy that data. Agents read the definitions and query the bound sources directly.

Per the ontology overview on Learn, bindings during preview can point at semantic models, lakehouses, eventhouses, warehouses, SQL databases, mirrored databases, and OneLake shortcuts, views and materialized views. The ontology is a virtual layer. Source data stays where it lives.

Four building blocks matter most.

• Entity types and properties, such as a Customer with an email address or a Machine with an operating state.
• Relationships. Customer places Order. Machine belongs to Production Line.
• Metrics come straight from DAX measures in a source semantic model, and the semantic model keeps ownership of the formula.
• Rules, written in plain language and linked to entities, so every agent reads the same business logic instead of each prompt carrying its own copy.

You can build an ontology from scratch, generate one from an existing semantic model, let the built-in ontology agent draft it, or import RDF, Turtle or OWL definitions that your data architects may already maintain in another tool. The ontology agent works proposal-first. It suggests changes and you approve them.

Graph is optional now. An ontology-derived graph schema doesn’t load instance data by default, and you opt in to materializing it only when the relationship path itself is the question, such as tracing a part through suppliers to a recall.

Security follows the data. Ontology authoring and querying respect OneLake security plus row-level, object-level and column-level security on the bound sources. Good.

One date to calendar. The old ontology experience retires on January 31, 2027. Migrating creates a separate copy, so any agents, dashboards and Activator alerts wired to the old item have to be reconnected or rebuilt by hand. If your team built a pilot early in 2026, that’s a real task, not a checkbox.

Fabric IQ vs Semantic Model, Which One Do You Need?

Usually both. A semantic model holds trusted measures for reports. An ontology wraps those measures in business entities, relationships and rules so agents and operational apps can reason across domains, including real-time data from eventhouses.

Here’s the part competitors skip. The ontology is only as good as the semantic model you generate it from. If Finance and Sales each have a different Revenue measure, the ontology inherits both, and now every agent you ground on it inherits the same argument your finance and sales leaders have been having in monthly reviews for years. In our Fabric projects, the first blocker on any AI-over-data request is almost never the AI. It’s measures nobody agrees on.

Fix that first. Our guide to Copilot in Power BI covers how to prep a semantic model for AI questions, and the same prep work carries straight into an ontology later.

What Do Fabric Data Agents Do, and What Are Their Limits?

Think of a Fabric data agent as a configurable Q&A agent over up to five Fabric sources. It turns plain-English questions into SQL, DAX or KQL, runs them read-only under the asking user’s permissions, and returns at most 25 rows and 25 columns.

Data agents are the GA piece you can put in front of users today. Microsoft’s data agent concepts page lists sources as lakehouses, warehouses, KQL databases, Power BI semantic models, ontologies and Microsoft Graph. You add instructions and example queries to steer it. Git integration and deployment pipelines handle promotion from dev to production, which matters more than it sounds once three teams start editing the same agent’s instructions.

Specific limits apply. Read them before you promise anything.

• Five data sources per agent, in any mix.
• 25 rows and 25 columns. Ask for every row from this year and you still get 25.
• Read-only. Always.
• English only for questions, instructions and example queries.
• Got PDFs or Word files? Not supported. Tables only.
• If the source’s capacity sits in a different region from the agent’s capacity, the query fails.
• Up to 100 example queries per source, though example queries aren’t supported for semantic model sources at all.
• You can’t change the underlying model.

Those caps tell you what it’s for. Conversational answers. Not exports.

Security is the good news. The agent runs as the person asking, so row-level and column-level security still apply, and sharing an agent doesn’t grant anyone access to the data behind it. Microsoft Purview data loss prevention policies on the sources can block queries outright, which means a well-governed tenant may see an agent give incomplete answers and need to explain why. Building agents that act, not just answer, is a different job, and it’s what our AI agent development team handles when a read-only Q&A agent isn’t enough.

Where Do Operations Agents and Graph Fit?

Operations agents watch live data in an eventhouse or ontology, run each rule’s query every 5 minutes, and message people in Teams or take configured actions. Graph stores and traverses relationships for multihop questions like dependency chains and shortest paths.

Learn’s operations agent documentation describes a playbook the agent builds from your instructions, with rules you can inspect as real KQL or graph queries. Conditions come in two flavors. State conditions fire while a value stays past a threshold. Transition conditions fire once, when it crosses.

Now the governance catch. Each operations agent gets its own Microsoft Entra Agent ID, which is great for auditing. But it runs with the delegated permissions of whoever created it. When someone approves a recommended action, the action executes with the creator’s permissions, not the approver’s, so an agent built by a power user can do things the person clicking approve never could. So the person who builds the agent matters a lot, and a departing analyst’s agent deserves the same review as a departing analyst’s admin rights. No trial capacities, by the way.

Graph is the quieter GA item. It uses the ISO standard GQL query language and runs directly on OneLake. Per the graph overview, it bills 10 CU-seconds for every second of uptime and provisions at least 100 GB of storage at the OneLake Cache rate. Using graph as a data agent source is still preview.

If your use case is live operational data, start with our Fabric Real-Time Intelligence guide. Operations agents only make sense once events are flowing into an eventhouse reliably.

How Does Fabric IQ Connect to Foundry IQ, Copilot Studio and MCP?

Through six routes. An ontology can feed a Foundry IQ knowledge base or act as an MCP server. A data agent can act as an MCP server or a connected agent in Copilot Studio. Most of these routes are still preview.

First, the naming. Foundry IQ isn’t part of Fabric. The Foundry IQ page describes a managed knowledge layer built on Azure AI Search, with knowledge bases that pull from Blob Storage, SharePoint, OneLake and the web. Think documents and policies. Fabric IQ is entities and numbers.

Microsoft’s Foundry IQ ontology how-to walks through picking Fabric IQ as the knowledge type and selecting an ontology from the OneLake catalog, and it’s blunt that the Foundry project needs the right search role first. Same identity on both sides. Same tenant.

MCP is the route developers will like. The ontology MCP guide builds an endpoint from your workspace and ontology IDs, while the Copilot Studio version uses an Agent 365 endpoint that exposes two tools, list_ontology_entity_types and search_ontology. Two endpoint formats for one preview feature. Don’t hard-code either.

For data agents, the data agent MCP server exposes a single tool per published agent, and it accepts user or service principal tokens, which sidesteps the service principal gap on the ontology side. That makes it the most practical route for a custom app today. It’s the same pattern we covered for the Dataverse MCP server on the Dynamics 365 side.

Copilot Studio is the trickier path. The connected-agent page says a custom agent with a connected Fabric data agent isn’t currently supported in Microsoft 365 Copilot. Teams only, for now. If you’re weighing Copilot Studio against a code-first build for this, our Copilot Studio vs custom AI agents comparison lays out the tradeoffs.

What Does Fabric IQ Cost to Run?

There’s no Fabric IQ SKU. Everything runs on Fabric capacity. Data agents and the ontology MCP server need a paid F2 or higher, or a Power BI Premium P1 with Fabric enabled. Microsoft suggests evaluating the ontology on an F8.

Ontology usage has its own meters, documented on the ontology billing page.

Sizing gets easier with Microsoft’s own examples. A light edit, like adding client and buyer as synonyms for Customer, runs about 0.5 to 1 CU-hours of AI reasoning. Drafting a whole ontology from a workspace, with entities, relationships, measures and business definitions, runs about 20 CU-hours, so a team that regenerates drafts all afternoon will notice it in the Capacity Metrics app. And the ontology UI refreshes its cached definition roughly every 20 minutes while it’s open. Close the tab.

Other licenses stack on top. The Copilot Studio routes need Microsoft 365 Copilot licenses. Copilot Cowork runs on usage-based billing. If agents are part of the plan, our Copilot Studio pricing guide explains how credits get consumed, and our Fabric vs Power BI Premium breakdown covers the F-SKU side.

What Can’t Fabric IQ Do Yet?

It only reasons over data Fabric can reach through OneLake. The ontology isn’t GA, data agents cap answers at 25 by 25 and stay read-only, and several connections lack production status or service principal support.

• OneLake-only scope. Data in Dynamics 365, SAP or an on-premises SQL Server has to arrive through mirroring or shortcuts before Fabric IQ can describe it.
• No GA date for the ontology. Microsoft has said the coming months since June.
• Data agents won’t write, won’t export full datasets, and only officially support English.
• Service principals can’t reach the ontology MCP server yet, which rules out a lot of unattended automation.

That first bullet is the big one for mid-market companies. If half your data still lives in on-premises databases and SaaS apps outside Fabric, Fabric IQ simply can’t see it, and no amount of ontology modeling or prompt tuning will fix that gap. Our Microsoft Fabric migration guide covers how teams get there.

When Should a Company Actually Start with Fabric IQ?

Start now if your data already lives in OneLake and you have one trusted semantic model. Ship a GA data agent on it first, then pilot an ontology on one domain in a separate workspace. Wait if your data isn’t in Fabric yet.

Bias disclosed. We sell Fabric work, so you’d expect us to say start everything today. We won’t.

Good fit now.

• You’re already on paid F capacity, with core data in a lakehouse or warehouse.
• There’s a production semantic model with measures Finance actually signs off on.
• Somebody keeps asking the same 20 questions of the BI team every week. That’s a data agent.
• Operations runs on live events, such as fleet, freezer or machine telemetry, where an operations agent watching thresholds beats a dashboard nobody opens on weekends.

Better to wait.

• Your data is still spread across on-premises SQL Server and spreadsheets.
• Trial capacity only. Operations agents won’t run, and data agents need paid capacity.
• You need production support on the ontology itself this quarter.

In our experience a four-step pilot works well. Pick one domain, like order-to-cash or plant maintenance. Clean the semantic model for that domain until the measures stop starting arguments. Publish a data agent on it and put it in front of 10 to 20 real users. Then, in a separate non-production workspace, generate an ontology from that same semantic model and test it through the ontology agent or MCP, keeping it well away from anything users depend on until Microsoft drops the preview label. Measure what the ontology answers that the data agent couldn’t. If the answer is nothing, you’ve saved yourself a preview dependency. Our lakehouse vs warehouse comparison helps with the foundation choice that comes before step one.

Wrapping Up

Real progress, then. Part of Fabric IQ is production-ready. Data agents, graph, operations agents and the Cowork plugin are GA. The ontology, which is the piece that actually carries business meaning across domains, is still preview, as are most of its MCP and Foundry connections. Start with a data agent over clean measures. Pilot the ontology where it can’t hurt anyone. Re-check after Ignite in late November.

ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm based in Irving, Texas, in the Dallas area, working with US mid-market companies. We help teams get data into OneLake, fix the semantic models agents depend on, and build agents that answer and act. If you want a second opinion on whether Fabric IQ fits your data today, our Fabric services team can review your workspace, capacity and semantic models and tell you where a data agent would pay off first. When agents need to do more than answer, talk to our AI agents practice.

What Data Teams Ask About Fabric IQ

Is Fabric IQ generally available yet?

Fabric IQ vs semantic model, do we have to pick one?

What’s the row limit on a Fabric data agent?

Does Fabric IQ work with data outside OneLake?

So what’s Foundry IQ, and how is it different?

Can we try Fabric IQ on a trial capacity?

Will Ignite 2026 change any of this?