AI agents can answer natural-language questions, but only when they understand what your data means. Without structured business context, agents operate on schema and metadata alone. They may know a table called Sales exists, but not whether it represents gross revenue, net revenue or transactions.
Fabric ontologies close that gap. Paired with AI agents, they form a cognitive layer over enterprise data. In retail and analytics work, teams often want Copilot and Fabric data agents to inherit the same definitions of revenue, margin and KPIs already certified in Power BI semantic models.
What is a Fabric ontology, and why do data agents need one
An ontology is a machine-understandable representation of a business. It provides formal naming and explicit definitions of objects and concepts and defines how they relate to each other. It is a structured semantic model that describes entity types, their properties and the relationships between them in a way that machines can interpret.
In the context of Microsoft Fabric, an ontology acts as a business context layer on top of data. While a traditional semantic model defines measures, relationships and hierarchies for reporting, an ontology formalizes business meaning.
In Fabric, ontologies can be generated from an existing semantic model or built directly from data stored in OneLake.
A Fabric data agent is a conversational system built with generative AI that interprets natural-language questions and translates them into structured queries. It can connect to lakehouses, warehouses, Power BI semantic models, KQL databases and ontologies.
However, without structured business context, an AI agent operates only on schema and metadata. It may know that a table exists, but not what it means in business terms. For example, it may recognize a table called Sales but not understand whether it represents gross revenue, net revenue or transactions.
By using an AI agent over an ontology, the system becomes context-aware and able to understand what each concept represents to the business. Instead of simply querying tables, it reasons over defined concepts and relationships.
In this sense, ontology and AI agents together form a cognitive layer over enterprise data. The ontology defines meaning, while the agent interprets questions and navigates that meaning to retrieve relevant insights.
Why ontologies and Fabric data agents belong together
Business intelligence has evolved significantly over time. It began with static reports that simply presented historical data. This progressed to self-service dashboards, enabling users to explore data independently. The next major step was the introduction of semantic models, which standardized business logic, calculations and definitions across organizations.
Today, the evolution continues toward systems that not only retrieve numbers but also understand the meaning and context behind them.
AI capabilities in Microsoft Fabric have expanded significantly with the introduction of AI-powered experiences such as Copilot and data agents. Introduced throughout 2023–2024 as part of Fabric’s broader AI integration roadmap, these features allow users to interact with data conversationally through generative AI.
Ontology-driven models and intelligent agents represent the next stage of this evolution. Ontologies provide a structured representation of business concepts and their relationships. When combined with Fabric data agents, this approach allows systems to reason over data, automate analytical tasks and provide context-aware insights.
For business analysis this brings several advantages:
- Shared business vocabulary - Ontologies formalize business concepts in a structured way. This creates a shared vocabulary between analysts, engineers and business users.
- Improved query understanding - AI agents using ontologies understand intent, not just schema.
- Better business analysis - For analysts, this means less time translating business questions into technical queries. The AI agent can navigate the ontology and retrieve relevant data more directly, allowing analysts to focus more on interpretation and decision-making.
How ontologies are implemented in Fabric
It is possible to create an ontology generated from a semantic model, which automatically creates the properties and their relationships, or build one directly from OneLake data.
Generating an ontology from a semantic model is usually the fastest approach because the model already contains relationships and business logic.
However, some things need to be considered:
First, the semantic model must be published, and its tables must be visible. Hidden tables or hidden columns can cause issues during ontology generation because the ontology builder expects a transparent structure. This is one of those cases where BI modelling conventions such as hiding technical tables may need to be adjusted.
There are also technical constraints. Ontology data binding is not supported for source semantic models in Import mode, or semantic models in Direct Lake mode while the backing lakehouse is in a workspace with inbound public access disabled.
Another limitation relates to data types. Fabric Graph does not currently support the Decimal type. As a result, if an ontology is generated from a semantic model containing Decimal columns, queries may return null values for those properties. However, the Double type is supported. Recreating the property as Double within the ontology and binding it to the source data allows values to appear correctly in queries. Therefore, the Double type should be used even if this is not considered the best practice for semantic model development.
Conceptually, an ontology should model business ideas, not mirror tables. Instead, it should represent business concepts. For example, when we build a Power BI dashboard, we often define measures like Sales calculated as unit price minus discounts. With an ontology, the system works best when the business meaning behind those calculations is explicitly defined as concepts, rather than relying only on embedded formulas. In other words, part of the ontology design process is extracting business logic from technical definitions and expressing it as structured knowledge. This may require adjustments from semantic models designed for Power BI reports alone.
If you are planning agent rollout alongside ontology design, our Data & AI Activation work follows the same sequence: certify semantic models first, then extend them into Fabric Ontologies so agents inherit governed business context.
Retail case study: from semantic model to Fabric data agent
To better illustrate how ontologies and AI agents can work together in Microsoft Fabric, consider a simplified scenario involving a retail company.
Imagine a company that operates multiple retail stores across different regions. The organization collects large volumes of data from sales and inventory. This data is stored in Microsoft Fabric, where a Power BI semantic model is created to support analytical dashboards and reporting.
While these dashboards provide valuable insights, business users still frequently rely on analysts to answer ad-hoc questions such as:
- Which stores have declining sales this quarter?
- Which products generate the highest profit margins?
Traditionally, answering these questions requires analysts to translate business requests into technical queries, typically written in SQL or expressed as DAX calculations within the semantic model.
To improve data accessibility and reduce this dependency on technical translation, the company generates an ontology based on the existing Power BI semantic model. Rather than representing information only as tables and columns, the ontology defines business entities and the relationships between them. Examples of entities might include Store, Product, Customer, and Order, while relationships describe how these entities interact within the business.
Within this ontology, key business concepts such as Revenue, Discount, and Profit are defined explicitly instead of being embedded solely in technical calculations. This approach creates a semantic representation of how the organization operates, capturing both the data and its business meaning.
An AI data agent is then created within Microsoft Fabric and connected to the ontology. Business users can now interact with the system using natural language by asking questions such as:
- “Which stores have the highest revenue growth this month?”
- “Which products sell the most during promotions?”
- “Which regions show declining customer retention?”
The AI agent interprets these questions, maps them to the relevant concepts defined in the ontology (such as Store, Revenue, Promotion, and Customer), and automatically generates the appropriate queries to retrieve the required information. As a result, users can access insights more directly, without needing to understand the underlying data structure or query languages.
Risks and limitations
-
Over-automation without human oversight - AI agents can automate analysis and generate insights, but excessive automation without human review can lead to incorrect conclusions. Operations agents rely on large language models (LLMs) to create playbooks and reasoning steps. Since LLM-based AI services are probabilistic and can be fallible, their outputs should always be reviewed carefully.
-
Monitoring “silent reasoning” - Another challenge is understanding how an AI agent arrived at a particular answer. If reasoning happens silently within the model, errors may go unnoticed. Organizations should implement monitoring mechanisms and validation processes to ensure results remain trustworthy.
-
Semantic model limitations - Currently, only Direct Lake semantic models are accessible to AI agents for entity and relationship binding. This limitation excludes a large portion of existing semantic models and can prevent scenarios where organizations want to access data where it already resides using DirectQuery instead of duplicating it into OneLake.
-
No automatic ontology building - Building a meaningful ontology requires agreement on business definitions and governance processes. This can be labour-intensive, especially for organizations that do not already have mature semantic models.
-
OneLake-centric dependency - Fabric’s architecture is heavily centred around OneLake. Except for shortcuts to Delta Parquet files that can remain external, most data must reside in OneLake. This raises questions for organizations with large investments in platforms such as Google BigQuery, Teradata, Snowflake, SQL Server or Azure SQL Database. Even when creating shortcuts to formats like CSV, Parquet or JSON stored in S3 or Google Cloud Storage, the transformation process often copies the data into OneLake. For some companies, this architectural shift may require significant planning.
What does the future look like?
The combination of ontologies and AI agents suggests a shift in how organizations interact with data. Instead of dashboards being the primary interface, the interface increasingly becomes conversation. Users ask questions and the AI systems interpret those questions through an understanding of the business.
Microsoft Fabric appears to be moving steadily in this direction. The integration of Copilot, AI agents and ontologies indicates a broader strategy to embed generative AI directly into analytics workflows.
In the future, Fabric’s ontology will integrate with Fabric Activator, enabling automated, event-driven alerts that monitor properties across all instances of an entity type to ensure continuous oversight. Fabric’s users will also be able to auto-generate ontologies from multiple semantic models.
