An AI assistant can find a customer record and still misunderstand the customer. It may confuse a legal entity with a billing account, calculate revenue using the wrong definition, or treat an unresolved service case as evidence of a commercial risk that the business has never agreed to measure that way.
These are familiar data problems. AI makes them more visible because it lets more people ask broader questions without knowing which system, measure, or subject-matter expert should supply each part of the answer.
Microsoft’s updated Fabric ontology capabilities offer a practical way to address that problem. They let an organization capture business concepts, connect them to data, reuse established calculations, and make that context available to supported agents. The late-September and October updates strengthen the connection between the analytical models companies already maintain and the wider Microsoft IQ ecosystem.
My interest is in the economics of that reuse. A company that defines its customer, product, account, and service concepts once, with accountable owners, should have less interpretive work to repeat every time it builds another agent. It also has a more precise place to investigate when an answer is wrong.
Give business meaning somewhere to live
An ontology is a model of the things a business cares about and how they relate. A customer places an order. An account belongs to a customer. A service case concerns a product. Properties describe those things; relationships connect them; rules and metrics explain how the organization interprets them.
Fabric’s ontology item stores those definitions and their bindings to enterprise data. It sits within Fabric IQ, alongside the semantic models and other capabilities used to give business data a shared meaning. The ontology acts as context over the sources that own the data; it is not a universal replacement for their query engines. The updated experience remains in preview.
That distinction is useful to a business leader. A company does not have to resolve every data-platform decision before it can begin improving how a defined business domain is understood. It can start with a limited set of important concepts, established sources, and decisions that already consume them.
For example, a customer-service review may require three kinds of evidence: open commercial commitments, unresolved service issues, and the policy that defines escalation. Today, an analyst often reconciles those things manually. An ontology gives the organization a place to make the relationships and definitions explicit, so each new application does not begin with an independent interpretation.
Extend the value of existing semantic models
The most commercially useful change is the ability to bring established Power BI measures into ontology context. Metrics retain a connection to their source semantic model, allowing agents to recognize calculations the business already owns. The source model remains authoritative for the DAX expression. Refresh is required to reflect source measure changes in the ontology.
This matters because a metric’s value includes the work behind it. Someone decided which transactions count, how dates are interpreted, which exclusions apply, and who can see the result. Finance or operations may have spent years making that definition dependable.
When an AI implementation reconstructs the calculation from raw tables, it can discard much of that investment. Reusing the governed measure extends the return on the original modeling and review effort. It also keeps the accountable owner close to the calculation.
The ontology can be generated from a semantic model, and Microsoft’s updated workflow supports bringing additional related models into the same ontology through its agent. [3] That makes it possible to begin connecting a domain that has been divided among sales, service, and finance models.
The business work is deciding whether similarly named concepts are actually the same. A customer in a service model may mean an installed location, while a finance model uses the invoiced legal entity. An agent can propose a mapping. The organization still needs someone who can approve what that mapping means.
This is a useful change in the division of labor. Technology can accelerate discovery and drafting. Domain owners spend their time resolving the disagreements that have real consequences for the business.
Put operating knowledge beside the data
The updated ontology supports descriptions, alternative names for entity types, and structured metadata. These additions help connect the language used in a meeting to the concepts represented in systems. A business does not gain much from a beautifully modeled entity if its users call it something else and every agent needs a separate translation.
Natural-language rules add another kind of context. Teams can record a definition such as when a service case requires escalation and link it to the relevant concepts. The rule is discoverable business knowledge; it does not execute an action or enforce access merely because it has been written into the ontology.
That makes rules useful as maintained specifications. The operations owner can approve the policy once and identify its effective date and scope. An application team can implement the required behavior, then test that behavior against the same specification. An agent can retrieve the definition when explaining a recommendation.
Namespaces help preserve legitimate differences between domains, while inheritance supports reuse among specialized entity types. These are modeling tools with an organizational consequence: teams can share common concepts without forcing every department to adopt an identical view of its work.
I would use that flexibility carefully. A namespace should clarify ownership and meaning. It should not become a technical way to hide disagreements that the business actually needs to resolve.
Where the wider IQ ecosystem fits
Microsoft IQ brings together capabilities for business data, workplace context, institutional knowledge, and information from the web. The useful question is what evidence each contributes to a decision.
| Capability | Evidence it contributes | Example in a customer-service review |
|---|---|---|
| Fabric IQ | Business entities, relationships, metrics, and operational data | Which customers have unresolved cases and open order value |
| Work IQ | Context about people, collaboration, and work | Who owns the relationship and what was discussed in the account meeting |
| Foundry IQ | Curated institutional knowledge | The approved escalation policy and relevant service guidance |
| Web IQ | Current external information | Public events that may explain a change in the customer’s operating environment |
The examples are a proposed design, not a claim that turning on an ontology automatically assembles those sources. The agent or application needs explicit connections, appropriate access, and a clear instruction about which source owns each kind of evidence.
That source hierarchy is particularly valuable. A meeting note may explain why someone made an exception; it should not silently replace an approved policy. A public article may add context; it should not overwrite the company’s recorded account balance. An AI response becomes easier to assess when it separates measured facts, policy, collaboration context, and its own interpretation.
Fabric ontology supplies the business concepts that help connect these kinds of evidence. A stable customer identifier is more useful than a fuzzy match on a company name. A defined relationship between a customer and an order provides more dependable context than an agent guessing from similar column names.
Microsoft documents a preview route that exposes a Fabric ontology as a Foundry IQ knowledge source, wraps it in a knowledge base, and attaches that knowledge base to a Foundry agent. This is a concrete way to bring structured business context into a wider agent design.
There is also a naming distinction worth keeping clear. The generally available Fabric IQ MCP endpoint currently serves Power BI reports and semantic models. Ontology has a separate MCP integration. A connector carrying the Fabric IQ name does not, by itself, establish that it can consume an ontology.
The business value is in repeated use
The first use case has to pay for discovery, modeling, and agreement. That work is visible, and it can make a shared ontology look more expensive than a narrowly prompted agent built for one demonstration.
The comparison changes when the second and third applications arrive. If each needs the same definition of an active customer or the same relationship between a service issue and an installed product, the organization can reuse what it has already approved. The benefit is less time rediscovering the domain, fewer separate interpretations to maintain, and a clearer explanation of why two experiences produce different answers.
Those are hypotheses to measure. Track the time required to connect a new consumer to an existing domain, the number of definitions that must be recreated, and the effort required to resolve inconsistent answers. Record how much work moves from individual agent teams into shared modeling and review. Shared ownership does not make that work disappear.
Value can also come from improving a decision. A service team may identify affected customers more quickly or prepare a better account review with fewer manual reconciliations. Measure that outcome directly. Counting entities, relationships, or connected agents tells a team what it built; it does not establish that the business gained anything.
I would avoid a large initial ontology program whose success depends on modeling the whole enterprise. Start with a decision that crosses two or three established sources, has a recognizable owner, and already creates reconciliation work. The organization should be able to compare the new experience with the current one.
Ownership becomes part of the product
The business domain owner should approve definitions and their intended uses. Semantic-model owners remain responsible for calculations. Data engineers maintain bindings and identity mappings. Agent owners evaluate what their consumers actually retrieve and how they use it.
That arrangement needs a release process. A definition change can affect multiple applications even when no underlying table changes. A new synonym can alter how a question is interpreted. A measure update can change a recommendation. A relationship correction can change which customers appear to be affected by an event.
Fabric’s named ontology versions provide checkpoints that authors can create and restore. The operating process should attach a reason for the change, an accountable reviewer, and a small set of business questions that must still produce the expected answers. This is an ongoing responsibility, particularly as models and agent tools evolve.
Permissions remain a separate responsibility. A label or business rule describing sensitive information does not grant or deny access. The configured source and consumer permissions must enforce the required boundaries. Test the experience as an ordinary intended user, rather than relying on the author’s broader access.
Choose a bounded first application
The preview is mature enough to evaluate concrete business questions, but individual integrations have current limits. As of October 17, Microsoft’s documentation flags an issue attaching new-experience ontologies to Fabric data agents. The ontology agent also has a known limitation in automatically considering stored rules through its answering tool. Those details should shape the chosen consumer and evaluation, rather than become a reason to postpone the modeling work.
A sensible first application is a read-only review that combines a small set of trusted measures with explicit business definitions. Give users the evidence behind the answer. Require the agent to identify missing context. Compare results with the existing process, including ambiguous cases that require a person to decide.
The strategic attraction of Fabric ontology is that it can extend business meaning across more of the tools people already use. Microsoft IQ provides several places for that meaning to become useful. The organization earns the value by choosing a domain it can own, making its definitions dependable, and reusing them in the next application instead of rebuilding the same understanding again
