What Fabric IQ Is and Why It Matters#
Fabric IQ is part of Microsoft IQ, a broader enterprise intelligence layer that Microsoft is building across its platforms. Microsoft IQ also includes Work IQ for employee work context, Foundry IQ for organizational policy and document context, and Web IQ for web context — and inside that layer, Fabric IQ's specific job is supplying business-entity and data context [S1]. In practical terms, Fabric IQ is the piece responsible for making sure that when an AI agent or a report says "customer" or "shipment," it means the same thing everywhere.
That matters because the alternative is expensive and fragile. Without a shared layer of business meaning sitting on top of raw tables, every AI system that needs to answer a business question has to have that translation done manually, by a domain expert, from schemas into business concepts — and Fabric IQ's own positioning frames that gap as making AI systems unfit for high-stakes decisions [S1]. Fabric IQ exists to close that gap once, centrally, rather than leaving every report and every agent to redo the translation on its own.
Fabric IQ delivers this through three layers of business context — unified data, business intelligence, and operational intelligence — and it delivers all three through a small set of Fabric items anchored by two core ones: the ontology (preview) and the semantic model [S1]. As the surrounding IQ workload has matured, that item set has grown to include a planning experience and an operations agent, both covered later in this article, alongside a data agent and a graph store.
Without a shared ontology layer, AI systems are described as unfit for high-stakes decisions [S1].
The Two Core Items: Semantic Model and Ontology#
Fabric IQ doesn't start from zero. One of its two core items is the semantic model — the same curated analytics layer Power BI has used for years to define measures, relationships, and business-friendly names over raw data. The second, newer item is the ontology (preview), which adds a layer of business vocabulary, relationships, rules, and actions on top [S1].
An ontology item defines core business entities, relationships, properties, rules, and actions, and it exposes a natural-language query layer — NL2Ontology — that converts a plain-English business question into a structured query against those entities [S1]. Where a semantic model tells you how to calculate "total revenue," an ontology tells you what a "customer," an "order," and a "shipment" are, how they relate to each other, and what rules and actions apply to them.
Crucially, an ontology does not have to be built from scratch. Ontologies in Fabric IQ can be generated or aligned directly from Power BI semantic models that are already in production, which means business terms and KPIs that a BI team has already spent years refining can carry straight through into the ontology instead of being redefined per experience [S1]. For organizations with a mature Power BI estate, this is the on-ramp: the ontology bootstraps from what already exists rather than starting a parallel modeling effort.
Why bootstrapping from semantic models matters#
The rule: when standing up an ontology, generate or align it from existing production semantic models rather than authoring business definitions a second time. The why: it keeps business terms and KPIs consistent across reports, agents, and applications instead of letting each surface define "customer" or "active subscription" its own way [S1].
# Wrong: ontology authored independently of existing BI assets
Ontology.Customer.definition = "however the ontology author defines it"
SemanticModel.Customer.definition = "however the original BI team defined it"
# -> two different answers to "who counts as a customer"
# Right: ontology generated/aligned from the existing semantic model
Ontology.Customer = align_from(SemanticModel.Customer)
# -> one definition, reused everywhere
Inference: the pseudocode above illustrates the pattern the claim describes (align, don't redefine); it is not a literal documented API — the underlying practice is grounded in [S1].
What an ontology is actually made of#
An ontology is composed of entity types (the things), properties (their facts), and relationships (how those things connect), together with constraints and rules that keep the representation consistent across teams [S3]. An entity type itself is a reusable logical model of a real-world concept — a standardized name, description, identifiers, properties, and constraints — deliberately elevated above any single table so that inconsistent per-source column definitions don't fragment what "customer" means across systems [S3].
When that entity type is populated from real data, the result is an entity instance: a concrete, timestamped occurrence of the entity type, populated from a data binding, that retains which source created it and when it was true — turning a raw row into a standardized, provenance-tracked business object [S3]. Relationships between entities are typed, directional links that can carry their own attributes (distance, confidence, effective-at) and cardinality rules, which is what makes traversal and dependency analysis possible without anyone hand-writing join logic [S3].
The IQ Workload: Ontology, Semantic Model, Planning, Graph, and Two Agents#
Ontology and semantic model are the two foundational items, but the IQ (preview) workload as a whole now groups several more items together: Plan (preview) for planning and forecasting, Graph for storing and traversing connected data, Data agent for natural-language Q&A, and Operations agent (preview) for monitoring live data and triggering governed actions [S1].
None of these items is exclusive to the IQ workload. Fabric items can belong to multiple workloads simultaneously — the semantic model item, for instance, is shared with the Power BI workload, while Graph and the operations agent are shared with the Real-Time Intelligence workload [S1]. So Fabric IQ is less a walled-off product than a particular arrangement of items that already exist elsewhere in Fabric, organized around the ontology as the new connective layer.
Release status moves quickly on preview items, and sourcing on it varies in trust tier. A tier-6 community deep-dive states that, at Microsoft Build 2026, the Operations agent, Graph in Fabric, and Planning in Fabric items reached general availability while the Ontology item remained in preview [S2]. Inference: treat this specific GA/preview breakdown as a lower-confidence, unofficial account pending confirmation from a Microsoft Learn or product-blog source — it is included here because it is the most current signal available, not because it carries first-party weight.
Planning: a new workload with its own billing model#
Planning in Microsoft Fabric (Preview) unifies planning, analytics, reporting, and data management into a single Fabric experience rather than a separate standalone tool [S4]. Because Planning's usage pattern looks nothing like a typical analytics workload, Microsoft designed a billing model specifically for it — and the reasoning behind that design is itself informative about how the workload is meant to be used.
Microsoft's stated rationale is that enterprise planning work is cyclical: concentrated, high-intensity usage clusters at month-end and at quarter- or year-end forecasting, rather than the steady, incremental usage pattern typical of most analytics workloads [S4]. Two simpler pricing models were considered and rejected: pure consumption pricing would undervalue Planning because its critical work happens in short bursts, and flat seat-based licensing feels rigid because it charges for users who only participate occasionally [S4].
The model that resulted splits billing by how someone uses Planning. People-facing usage is billed through role- and session-based pricing, while automated operations like data sync and sheet updates are billed through per-successful-job pricing [S4]. On the people side, Planning defines three roles with different pricing weight: Viewers (read-only, priced low to encourage broad adoption), Stakeholders (active participants, priced for engagement), and Planners (the model owners running scenarios, priced for their outsized impact on decisions) [S4].
A Planning session is the billing unit behind the role-based side of that model. A session binds a specific user, their role, a specific Fabric capacity, and a time window; it starts when a user meaningfully engages with a planning artifact and then runs for a fixed 30-day (730-hour) period [S4]. That fixed window is a deliberate cost-smoothing choice — it exists so a short burst of planning activity around a quarter-end close isn't billed as if it were continuous heavy usage for the following month [S4].
During the Planning preview, Capacity Metrics shows usage only — no dollar charges are applied. Per the announcement, billing for Planning is stated to begin at general availability, and the same post states GA is targeted for July 2026 [S4]. Treat "July 2026" as the vendor's own stated target, not a guaranteed date — roadmap timing on preview features can slip, and this article is not the place to firm it up further.
The two agents grounded in this ontology#
Two of the items in the IQ workload are agents that consume the ontology and semantic model directly, rather than raw tables:
- An operations agent (preview) is an AI agent that reasons across business concepts to monitor real-time data, detect anomalies, and recommend or trigger governed business actions. It is shared between the IQ and Real-Time Intelligence workloads [S1].
- A data agent, in the same family, answers natural-language questions grounded in semantic models and ontologies for a specific business domain [S1].
A tier-6 deep-dive frames the two as complementary rather than overlapping: the data agent is reactive and conversational, answering a question when asked, while the operations agent continuously monitors data and can autonomously propose or trigger governed actions without a person initiating the interaction [S2]. Because both agents reason over the ontology rather than over raw schemas, the same governed business definitions apply no matter which agent — or which downstream application — is asking the question.
The claims in this knowledge base describe the data agent's grounding under the fabric-data-agent capability, not fabric-iq directly — it is included here for context on how the IQ workload's agents relate to the ontology, but see that capability's own coverage for depth on data agents specifically.
Reaching Fabric IQ From Outside the Fabric Portal#
A tier-6 deep-dive positions Fabric IQ as reachable from multiple first-party Microsoft surfaces beyond the Fabric portal itself, including Microsoft Foundry, Copilot Studio (as an MCP tool in preview), Microsoft Agent 365, and GitHub Copilot CLI [S2]. Inference: this is a lower-tier, single-source claim about ecosystem reach rather than a Microsoft Learn statement — worth flagging as a direction Fabric IQ is heading, not a fully verified integration matrix.
OneLake Underneath, Even Where It Isn't Listed#
OneLake is not formally listed as an item inside the IQ (preview) workload, but every item in that workload relies on and interacts natively with OneLake data tables [S1]. That's a deliberate omission, not a gap: OneLake is the substrate everything else in Fabric IQ sits on top of, so calling it out as a separate "IQ item" would misrepresent its role as infrastructure rather than a workload-specific feature.
That substrate role extends beyond a single cloud. Once multi-cloud data lands in OneLake — for example through Fabric Data Factory's multi-cloud architecture patterns — it can be made available to Fabric IQ, extending Fabric's AI-oriented capabilities across models and agents built on that unified data [S5]. In other words, Fabric IQ doesn't care whether the underlying data originated in Azure, AWS, or GCP; once it's landed and bound into OneLake, it's eligible for the same ontology and agent layer as any other Fabric-native data.
Benefits: Why Organizations Adopt This Pattern#
Fabric IQ's stated benefits cluster around three things: cross-domain reasoning, faster onboarding, and governance [S1].
Cross-domain reasoning comes from graph relationship traversal — the example given is chaining an Order to a Shipment to a sensor reading to detect a cold-chain breach, a question that spans multiple business domains and would otherwise require joining across systems that don't share a common vocabulary [S1].
Faster onboarding follows from declaring business concepts once. If "customer," "order," and "shipment" are already defined in the ontology, a new report, agent, or application doesn't need to rediscover those definitions from raw schemas — it reuses them [S1].
Governance comes from enforcing consistent definitions across teams — the same mechanism that prevents onboarding friction also prevents different teams from quietly drifting into incompatible definitions of the same business concept [S1].
| Benefit | What it comes from | Source |
|---|---|---|
| Cross-domain reasoning | Graph relationship traversal across chained entities (Order to Shipment to sensor) | [S1] |
| Faster onboarding | Business concepts declared once in the ontology, reused everywhere | [S1] |
| Governance | Consistent definitions enforced across teams | [S1] |
Community discussion adds a related, narrower framing for one specific consumer of the ontology: several authors describe Fabric IQ ontologies as a complement to Fabric Data Agents specifically, because externalizing business meaning and relationships as an explicit semantic layer lets an agent navigate defined concepts instead of inferring them purely from prompts and raw schema — which those authors argue reduces the fragility of prompt-heavy NL2SQL setups [S6]. Inference: this is a tier-4 community viewpoint, not a benchmarked comparison — treat "reduces fragility" as a reasoned argument rather than a measured result.
What Goes Wrong: Skipping the Shared Ontology#
The antipattern Fabric IQ is built to counter is straightforward to state: without a shared ontology layer, every business question posed to an AI system requires manual translation, by a domain expert, from raw tables and schemas into business concepts [S1]. That manual-translation step doesn't scale, and it introduces exactly the kind of inconsistency — different experts translating the same underlying data into subtly different business meanings — that makes AI systems unreliable for high-stakes decisions [S1].
This is why the ontology is positioned as a governance mechanism as much as a modeling convenience. It isn't just that redefining "active customer" five times across five teams is inefficient — it's that an AI agent making a governed business decision on top of an inconsistent definition is a decision made on unreliable grounds.
A second, more operational antipattern applies once an ontology is actually running: upstream data source changes — new, updated, or deleted rows — are not automatically reflected in the ontology's bound data or graph. They require an explicit manual or scheduled refresh of the graph model before they become visible [S3]. Skipping that refresh cadence means agents and reports can silently reason over stale entity instances without any error being raised.
The operations agent carries its own, separate set of rollout gaps worth planning around rather than discovering in production. At time of writing, per a tier-6 deep-dive, it is English-language only, unavailable in the South Central US and East US regions, and unsupported on trial (non-paid) Fabric capacities [S7]. Inference: these are point-in-time rollout limitations on a preview feature, not permanent architectural constraints — expect this list to shrink as the feature matures, and verify current status before relying on it for a production rollout plan.
Internals#
Architecture & design#
At the architecture level, Fabric IQ is organized around two items — the ontology (preview) and the semantic model — that together deliver three layers of business context: unified data, business intelligence, and operational intelligence [S1]. The ontology is not a rebuild of the semantic model; it is generated or aligned directly from semantic models already in production, so the two items form a chain rather than two competing sources of truth [S1].
The IQ (preview) workload wraps this pair with additional shared items — Plan (preview), Graph, Data agent, and Operations agent (preview) — several of which are also claimed by other workloads (the semantic model by Power BI; Graph and the operations agent by Real-Time Intelligence), reflecting a design where Fabric items are shared building blocks rather than workload-exclusive components [S1]. OneLake sits underneath all of it as the unifying data substrate, even though it isn't formally enumerated as an IQ workload item [S1].
Inside the ontology item itself, the architecture separates modeling from storage. Entity types, properties, and relationships are modeled once as a logical layer; a data-binding layer separately connects that logical model to concrete OneLake data — lakehouse tables, Eventhouse streams, or Power BI semantic models — by mapping columns to properties and keys to relationship links, while carrying schema-evolution rules, data-quality checks, and provenance at the concept level [S3]. That separation is what lets the same entity type stay stable even if its underlying tables change shape over time.
For traversal at scale, the ontology's instance data is materialized as a queryable instance graph — nodes as entity instances, edges as asserted or derived links carrying metadata — built on top of the separate Graph in Microsoft Fabric item. That underlying Graph item must be enabled as a tenant setting before an ontology's graph features will work at all [S3]. This is a concrete dependency worth planning for: standing up an ontology's graph capability is not solely a workspace-level action, it also requires a tenant-level toggle.
The operations agent's architecture sits downstream of a full Real-Time Intelligence pipeline rather than being a standalone monitoring tool: Eventstream ingests telemetry, Eventhouse/KQL stores it, Fabric Activator applies threshold-based alerting, and the operations agent adds LLM-based reasoning and recommended actions on top of that existing stack [S7]. Positioned this way, the operations agent is the reasoning layer at the end of an already-existing Fabric real-time architecture, not a replacement for Eventstream, Eventhouse, or Activator.
How it works internally#
Ontology queries are built to start from business vocabulary rather than physical schema: a caller starts from an entity type, filters by property, traverses relationships, and aggregates over time using business terminology, and the ontology layer routes execution to whichever backend actually holds the data — GQL against Graph in Microsoft Fabric, or KQL against Eventhouse [S3]. NL2Ontology sits in front of that query layer and converts a natural-language business question into one of these structured queries, but it does so within guardrails: the filters, joins, units, and validity windows it generates are constrained to the definitions already published in the ontology, rather than being inferred freely by a model from raw schema [S3]. That constraint is the mechanism, concretely, by which the ontology prevents the "different experts, different definitions" antipattern described earlier — the model is not allowed to invent a new definition of "active customer" on the fly.
The operations agent's internal execution loop is polling-based rather than event-driven: it evaluates its configured detection rules against Eventhouse KQL tables on a fixed cadence of every 5 minutes, rather than reacting to telemetry instantly as it arrives [S7]. When a rule fires, the agent is human-in-the-loop by design — it proposes a recommended action from its reasoning over the telemetry, and a person must approve that proposal in Microsoft Teams before a connected Power Automate flow actually executes it [S7]. That proposal doesn't stay open indefinitely: an action that is neither approved nor rejected expires automatically after 3 days [S7].
A subtler internal detail affects both auditing and security posture: a triggered operations-agent action executes using the identity of the person who created the agent, not the identity of whoever approves the action in Teams [S7]. That means approval in Teams is a governance gate on whether an action runs, not a delegation of whose permissions it runs under — worth understanding before granting broad approval rights to people who shouldn't also be implicitly granted the agent creator's execution scope.
Because upstream changes require an explicit refresh before they appear in the ontology's bound data or graph [S3], and because the operations agent only evaluates its rules every 5 minutes [S7], neither layer of Fabric IQ should be assumed to reflect the absolute latest source-system state at query time. Build monitoring and alerting expectations around those two lag sources rather than assuming true real-time freshness.
Performance characteristics#
Coming soon — this depth isn't in the knowledge base yet. It needs an L4/L5 source such as a Microsoft engineering blog covering Fabric IQ ontology query performance, NL2Ontology latency characteristics, graph-refresh throughput at scale, or measured benchmark numbers for the operations agent's 5-minute polling cadence under high-cardinality Eventhouse tables. Tracked in content/queue.md.
Worked Example#
Consider a retail organization that already has a mature Power BI semantic model covering Customer, Order, and Shipment tables, built up over several years by its BI team, and that wants to add both an ontology and an operations agent.
1. Start from what already exists. Rather than authoring a new ontology from scratch, the team generates/aligns an ontology directly from the existing production semantic model, carrying over the established definitions of Customer, Order, and Shipment [S1].
2. The ontology adds entity types, relationships, and data bindings on top. Each of Customer, Order, and Shipment becomes a standardized entity type, with a data-binding layer mapping the underlying lakehouse columns to entity properties and keys to relationship links [S3]. The team enables the Graph in Microsoft Fabric tenant setting so the ontology's instance graph can materialize, then defines the Order → Shipment → SensorReading relationships as typed, directional links [S3].
3. NL2Ontology exposes a natural-language layer without new join logic. A business user can now ask a plain-language question about a shipment, and NL2Ontology converts it into a structured query — constrained to the ontology's own published definitions — that the ontology routes to KQL against Eventhouse for the sensor-reading data and to GQL against Graph for the relationship traversal [S3].
4. An operations agent is pointed at the ontology, not raw tables. The organization's operations agent, sitting downstream of Eventstream, Eventhouse, and Fabric Activator, evaluates its cold-chain detection rule every 5 minutes, reasoning across the ontology's chained Order → Shipment → sensor-reading concepts to detect a cold-chain breach [S7]. It proposes an alert-the-logistics-team action, which a manager approves in Microsoft Teams; the action then executes under the identity of whoever originally created the agent, and would have expired automatically after 3 days had nobody responded [S7].
5. Planning consumes the same underlying OneLake data on its own billing terms. If the same organization also stands up Planning (Preview) for its quarterly forecasting cycle, its Planners run scenarios and its Stakeholders review them under role- and session-based billing, with each 30-day session smoothing the cost of a concentrated month-end planning push rather than billing it as sustained heavy usage [S4].
6. Every downstream consumer inherits the same definitions. Because the semantic model, the ontology, the data agent, the operations agent, and Planning's forecasts all trace back to the same aligned definitions, a report built on the semantic model and an agent reasoning over the ontology agree on what a "customer" or a "shipment" is — closing the gap that, without a shared ontology, would otherwise require a domain expert to manually re-translate the business meaning for every new AI system built on top of the data [S1].
Inference: the specific retail scenario, table names, and step sequence above are an illustrative synthesis built to connect the verified claims into one worked flow; the underlying facts about ontology generation, entity/relationship/data-binding structure, NL2Ontology routing, operations-agent polling and human-in-the-loop behavior, and Planning's session-based billing are each grounded in the cited claims.