Ontology or Semantic Layer? What an AI Agent Needs From Both

Put one question to three sources, how much revenue came in, and the replies often differ: 10.2M from finance, 10.4M from marketing, $9.8M from the AI helper inside Slack. Nobody agrees. Humans used to settle this over a short meeting. An agent will not ping a coworker to ask what a metric means, so when it meets a column named rev_ttm_adj_v2 it makes something up or grabs whichever definition shows up first.

Feeding modeled domain knowledge into retrieval has reportedly lowered hallucination rates by roughly 40%. That holds only if the knowledge exists in a modeled form, and not just in the memory of the few people who built the tables. Storage volume and agent skill matter little when raw tables and SQL are all that sits in between, because the business will not rely on what comes out.

The context layer

The context layer names a function, not a product. It gathers semantic definitions, domain knowledge, lineage, governance policy, quality signals and certification status and exposes them through one interface for people and agents alike.

Ontologies and semantic layers do most of the work here. Vendor marketing often blurs them together, but each addresses a different problem, and building them in the wrong sequence yields AI projects that look great in a demo and stall before production.

Division of labor in one line

Short version: the semantic layer handles questions like how much revenue there was, while the ontology handles questions like what a customer even is.

The semantic layer is responsible for metrics. It fixes how revenue, monthly active users and lifetime value are worked out, which joins to use and which filters to apply, so that all teams and tools get identical results.

The ontology is in charge of meaning. It says what counts as a customer, how customers connect to orders, what makes someone Platinum, and whether software can infer fresh conclusions from facts already stored.

Ontology: concepts, relationships, reasoning

The textbook definition, an explicit formal specification of a shared conceptualization, reduces to three parts:

• Classes: the types of entity in the domain, for example Customer, Product, Order, Region.
• Properties and relationships: how those things connect. A customer places an order, and a product belongs to a category.
• Axioms and rules: logical constraints. Every order contains at least one product, and a customer belongs to exactly one region at any moment.

Ontologies are written in W3C standards like RDF and OWL, so machines can reason over them as well as read them. Suppose the ontology says a Platinum customer has annual revenue above 1M and the facts say Acme earns 2M. The engine concludes by itself that Acme is Platinum, and nobody wrote the if-else. Semantic layers and BI tools cannot do this. They run calculations defined in advance and never derive a fact that was not defined.

Ontologies also bridge vocabularies between systems. A CRM says Customer, an ERP says Client, finance says Account, and the ontology maps all of them to a single business object. An agent grounded this way follows a connected graph in place of guessing across disconnected tables. In healthcare SNOMED CT is the standard instance, in financial services FIBO, and in regulated sectors a formal ontology is nearly mandatory.

The price is just as visible. Palantir made enterprise ontology a market category, yet delivery is heavy going: embedded engineers, manual modeling, anywhere from six to eighteen months for a complete build, and a scarce talent pool in formal logic.

Semantic layer: metrics and numbers that agree

This line of work is the more practical one. Back in the 1990s Business Objects introduced Universe, a way to put business vocabulary in front of tangled schemas. The underlying issue persists: revenue gets calculated in different ways, figures clash and confidence drops. Today the stakes are higher, since a mismatch used to yield one awkward slide and can now yield an invented number in a report that drives decisions.

A modern semantic layer has four parts:

• A metadata repository, mapping something like mrr_calc_v3 to monthly recurring revenue.
• A business logic engine, holding metric formulas in one place so they are defined once and reused.
• Query translation, which generates joins and filters.
• Access control, applying row- and column-level permissions consistently.

Tooling has moved fast. dbt added a Semantic Layer powered by MetricFlow, which keeps metric definitions in YAML under version control and compiles them to several SQL flavors. In September 2025 Snowflake, Salesforce, dbt Labs and BlackRock started the Open Semantic Interchange (OSI) effort, and its 1.0 release in January 2026 gave a neutral format for swapping semantic metadata. Products such as Cube, AtScale, LookML, DAX, Databricks Metric Views and Snowflake Semantic Views all point to the same direction, which is that the semantic layer is turning into ordinary plumbing for AI-ready data stacks.

There is a limit, though. The layer can say precisely how revenue is computed, but not how a customer connects to a market and its regulations, nor whether an account deserves a high-risk flag under domain rules. Jessica Talisman, writing in Metadata Weekly, framed it neatly: semantic layers handle lookup, ontologies handle context and reasoning.

What breaks with only one

• Semantic layer alone gives accurate but thin answers. Which channel produced the most GMV last month? A precise reply. Why did it decline, or should spending go up? Silence, since nothing models how channels, spend and customer profiles interrelate.
• Ontology alone talks well about concepts and fails on figures. Is Acme Platinum? Sound reasoning. What did Acme bring in last month? Three conflicting answers again, because the system lacks any pointer to the fact table or the aggregation rule.

Industry numbers agree. Gartner predicts that more than 40% of agentic AI projects will be scrapped by the end of 2027 on account of cost, vague value and inadequate controls. Among 248 data management leaders surveyed, 63% admitted they lacked the practices to support AI. The model is rarely the culprit; the data underneath has no semantic grounding.

Momentum runs the other way too. Gartner's 2026 summit forecast universal semantic layers joining data platforms and cybersecurity as critical infrastructure by 2030, and Futurum sees adoption rising from 16% this year to 30% in 2031. Microsoft is previewing built-in ontology support in Fabric IQ, while Timbr.ai sells semantic layers with reasoning added. The two approaches are heading toward each other.

Knowledge graphs and taxonomies

A knowledge graph stores the instances, so actual customers and orders appear as nodes. Think of the ontology as the schema and the knowledge graph as the data itself. An agent that follows relationships at runtime is moving through that graph.

A taxonomy is a stripped-down ontology: hierarchies of parents and children, with no inference and no sideways links. Product catalogs, classification of data domains and PII tagging typically start there, and that is a fine starting point. A full ontology only becomes necessary once an agent must reason across categories, such as asking if a downgrade in category A hits stock in category B.

How the pieces fit

The context layer has two halves:

• Data context: ontology, semantic layer, knowledge graph, lineage, quality scores and access policy. It tells the AI what kind of business it operates in.
• Application context: user preferences, conversation history, domain documents and retrieved facts (memory plus RAG). It tells the AI who it is talking to.

A single question passes through four stages:

1. The ontology defines a concept such as revenue recognition, with its attached rules.
2. The semantic layer converts that into computation: which tables to join and how to aggregate.
3. The knowledge graph links the concept to its metrics, lineage and downstream consumers.
4. MCP delivers the context to the agent at inference time.

Two years of context-engineering discussion converge here: reliable output needs structured context, and ontologies and semantic layers are the two hardest parts. MCP solves delivery, not content. Give an agent ungoverned tables and SQL, and the protocol will carry a hallucination faithfully.

One vendor's approach

One database vendor describes its answer as an open semantic stack, also called OSI, that merges metrics, definitions, raw data, a context graph and an ontology instead of another BI semantic layer. It has three layers:

• Bottom, the semantic layer: metric definitions, calculation rules and mappings from dimensions to data. It builds on the Ant-OSI standard, works with the industry OSI, and already runs in production at Ant Group.
• Context graph in the middle: metrics, objects, events, lineage and consumers connected as a network, which an LLM reasons over measurably better than raw schemas or YAML.
• Ontology layer on top: business semantics aligned with database semantics, with workspace-local terms and enterprise-wide concepts linked while evolving on their own schedules.

The principle beneath it is semantic as code. Define semantics once, then let BI draw dashboards, agents write SQL and governance tools trace lineage, all against the same definition, with no separate semantics for BI, AI and governance. In that vendor's customer trials, natural-language-to-data accuracy came out well ahead of alternatives. The claim is that models do not set products apart, because everyone calls the same frontier LLMs; the quality of semantic context does. Supplying correct business definitions in place of raw tables lifts NL-to-SQL accuracy more than prompt tuning can.

Where to start

Begin with the semantic layer when:

• Teams disagree about what revenue or active user means.
• The project is conversational analytics or chat-with-data.
• The data stack is already centralized and returns are wanted within two to six months.

Begin with the ontology when:

• The organization sits in finance, healthcare or government, with strict compliance demands.
• The AI must reason across domains, such as customer by product by regulation.
• One concept has a different name in half a dozen systems.
• Automated classification or rule-based anomaly detection is needed.

For most enterprises, a practical order is:

1. Build the semantic layer first, centralizing core metrics so BI and AI read identical definitions.
2. Keep the ontology light at first, as a business glossary and not a full OWL effort.
3. Add governance signals: lineage, quality scores, ownership and certification.
4. Expose all of it to agents over MCP, which turns the context layer from a diagram into infrastructure.

dbt will not give an ontology, and a Palantir-style ontology does not suit every team. Growing from a glossary toward a formal ontology is far more realistic than landing everything at once.

The vendor's own roadmap shows the same gradualism. Short term, the semantic layer reaches every workspace, with centrally managed metrics and searchable terminology. Medium term, glossaries, category hierarchies and entity relationships arrive as a taxonomy first, then gain cross-system alignment and basic reasoning, growing domain by domain. The long-term question is what happens when domains that modeled their semantics separately must merge them, and how to keep local and global definitions evolvable.