Fabric IQ gives agents shared business context

Microsoft Fabric IQ is a preview workload for adding shared business meaning to data in OneLake. Its ontology and graph experiences can give people, applications, and agents a common vocabulary for concepts such as customers, orders, assets, and shipments.

That context can reduce repeated translation between teams. It does not settle which definition is correct, who owns it, or whether an agent’s answer is safe to use.

Status check

Microsoft currently documents Fabric IQ and ontology as preview. Validate tenant, region, item, API, and support requirements before using them in a production dependency.

What Fabric IQ contains

The Fabric IQ documentation groups several related capabilities. Their roles are distinct:

• Ontology defines business entities, properties, relationships, and rules, then binds those definitions to source data.
• Graph in Microsoft Fabric stores and traverses connected instances, supporting relationship and impact analysis.
• Semantic models provide governed measures and dimensions for analytics.
• Data and operations agents can use this context to answer questions or respond to events within their configured boundaries.

Ontology and Graph are not interchangeable. Microsoft describes ontology as the vocabulary and semantic layer, while Graph provides graph storage and computation.

Where shared context helps

Consider two teams that both use the term “active customer.” One means an account with a purchase in 90 days. The other means a contract that has not expired. An AI assistant cannot safely resolve that conflict from column names alone.

An ontology can make the definitions, relationships, source mappings, and ownership visible. A consuming agent can then query published business concepts instead of guessing from raw tables.

The hard work remains organisational. Teams still need to agree on terms, exceptions, effective dates, and who can approve a change.

Build the first ontology around a decision

Avoid modelling the whole enterprise at once. Choose one question that crosses two or three domains, then define only the concepts needed to answer it.

For each concept, record:

Definition field	Example question
Meaning	What counts as an order?
Identifier	Which field is stable across sources?
Source	Which system is authoritative?
Time	When does the definition take effect?
Owner	Who approves a change?
Access	Who may query the bound data?

This produces a testable model rather than a vocabulary project with no consumer.

Preview limits to include in the plan

The ontology documentation notes that upstream changes require a refresh before they appear in the ontology item. Microsoft also documents current feature limits, including the absence of ontology versioning.

Before a pilot, verify:

• supported source and binding types
• refresh timing and failure behaviour
• permissions through every query path
• deployment and change-control options
• agent integration status and data exposure
• how the solution can be removed or rebuilt

Preview capabilities can change. Record the documentation date and rerun these checks at each release gate.

Evaluate the consumer, not only the model

A correct ontology does not guarantee a correct agent answer. Test the full path with known questions, ambiguous wording, missing data, and users with different permissions.

Measure whether the consumer cites the right source, applies the published definition, respects access, and asks for help when the evidence is insufficient. Those checks turn shared context into an accountable system design.