Semantics vs ontology vs context engine: what they are and when to use each

Sit in any AI or data meeting this year and you'll hear three words used as if they're interchangeable: semantics, ontology, and context. Someone wants a "semantic layer." Someone else says what they really need is an "ontology." A third person insists the whole thing is a "context engine" problem. Everyone nods. Nobody agrees, because nobody is talking about the same thing.

They are not the same thing. They sit at different levels, they answer different questions, and if you're putting AI agents on top of your company data, mixing them up is how you end up with a chatbot that confidently reports the wrong revenue number.

Here's the short version before we dig in:

• A semantic layer tells you what a number means. One trusted definition of "revenue," used everywhere.
• An ontology tells you how the business fits together. The concepts, the relationships between them, and the rules they follow.
• A context engine decides what an AI model sees right now. The right facts, at the right moment, for the exact question being asked.

And there's a fourth word that keeps crashing the party, the knowledge graph, which is really just what you get when you take an ontology and fill it with actual data. More on that below.

The semantic layer: what does this number mean?

Start with the most concrete one. A semantic layer is a single, governed place where your business definitions live. What counts as an "active customer." How "gross margin" is calculated. Which tables to join, and on which keys, to get "monthly recurring revenue."

The point is consistency. Without it, the finance dashboard, the sales report, and the AI assistant all compute revenue three slightly different ways, and you spend the next meeting arguing about whose number is right instead of what to do about it.

A quick example. Say "net revenue" means gross bookings minus refunds minus platform fees, recognised in the month the service was delivered. In a semantic layer you write that definition down once, as a reusable metric. Every tool that asks for net revenue gets the same answer, whether it's a human in a BI tool or an agent writing SQL on the fly.

Reach for a semantic layer when: you have dashboards and analysts disagreeing on basic numbers, or you're about to let an AI tool query your warehouse and you do not want it inventing its own math. This is the floor. Almost everyone building AI on structured data needs one, and most people should start here.

What it does not do: a semantic layer knows that "customer" is a thing you can count, but it doesn't really understand what a customer is, how customers relate to contracts, or that a contract past its renewal date with a high value should be flagged as at risk. For that you need the next layer up.

The ontology: how does the business fit together?

An ontology is a formal model of your domain. It says what concepts exist (customer, contract, product, region), how they relate (a customer signs a contract, a contract covers a product), and what rules apply (every contract must have exactly one paying account; a "strategic account" is any account with more than five active contracts).

The magic word here is inference. Because the relationships and rules are written down formally, the system can work out things you never stored directly. You never created a "high-risk customer" table, but the ontology knows that a customer with an expiring contract, a high account value, and no renewal booked is high-risk, and it can label them that way on demand. That is reasoning, not just lookup.

A quick example. In a plain database, "this account belongs to a parent company in Germany, which is in the EU, so EU data rules apply" is three separate joins you have to remember to write. In an ontology, "Germany is part of the EU" is a fact the model already holds, so anything true of EU accounts is automatically true of this one. You get the conclusion for free.

Reach for an ontology when: your questions span many connected entities and need real logic, not just aggregation. Risk scoring, fraud rings, drug interactions, supply-chain dependencies, "which of our customers are indirectly exposed to this supplier going under." Anywhere the interesting answer lives in the relationships rather than in a single table.

The catch: ontologies take real modelling effort and real expertise. Done well they are powerful. Done as a box-ticking exercise they become an expensive diagram nobody uses. Don't build one because it sounds sophisticated. Build one when the reasoning genuinely pays for the work.

The knowledge graph: the ontology, filled in

Quick detour, because this word is everywhere and it confuses people. An ontology is the schema: the empty model of concepts and rules. A knowledge graph is that model with the actual data poured in. Real customers, real contracts, real connections between them, stored as nodes and edges you can walk across.

The way to hold it in your head: the ontology is the blueprint, the knowledge graph is the building. You design the blueprint once. You instantiate it into a graph you can actually query, hop across, and hand to an AI system when it needs to trace how things connect. Most serious ontology work ends up materialised as a knowledge graph, which is why the two get mentioned in the same breath.

The context engine: what matters right now?

This is the newest of the three, and the one people find slipperiest, because it lives at runtime rather than in your data model.

A context engine is the machinery that assembles what an AI model sees on each and every call. Not everything you know. The right slice, for this user, this question, this moment. It pulls the relevant documents, the relevant metrics, the relevant slice of the graph, plus the user's permissions, recent activity, and whatever memory matters, and it packs that into the model's limited attention budget.

Why it exists: a model can only pay attention to so much at once. Stuff the whole company into the prompt and quality drops. The model gets slower, more expensive, and more likely to miss the one line that mattered. The whole craft, sometimes called context engineering, is finding the smallest set of high-signal information that gets you the right answer. Gartner flagged it as a breakout AI capability for 2026, and it's why "context" has become the word of the year in AI circles.

A quick example. A support agent asks your AI assistant, "should we give this customer a refund?" A good context engine quietly gathers: this customer's plan and payment history, your actual refund policy, their last three tickets, and the fact that the person asking is a tier-one rep who can approve up to a certain amount. It leaves out the other ten thousand customers, the marketing copy, and the engineering docs. Same underlying data as everyone else, but shaped for this decision.

Reach for a context engine when: you're building agents or assistants and you've noticed they either hallucinate (too little context) or get vague and slow (too much of the wrong context). If your data foundations are solid but the AI on top still feels unreliable, this is usually the missing layer.

Notice the dependency. A context engine is only as good as what it draws from. Feed it a clean semantic layer and a well-built graph and it has trustworthy material to select from. Point it at a swamp and it will faithfully hand your model the swamp.

So, when do you use what?

The honest answer is that these stack, they don't compete. Here's the whole thing on one screen:

If you're deciding where to spend next quarter, here's the rule of thumb:

• Numbers that don't agree across the business? Start with a semantic layer.
• Questions whose answers live in how things connect and infer? Add an ontology, materialised as a knowledge graph.
• Solid data but flaky AI agents on top? Invest in a context engine.

Most teams over-reach. They hear "ontology" at a conference and try to model the entire enterprise before they've even agreed on what revenue means. Go bottom up. Nail your definitions, connect what genuinely needs connecting, then get good at feeding the right slice to your models.

The out-of-the-box tools

You don't have to build any of this from scratch anymore. The big platforms now ship a product for each layer, and it's worth knowing which is which so you don't buy an ontology tool when what you needed was a metrics layer.

Databricks

Databricks has arguably moved fastest here, and it covers all three layers.

• Unity Catalog Business Semantics is the semantic layer. The core object is a metric view, written in YAML, that cleanly separates dimensions (what you group and filter by) from measures (the numbers you report). Metric views went generally available in April 2026, so your definitions live in the catalog and everything downstream inherits them.
• Genie Ontology, announced at the Data and AI Summit in June 2026, is a continuously learned context layer that sits on top of those semantics and grounds Databricks' Genie assistant in your business meaning.
• Ontobricks (a Databricks Labs open-source project) is the ontology and knowledge-graph piece. It turns Unity Catalog tables into a materialised knowledge graph: design an ontology visually, map it to your tables, run OWL reasoning and validation, and expose the whole graph to AI agents over MCP. If you live on Databricks and want the full stack, this is the closest thing to one-stop.

Google Cloud

Google's entry is Knowledge Catalog, which was called Dataplex until it was renamed in April 2026. Google markets it, in almost these exact words, as "a universal context engine for your enterprise." It's Gemini-powered, harvests metadata across BigQuery, Looker and friends, extracts entities and relationships from both structured and unstructured data, and builds what they call a context graph to ground agents and cut hallucinations. It leans hardest into the context-engine framing of the three, with the semantic and graph pieces feeding it underneath. (Note: the older standalone Data Catalog service began a phased shutdown in June 2026, so new work should target Knowledge Catalog.)

AWS

AWS is more of a toolbox than a single product, which fits its style.

• Amazon Bedrock Knowledge Bases is the context/retrieval engine. Its GraphRAG capability, now generally available, automatically builds a graph of entities and relationships from your documents in Amazon Neptune Analytics and uses it to give models richer, multi-hop context. Great when you want the graph managed for you.
• Amazon Neptune on its own is where you go when you want to hand-model an ontology and control the graph yourself, rather than letting the system infer it.
• SageMaker Catalog (the old DataZone) covers the governance and business-context side.

The trade-off is real: Bedrock Knowledge Bases gives you a graph with almost no effort but little control over how it's built, while going to Neptune directly gives you full control at the cost of doing the modelling yourself.

Worth knowing beyond the big three

• dbt Semantic Layer and Cube are popular, warehouse-agnostic semantic layers if you don't want to be locked to one cloud.
• Palantir Foundry built its entire platform around the Ontology concept and is probably the most opinionated take on it.
• timbr and similar tools specialise in the "semantic layer plus ontology plus knowledge graph" middle, often as a virtual layer over your existing warehouse.

How to actually stack them

Put simply: the semantic layer defines your terms, the ontology defines how those terms relate and what can be inferred, the knowledge graph holds the connected facts, and the context engine picks the right subset and hands it to the model. Each one makes the layer above it better. Skip the foundations and the impressive-sounding top layer just fails faster.

If you're starting today, resist the urge to boil the ocean. Pick the ten metrics your business argues about most and define them once. Connect the handful of entities where the relationships genuinely matter. Then, and only then, worry about context engineering to feed it all to your agents. That order is boring, and it's also the one that works.

Sources

• Semantic Layer vs Ontology vs Knowledge Graph vs Context Graph (timbr)
• Ontology vs Semantic Layer: how to choose (Atlan)
• What is context engineering (Atlan)
• What are Metrics in Unity Catalog (Typedef)
• What's new with Unity Catalog, Data + AI Summit 2026 (Databricks)
• Ontobricks (Databricks Labs, GitHub)
• Knowledge Catalog (Google Cloud)
• Bedrock Knowledge Bases GraphRAG with Neptune (AWS)