Key Takeaways
- A business ontology is an approved, machine-readable map of your business: its entities, their properties, how they relate and the rules that apply.
- It exists because two AI agents with accurate data can still give the board two different answers if they define 'active customer' differently.
- Snowflake (Business Ontology, private preview, November 2026) and Microsoft (Fabric IQ ontology) both now ship one for agents.
- Start with the ten to twenty terms that appear in board papers, give each a named owner, and version them like code.
It is Monday's operations review at a Hong Kong logistics group. The finance agent reports an on-time delivery rate of 94%. The customer service agent, asked the same question five minutes earlier, said 87%. Both pulled from the same warehouse system. Both are, technically, correct.
The gap is not a model failure. Finance counts a delivery as on time if it arrives on the promised day; customer service counts it against the two-hour slot the customer chose. Nobody wrote down which definition the company actually uses, so each agent picked one. That missing agreement is what a business ontology fixes.
What is a business ontology?
A business ontology is an organisation-wide, machine-readable vocabulary of your business. It defines the things you care about, such as customers, orders and stores, the facts about each, how they relate, and the rules that govern them, so that every person, report and AI agent uses one approved meaning.
Microsoft's own training material on Fabric IQ puts it plainly: an ontology defines the things in your environment as entity types, the facts about those things as properties, and the connections between them as relationships, such as 'Customer places Order'. The key difference from a departmental data model is scope. A sales dashboard model serves one reporting domain; an ontology standardises a concept once and reuses it everywhere.
For an executive, the simplest way to think about it is a contract. The ontology is the written agreement on what your business words mean, stored in a form that software can read and must obey.
Why does a business ontology matter for AI agents now?
Because enterprises are moving from one chatbot to many agents built by different teams on different platforms. Each agent brings its own interpretation of customer, order or region, and when those interpretations diverge, agents give confident, conflicting answers from the same accurate data. The ontology gives them one shared reference.
This is now a vendor priority, not a theory. On 3 November 2026 Snowflake announced Business Ontology at its Expedition 2026 event, an extension of its semantic views that lets organisations set approved definitions for use across the company. Snowflake's stated reason was exactly the scenario above: without a standard definition, two agents could answer the same business question with incompatible results even when both have accurate underlying data. The feature is in private preview.
Microsoft made the same bet earlier. In March 2026 it opened its Fabric IQ business ontology to any vendor's agent through MCP. Amir Netz, CTO of Microsoft Fabric, described the ontology as the explanation you would otherwise have to give a forgetful new colleague every morning.
Analysts quoted in that coverage were candid about the harder part. Independent analyst Sanjeev Mohan argued that the challenge is organisational rather than technical: making the context layer reliable and trustworthy. That is the part no platform can buy for you.
How does a business ontology work?
An ontology sits between your data stores and your AI agents. Agents ask questions in business terms, the ontology translates those terms into the correct tables, joins and filters, applies the agreed rules, and returns an answer grounded in the approved definition rather than the agent's own guess.
The four building blocks
- Entities: the nouns of your business, for example Customer, Policy, Shipment, Property Unit.
- Properties: the facts about each entity, for example a shipment's promised date and delivered timestamp.
- Relationships: how entities connect, for example a Customer holds many Policies; a Shipment belongs to one Contract.
- Rules and metrics: the approved logic, for example 'on time means delivered within the customer-selected slot'.
In practice, platforms generate a first draft from existing semantic models or data catalogues, and people then rename technical tables into business terms, confirm keys and bind each concept to its source data. Microsoft's guidance notes that the quality of the starting model directly reduces the clean-up work. A well-named data model produces a cleaner ontology.
Once published, the ontology becomes a query surface. An agent no longer needs to know that 'active customer' lives across three tables with a 90-day filter. It asks for active customers, and the ontology supplies the definition the business signed off.
How is a business ontology different from a semantic layer, RAG or a knowledge graph?
They solve different problems. A semantic layer standardises metrics for reporting tools. RAG retrieves relevant passages from documents. A knowledge graph stores connected facts. An ontology defines what business concepts mean and how they relate, so it often sits underneath a knowledge graph and alongside RAG rather than replacing either.
| Approach | What it answers | Best for | What it does not do |
|---|---|---|---|
| Semantic layer | How is this metric calculated? | Consistent BI dashboards | Usually scoped to analytics, not agent actions |
| RAG | Which document passage is relevant? | Policies, contracts, manuals | Does not define live business state |
| Knowledge graph | What is connected to what? | Relationship discovery | Needs an agreed schema to stay consistent |
| Business ontology | What does this term mean here, and what rules apply? | Grounding many agents in one vocabulary | Does not fix poor source data |
Netz drew the RAG line clearly in the VentureBeat interview: retrieval suits large document collections such as regulations and handbooks, but it does not tell an agent the current state of the business. Mature enterprise designs use both: RAG for documents, the ontology for definitions and live operational meaning.
Leaders who have funded a semantic layer for Power BI or Tableau are not starting from zero. That work is usually the best seed for the ontology.
What does a business ontology look like in a Hong Kong enterprise?
It usually starts small and practical: a governed list of the twenty or so terms that drive board reporting and customer commitments, each with a definition, an owner, source systems and approved calculation logic, published where every agent and dashboard must read from it.
Financial services
An insurer has 'customer' defined one way in the policy admin system, another way in the CRM and a third way in the claims platform. Before letting an agent draft retention offers, it agrees one definition of customer, one of lapsed policy and one of household. The agent's recommendations immediately become comparable across channels.
Property management
A property manager running agents for tenant enquiries and leasing needs one meaning for 'vacant unit'. Is a unit with a signed but not-yet-started lease vacant? If the leasing agent says yes and the enquiry agent says no, a prospective tenant gets two answers in one afternoon.
Professional services
A consultancy defines 'billable utilisation' and 'matter' once, so that the agent preparing partner reports and the agent chasing unbilled time are measuring the same thing.
Personal data deserves explicit attention here. The ontology is also where you can mark which entities and properties are personal data and who may use them. That supports the data-minimisation and governance practices set out in the PCPD's Model Personal Data Protection Framework for AI, because the rule is attached to the concept rather than re-implemented in every agent.
What do leaders get wrong about business ontologies?
The common mistakes are treating it as an IT data-modelling project, trying to model the whole company before shipping anything, leaving definitions without a business owner, and assuming a platform feature will resolve disagreements that are really about how departments measure performance.
- Delegating it entirely to IT. Engineers can bind data, but only the business can decide what 'on time' or 'active' means. Definitions without a business owner drift back into departmental versions.
- Boiling the ocean. An ontology covering every table is a two-year project that never ships. One covering the terms in your monthly board pack can be useful in weeks.
- Hiding the politics. Conflicting definitions often reflect different incentive schemes. Expect a negotiation, and escalate it to the executive who owns the KPI.
- No versioning. Definitions change when strategy changes. VentureBeat's analysis argued that the ontology must be built, versioned and governed with the same discipline as a data pipeline. Treat a definition change like a policy change, with an effective date.
- Buying the platform first. Snowflake, Microsoft and Databricks each now position an ontology or context layer. Choose after you know your terms, not before.
How should you start building a business ontology?
Pick one agent use case with real money attached, list every business term that agent needs, agree a definition and owner for each, bind them to source data, and measure whether answers become consistent. Expand to the next use case only after the first set of definitions holds.
- Week 1 to 2: collect the terms from your board pack and the chosen agent's prompts. Most organisations find ten to twenty that matter.
- Week 3 to 4: run a definition workshop per term with finance, operations and the system owner. Record the decision and the owner.
- Week 5 to 6: bind each term to source data in whichever platform you already run, and point the agent at it.
- Ongoing: test the agent against known answers monthly, and report the consistency rate upward as a KPI.
The timeline is a planning guide rather than a benchmark; organisations with weak source data should expect the binding step to take longer.
One vocabulary, many agents
Every enterprise already has an ontology. It lives in people's heads, in spreadsheet footnotes and in the arguments that start every operations review. AI agents simply make the cost of that informality visible, because they repeat each department's version at scale and with total confidence.
The leaders getting value from agents in 2026 are not those with the most models. They are the ones who decided, in writing, what their business words mean, and made every agent read from that page.
Empowering AI. Centered on you.
Start with one role and one set of definitions
An AI employee is only as reliable as the business terms it works from. Book a free AI employee configuration assessment and we'll walk you through every step, from agreeing the definitions your first AI role needs to deploying it on Hong Kong servers or your private cloud.
Frequently Asked Questions
Do we need Snowflake or Microsoft Fabric to have a business ontology?
No. Those platforms make it easier to publish one to agents, but the hard work is agreeing definitions and owners. That can start in a governed glossary and move to a platform once the terms are stable.
Is a business ontology the same as a data dictionary?
Not quite. A data dictionary describes columns in a system. An ontology describes business concepts across systems, including their relationships and rules, in a form AI agents can query directly.
Who should own the business ontology?
Each definition should be owned by the executive accountable for that KPI, with a data team maintaining the technical bindings. A small governance group resolves conflicts and approves changes.
Does an ontology help with PDPO compliance?
It can. Tagging personal data at the concept level lets you apply access and minimisation rules once, rather than in every agent, which supports the governance approach in the PCPD's AI framework. It does not replace a privacy assessment.
How do we measure whether the ontology is working?
Track answer consistency: ask several agents the same set of business questions each month and record how often they agree with the approved figure. Rising consistency is the clearest signal to report upward.