You have started hearing both terms in the same meeting, sometimes from the same person, about the same platform. Here is what each one actually does, taught plainly, and why the difference decides what your AI agents can and cannot do.
If you only have a minute:
- What it is. A semantic layer is the one place your company defines a metric, like revenue, so every tool that asks gets the same number. An ontology is a map of the things your business runs on, customers, orders, contracts, and how they connect, so a person or an agent can walk from one to the next.
- How it works. A semantic layer wraps a formula around your data. An ontology wraps a graph around your data. No formula required, just entities and the relationships between them.
- What it solves. A semantic layer stops three teams from reporting three different revenue numbers in the same quarter. An ontology lets an agent answer a question nobody built a report for, by following a relationship instead of fetching a metric.
- Do you need one. If your teams argue about what a number means, you need a semantic layer, and that problem is solved and off the shelf. If you want an agent to reason across entities instead of just looking up figures, you need an ontology too, and that part of the market is younger than it looks.
- Why you care. An AI agent's answer is only as trustworthy as the semantic layer underneath it, and only as capable as the ontology it can traverse. An agent running on neither is a fluent guesser, whichever vendor's logo is on the chat window.
Ask an AI assistant sitting on top of your company's data what last quarter's revenue was, and it gives you a clean number, matching the figure finance already signed off on. Ask the natural follow-up, something like which of the accounts that hit that number are also flagged as churn risks, and it goes quiet, or worse, it guesses.
The first answer came from a layer built to do exactly that job. The second question needed a different layer, one that most companies rolling out AI agents this year have not built yet. Confusing the two, or assuming the first one covers the second, is an expensive mistake being made in board decks right now.
This is the second in the series I am calling "What Is... And Why Do I Care?" I keep watching sharp people approve things they cannot define. Last time it was the AI second brain. This time it is two terms that get used interchangeably by the people building your data platform, which should worry you more than if the terms were unrelated.
Here is the plainest answer I can give. A semantic layer is the one place your company defines what a metric means and how to calculate it, so every tool that asks gets the same number back. An ontology is a map of the things your business runs on, customers, orders, contracts, and how they connect to each other, built so a person or an agent can walk from one to the next. One makes a number trustworthy. The other makes an entity navigable. People conflate them because both are giving meaning to raw data, just at different altitudes.
Picture two documents living in the same building. One is the single certified calculator every department has agreed to trust when someone asks what revenue was this quarter, the number nobody argues with because everyone can trace it back to the same formula. The other is the company's org chart and case files, wired together so that this customer connects to these three orders, this order connects to that contract, and anyone tracing a case can follow the thread without needing a formula at all. The calculator answers a number question. The org chart answers a what-connects-to-what question.
How it works
Follow one thread through both layers: a customer, the orders they placed, and the revenue those orders add up to.
The semantic layer, up close. A raw data warehouse just has tables: an orders table, a customers table, a column called net_amount. Ask two different tools what revenue means and, without a semantic layer, you can get two different SQL queries and two different numbers, because one analyst excluded refunds and the other forgot to. A semantic layer fixes that by defining the metric exactly once, in one place, and forcing every downstream tool to ask that one place instead of writing its own formula.
dbt's own description of its Semantic Layer states the intent plainly: define business logic once, so every downstream tool queries that single definition rather than reinventing it. Under the hood, dbt's MetricFlow engine compiles that one definition into SQL on demand, so switching BI tools never means redefining revenue from scratch. Looker's LookML does the same job under its own name, and Power BI ships an equivalent as its semantic model. Three different products, one shared job: make sure revenue means the same thing everywhere it is asked. This part of the market is mature. It is not the part where the interesting mistakes are happening.
The ontology layer, up close. A semantic layer only ever had to know how to add up a column, never that a customer places orders in the first place. An ontology exists to capture that relationship on purpose, as a first-class thing, not a side effect of a query.
Palantir built the clearest version of this, years before AI agent was a phrase anyone used, inside its Foundry platform. Its Ontology splits into semantic elements, objects, properties, and the links between them, and kinetic elements, the actions and functions that can change them: what a thing is, kept apart from what you are allowed to do to it. Customer, Order, and the places relationship between them are exactly this shape, objects and a link, no formula involved.
That same object-property-link vocabulary keeps showing up independently across the industry, which is a stronger signal than any one vendor saying it alone. Microsoft's Fabric IQ, an ontology capability previewed at its Ignite conference and expanding through 2026, defines an ontology as entity types (like Customer), properties, and relationships (like Customer places Order), binding it directly to the semantic layer underneath. Different company, same structure, the same graph-on-top-of-calculator shape.
You will also see the two terms blurred on purpose. Stardog, a graph database vendor, describes its own product as The Knowledge Graph-Powered Semantic Layer on its own homepage, folding both words into one pitch. If the distinction in this article felt slippery before you read it, that is not you being behind. The vendors have not agreed on the words either. Neo4j, by contrast, is a general-purpose graph database and does not brand itself around ontology or semantics at all, a useful reminder that graph alone does not mean the same thing as ontology.
What problem it solves
Keep the two problems separate, because the fix for one does nothing for the other.
Only 1% of senior data and technology leaders say getting a consistent definition of a basic business metric across their own tools is not a challenge. 45% call it moderately hard. 38% call it slightly hard. Every difficulty tier has people in it, except solved.
Source: Strategy and CIO Dive, "Data, AI & Analytics Trends Across Organizations in 2026," survey of 100 senior leaders
A semantic layer solves that problem, and only that one. It settles which revenue number is correct before an agent ever gets involved, instead of after two departments have already staked their credibility on different answers. If your organization has that argument regularly, buying or building a semantic layer is not a research project. dbt, Looker, and Power BI all sell a version of it today, and the fix is mostly discipline: agree on the definition once, put it in the tool, stop letting people write their own formulas.
An ontology solves a different problem: giving an agent something to walk across. Ask a well-built semantic layer what was Q3 revenue and it answers instantly, because that is precisely the shape of question it was built for. Ask it which customers who hit their revenue target last quarter are also flagged as churn risks, and it has nothing to stand on, because that question needs two different kinds of records connected to each other, not one metric computed correctly. A semantic layer only has columns and formulas, no concept of customer as a thing with relationships.
Here is what actually happens when both layers exist and an agent gets that question. It walks the ontology first, following the Customer node out to whichever flag marks a churn risk, and comes back with a short list of names. Then it hands that list to the semantic layer and asks the one question the semantic layer is built for: did each of these hit their revenue target, using the same formula finance already trusts. The agent reports back the intersection. Neither layer could have answered the question alone: the ontology cannot compute a target, and the semantic layer cannot follow a flag.
That second kind of question is exactly what an ontology exists to answer, and it is exactly the kind of question your AI assistant is going to get asked once people stop treating it like a fancier search box. The metric-only failure mode is loud and easy to catch, three numbers on a slide that do not match. The relationship-only failure mode is quieter and worse: the agent answers fluently, sounds certain, and is reasoning over a pile of unconnected facts because nobody ever told it that this order belongs to that customer.
Do you need one?
Almost certainly the semantic layer. The ontology, only if you have a real reason, and the two questions that decide it are different enough to need separate tests.
For the semantic layer: can you name a metric your own teams argue about? Revenue, active customer, qualified lead, anything where two people pull different numbers for the same quarter. If yes, buy one. It is a solved, boring, off-the-shelf category, and there is no good excuse left to still be having that argument in 2026.
For the ontology: does your agent's best trick end at here is the report, or can it answer a question that requires connecting two different kinds of records nobody thought to pre-build together? If every useful thing your AI assistant does is really a lookup wearing a conversation's clothes, you do not have an ontology problem yet. You have a very well-organized calculator, and that is a fine place to be.
If you do have that problem, know what you are buying into rather than find out three months in. Fabric IQ's ontology capability is in public preview as of this writing. Palantir sells its version as part of a full platform commitment, Foundry, not a feature you switch on inside a tool you already own. This is closer to where semantic layers were five years ago than where they are now: real, useful, and still being built out in public.
Most organizations need the semantic layer today and the ontology on a one-to-two-year horizon, not both on the same procurement cycle. Building an ontology before your metrics are trustworthy just gives you a beautifully connected graph full of numbers nobody agrees on.
What this is really about
Strip away the vendor names and this is the whole article in one sentence: an AI agent's usefulness is bounded by whichever of these two layers it is actually standing on, and no logo on the chat window tells you which.
An agent answering from a clean semantic layer sounds sharp because the number underneath it is trustworthy. An agent answering without an ontology to traverse is still fluent, still confident, and quietly limited to whatever a single table or a single pre-built report already contains. The demo cannot tell you which one you are looking at. Only the architecture underneath it can. Before the next AI agent pitch, from any vendor, ask which of these two layers it is actually standing on, and whether the second one is a shipped capability or a preview with a roadmap attached.
What to do this week
Find your loudest metric argument. The number two teams cannot agree on in the same meeting. Put it in a semantic layer this quarter. This is the cheap fix and there is no reason to still be doing it by hand.
Ask what your agent's best trick actually is. If every impressive answer traces back to a pre-built report, you have a semantic layer working well and no ontology at all, a fact worth knowing before you buy the next thing rather than a failure.
Ask any AI vendor which layer they are standing on. Semantic layer alone, or semantic layer plus ontology, and if it is the ontology, ask whether it shipped or is still a preview. The honest vendors will tell you straight.
Read the actual documentation before either purchase. Not the deck. The page that defines the entity types and the relationships, or the page that defines the metric calculation. Fifteen minutes there will tell you more than a demo will.
So, the four questions, answered. What is a semantic layer versus an ontology? One is a single trusted definition for a metric. The other is a map of your business's entities and how they connect. How do they work? A formula wrapped around your data, and a graph wrapped around your data. What problem does each solve? One ends the argument about whose number is right. The other lets an agent answer a question no report was built for. And do you need one? You almost certainly need the semantic layer now. You need the ontology once your agent's next good question can no longer be answered by a report.
Matthew Kruczek is Managing Director at EY, leading Microsoft domain initiatives within Digital Engineering. Connect with Matthew on LinkedIn to discuss how your organization should sequence its semantic layer and ontology investments before the next AI agent rollout.
References
- Palantir, "Ontology overview," Foundry documentation, accessed August 2026.
- Microsoft Learn, "Fabric IQ ontology overview," published October 2025, updated July 2026.
- dbt Labs, "dbt Semantic Layer," accessed August 2026.
- Strategy and CIO Dive Studio, "Data, AI & Analytics Trends Across Organizations in 2026," survey of 100 senior data and technology leaders across financial services, retail, technology, manufacturing, and healthcare, 2026.
- Stardog, homepage product positioning, accessed August 2026.
- Neo4j, product documentation and positioning as a general-purpose graph database, accessed August 2026.
