I attended FabCon Atlanta 2026.

I also created a few short videos that show the atmosphere of the venue, so feel free to check them out first.

FabCon Atlanta 2026 Day1-Day3 morning workshops 、KeyNone

FabCon Atlanta 2026 Day3 noon-Day5CoreNote session power hour

In this article, based on what I saw and heard at FabCon, I would like to focus especially on Ontology within Fabric IQ and share how I think we should understand it at this point in time.

Fabric IQ is described as a workload that organizes data in OneLake using business language, enabling analytics and AI agents to use that data with consistent meaning.

The Fabric IQ workload includes semantic models and Data Agents, and Ontology is one part of it.

I think many people may currently understand “Fabric IQ” as almost the same thing as “Ontology.”

That is not completely wrong. However, Fabric IQ is a broader term, so in this article I will mainly use the word “Ontology” to avoid confusion.

What is Fabric IQ (preview)?

The Atmosphere Around Fabric IQ at FabCon

At FabCon, I felt that everyone also highly interested in Fabric IQ.

At the same time, some of the questions were very basic, such as “What is IQ?”

In other words, my honest impression was that Fabric IQ is attracting a lot of attention, but even in the United States, understanding of it has not yet become widespread.

I also attended several IQ-related sessions. Based on the sessions I joined, I cannot say that I clearly saw exactly which real-world projects should use it and how.

Of course, there were Ontology demos, and there were discussions about how AI will be able to understand business meaning more easily and how the semantic layer will become more important. Officially, Ontology is also described as a way to represent a business in a machine-readable form through entities, properties, relationships, and rules.

However, to be honest, my current impression is that the concept itself is very attractive, but common implementation patterns are not yet widely understood.

My Conclusion First: I Would Still Take a Wait-and-See Approach for Production Use

My conclusion is that, at this point, I would still take a wait-and-see approach before placing Ontology at the center of a production environment.

The reason is simple.

First, it is still officially in preview.

Second, when it comes to improving the accuracy of Data Agents by giving them business context, I feel that many use cases can already be covered quite well by using semantic models.

A Common Misunderstanding

Ontology allows you to create entities as business objects and define relationships using natural language to represent business meaning.

On the other hand, based on the current specification, you cannot simply write natural-language descriptions for tables and columns inside Ontology in the same way you can with semantic model properties.

Of course, I am not saying that Ontology is unnecessary.

Rather, I believe Microsoft will continue to invest heavily in this area, and I personally have high expectations for it.

However, at least for now, I think the right stage is:

Development teams should try it in a test environment
Organizations should watch it as a future architecture option

On the other hand, I think it is still a little early to talk about adopting it broadly in production right away.

Semantic Models Will Continue to Be Important for AI

So, does that mean the semantic layer is still something for the future?

I do not think so.

Rather, even right now, building a well-designed semantic model is very effective. I also believe that even after Ontology becomes generally available in the future, the importance of semantic models will not disappear.

Officially, Ontology can be generated from semantic models. In other words, it feels more natural to see Ontology not as something that replaces semantic models, but as something that extends business meaning and relationships on top of semantic models as one of its foundations.

What Semantic Models Can Already Do Today

With the arrival of Data Agent, semantic models are no longer just models for BI.

You can specify a semantic model as a data source for a Data Agent, and through Data Agent customization, you can provide business metadata to AI.

For example:

Semantic model
- Use the “Prep for AI” feature
- Write the business meaning of tables and columns in properties such as table names, column names, table descriptions, and column descriptions
- Predefine calculations and business logic with DAX
Data Agent
- Clarify the role of the agent through instructions
- Add descriptions for data sources so that the agent can choose the right source depending on the question
- Use example query sets for expected questions
  - Note: this is not available for semantic models

For more details, I recommend starting with the following documentation.

Semantic model best practices for data agent

Best practices for configuring your data agent

Also, a Data Agent does not necessarily need to have only one data source.

When the data volume is large, or when you want to use example query sets, combining a semantic model with a lakehouse or warehouse can be a very realistic design.

For example:

Store large volumes of data in a lakehouse or warehouse
Organize the metrics and definitions you want AI to use in a semantic model

If you want to add business metadata to each table or column, my personal recommendation at this point is to write it in the semantic model properties.

Data Agent can refer to semantic model properties.

Editing Semantic Model Metadata Properties from a Notebook with Semantic Link in Fabric

When Would Ontology Become Necessary?

At this point, you might think, “Then isn’t a semantic model enough?”

In fact, I think semantic models can cover a large part of many use cases.

That said, based on my current understanding, I feel that Ontology becomes especially useful in the following two scenarios.

In other words, if your use case does not fall into these two patterns, a semantic model may be enough for now.

1. When You Want to Query Across Multi-Layered Relationships Like a Graph

The first case is when you want to ask questions that go across multiple layers of relationships.

Semantic models can also express relationships. However, as the relationships become more complex, the thinking tends to become more JOIN-oriented.

Ontology, on the other hand, uses a graph-based approach, so it seems better suited to graph-like operations such as path exploration.

For example, imagine you have the following tables:

Customers
Orders
Products
Contracts
Support history
Responsible organizations
Related events

If you want to ask, “What is related to this customer?” across multiple business domains, Ontology seems like a more natural way to express that.

In other words, Ontology becomes meaningful when the relationships themselves are valuable, rather than when you only need simple aggregations or KPI questions.

2. When You Want to Treat Historical Data and Real-Time Data as One Business Entity

The second case is when you want to treat historical data and real-time data not as separate systems, but as the same business object.

Officially, Fabric IQ is described as a way to unify data in OneLake using business language and give consistent meaning to analytics and AI agents.

For example:

Recent order events stored in Eventhouse
Historical order data accumulated in Lakehouse

If you want to handle these together in the context of a single business entity such as “Order,” the idea of Ontology seems to be a very good fit.

This feels less like a simple BI model, or physical model, and more like a foundation that helps AI understand the meaning structure of the business, in other words, a logical model.

We Do Not Need to Rush Ontology. For Now, This Is a Preparation Phase

As I have written so far, I believe Ontology has great potential.

However, I personally do not think it is something that must be introduced as the highest priority right now.

Ontology can be seen as a mechanism for strengthening the business meaning layer afterward.

Therefore, rather than seeing it as a foundation that must be introduced from the beginning, it feels more natural to think of it as something that organizations can add after their data platform and semantic organization have reached a certain level of maturity.

In fact, even if you want to use Ontology, there will likely be many cases where the organization’s data itself is not yet ready.

For example:

Required tables do not exist
Key definitions and meanings differ across systems
Tables that should be related cannot be connected cleanly through relationships

In such a state, the problem exists before Ontology can even be built.

That is why I believe the most important thing right now is to prepare and organize the organization’s data so that it can take advantage of Ontology in the future.

Microsoft will likely continue to invest heavily in this area, and the concept of Ontology itself will become increasingly important.

In that sense, I think we should see the current phase not as “the time to rush Ontology into production,” but as a preparation period for creating the conditions where Ontology can be used effectively.

In addition, I also feel that building Ontology requires a surprisingly high level of skill.

It is not enough to have only data modeling knowledge.

You need both:

An understanding of the business meaning behind the organization’s operations and data
The data modeling knowledge required to turn that meaning into a structure

In other words, Ontology cannot be built only by the IT department.

At the same time, it also cannot be fully defined only by the business department.

Collaboration between IT and business will be important, and people who understand both sides to some extent will become increasingly valuable.

Bonus 1: Foundry IQ Already Feels More Practical

As a side note, based on my experience, Foundry IQ felt more practical at this point.

For example, use cases such as the following are relatively easy to imagine even now:

Using OneLake as a knowledge source
Using SharePoint as a knowledge source

Fabric Ontology still looks like something that may become very interesting in the future.

On the other hand, Foundry IQ already feels easier to connect to concrete use cases.

Of course, these two are not competitors. I believe they will become more connected over time.

Bonus 2: Data Agent Development Works Well with CI/CD and Should Use Git Integration

This is slightly separate from Ontology, but through FabCon, I was reminded again that Data Agent works very well with CI/CD.

Are you using Git integration in Fabric?

As mentioned earlier, when developing a Data Agent, you define items such as instructions, data source descriptions, and example query sets.

Among these, data source descriptions may not change very frequently.

However, I feel that instructions and example query sets are things that will continue to evolve once the agent starts being used.

For example, in actual operation, the following situations are likely to happen:

A user asks an unexpected question, and you want to add a query set for that pattern
You adjust the instruction prompt, but the accuracy becomes worse
You want to roll back to a previous version and check the behavior
You want to compare the previous version and the latest version while testing

In other words, a Data Agent is not something you configure once and forget.

It is something that should be continuously improved during operation.

That is why it works very well with Git integration, where you can manage change history, track differences, and roll back when necessary.

If you want to use Data Agent seriously in Fabric, I believe it is important not only to create the agent, but also to grow it with Git integration in mind.

Microsoft Fabric Git Integration × Azure DevOps: How to Release Fabric Items Across Different Tenants

How to Reflect Changes to Another Repository with Azure DevOps Pipeline: A Minimal Memo for Repo A → Repo B

Summary

Finally, here is my current understanding.

Expectations for Fabric IQ / Ontology are high
However, it is still in preview, so I would be cautious about using it in production at this stage
In many cases, the combination of semantic models and Data Agent is already quite effective
Ontology will become especially useful in scenarios such as:
- Queries across multi-layered relationships
- Use cases where accumulated data and real-time data need to be handled in one business context

I believe this is definitely an area where Microsoft will continue to invest.

Therefore, now is a good time to catch up on Ontology and prepare your organization’s data platform so that you can adopt it quickly when the right timing comes.

Thank you for reading this long article!