Pick a semantic layer when an agent needs a governed number, and a knowledge graph when it must trace a path across systems. For an AI architect or data platform lead, the expensive mistake is wiring agents to either one alone: a confident wrong number from an invented join, or a path that ends at the wrong definition of “account” or “revenue.” When one request needs both, the two systems have to agree on what those terms mean. Atlan, the AI Context Platform, links business terms to the metrics that compute them, the lineage beneath those metrics, and the owners who certify them. It serves that context to agents through its MCP server. The semantic layer still calculates the number, and the graph still traces the path.
| Dimension | Semantic layer | Knowledge graph |
|---|---|---|
| What it models | Metrics, dimensions, facts, and logical tables | Entities, typed relationships, properties, and classes |
| Data model | A tabular model over warehouse tables | RDF triples or a labeled property graph |
| What keeps a number correct | Declared formulas, join keys, and grain, so the same metric compiles the same way every time | Whatever the query author or the ontology defines; graph queries aggregate what is stored |
| Missing facts | SQL treats an absent row as absent | OWL reasoning treats an unstated fact as possibly true; SPARQL and Cypher count what is stored |
| Query language | Generates SQL from governed definitions and join paths | SPARQL for RDF, Cypher or GQL for property graphs, or SQL/PGQ in SQL systems |
| Where queries run | In the warehouse or its query engine | In a graph engine or over source tables |
| Best at | Totals, ratios, trends, period comparisons, and governed KPIs | Multi-hop paths, cross-system entities, impact, dependencies, and inference |
| Harder for it | Questions beyond the modeled joins or outside tabular data | Governed metrics with fixed grain, and accurate query generation over large graph schemas |
| Who builds it | Analytics engineers and BI developers | Knowledge engineers, ontologists, and data engineers |
| Typical build effort | Define metrics, dimensions, joins, and access rules | Define concepts, map sources, resolve identities, and maintain relationships |
| Typical failure mode | An explicit scope error, a drifted metric definition, or an agent that picks the wrong metric or filter | An incorrect entity merge, a missing edge, ontology drift, or a plausible but wrong query |
| Standards | SQL plus platform-specific modeling formats | RDF, OWL, SPARQL, GQL, and SQL/PGQ |
| LLM-grounding evidence | A small dbt Labs benchmark reported 100% accuracy on in-scope questions and 0% on questions that needed more entity hops than MetricFlow supported | A small 2023 benchmark beat a raw database schema (DDL) when the graph condition also received ontology-backed business meaning |
| Example products | dbt Semantic Layer, Power BI semantic models, and Snowflake semantic views | Neo4j, BigQuery Graph, and RDF platforms such as Stardog |
Which meaning of semantic layer matters for AI agents?
“Semantic layer” has two established meanings, and they lead to different comparisons.
In analytics, it is a model of metrics, dimensions, and join paths that a compiler turns into SQL against a warehouse. In knowledge management, Enterprise Knowledge (2026) describes a semantic layer framework built on metadata, taxonomies, ontologies, business glossaries, and knowledge graphs that connects knowledge and data assets. For agents, the analytics meaning is the one that matters. It is the infrastructure choice teams face when they build for AI agents, and it is the meaning used from here on.
How does a semantic layer work?
A semantic layer turns a request for a defined metric into a repeatable query against the warehouse.
If an agent asks for net revenue by region for the third quarter of 2026, the layer selects the approved metric formula and follows the defined join path. It then applies the time and region filters and generates SQL for the query engine.
According to Snowflake documentation, semantic views organize logical tables, relationships, facts, dimensions, and metrics, which teams query in SELECT statements, use in Cortex Agents, and share across BI tools. Analytics engineers and BI developers define these objects in YAML, DAX, LookML, or SQL DDL depending on the platform. The boundary between a semantic layer and a metrics layer varies by platform, and Snowflake semantic views and Unity Catalog Metrics follow the same general pattern with different object models.
What makes the numbers dependable is that the hard decisions are made once. According to dbt Labs documentation, MetricFlow uses the entities defined in semantic models as join keys and creates a graph with the semantic models as nodes and the join paths as edges. It picks the join type from the entity types to avoid fan-out and chasm joins, and it supports multi-hop joins with a limit of two hops. A semantic layer already walks a small, governed join graph; it just refuses paths it cannot compute safely. That is why it is the right home for metrics: the formula, the grain, and the join path do not change from one question to the next.
Where do semantic layers stop?
The model’s boundary is also where reliable answers stop. If a question requires an unmodeled join path, a document, an ownership record, or an entity outside the platform, accuracy within the modeled scope does not help.
According to dbt Labs (2026), its semantic layer scored 0% on benchmark questions that required more entity hops than MetricFlow supported, while scoring 100% on questions within scope. On those same out-of-scope questions, dbt’s 2026 test found text-to-SQL scored 70.0% with Claude Sonnet 4.6 and 100.0% with GPT-5.3 Codex. The trade is coverage for predictability: the semantic layer says it cannot answer instead of guessing, and text-to-SQL answers more questions with no guarantee about any single one. dbt ran this test on its own product and one dataset.
Agents can request metrics already defined in the semantic layer through interfaces such as MCP. When serving semantic-layer metrics to agents over MCP, the semantic layer still computes the number; the interface only makes it reachable.
How does a knowledge graph work?
A knowledge graph represents entities and the typed relationships among them. A query matches or traverses a pattern, such as supplier to component to product to account, and returns the connected entities or the path between them.
What does an ontology add to a knowledge graph?
An ontology defines the graph’s classes and relationship types, while the graph data supplies specific entities and connections. According to the W3C OWL 2 Primer, reasoners can automatically compute consequences from an OWL ontology and infer further information, and OWL 2 is not a schema language for syntax conformance. Validation is a separate job: the W3C Shapes Constraint Language (SHACL), a 2017 Recommendation, validates RDF graphs against a set of conditions, including minimum and maximum counts on a property.
The ontology vs. knowledge graph distinction explains how the model and its instances work together. Pick a graph when the question is about how things connect, and keep the number it needs somewhere the formula is fixed.
How do RDF and property graphs differ?
The Resource Description Framework (RDF) represents statements as subject-predicate-object triples. According to the W3C SPARQL 1.1 Overview, SPARQL 1.1 is a set of specifications that provide languages and protocols to query and manipulate RDF graph content. This is the model behind RDF and SPARQL graph platforms such as Stardog.
Labeled property graphs represent entities as nodes and relationships as edges, with labels and key-value properties. According to Google Cloud documentation, GQL is ISO/IEC 39075:2024 and SQL/PGQ is ISO/IEC 9075-16:2023, and BigQuery supports both. The Introduction to BigQuery Graph adds that node and edge tables are built from existing tables or views. Teams can run graph-pattern queries without replicating data into a separate graph database.
Why does the open world matter?
The open-world assumption belongs to OWL reasoning. The same W3C primer explains that a database usually treats a missing fact as false, while in an OWL 2 document the fact may simply be missing but possibly true. SPARQL aggregates and Cypher counts still operate over the facts that are stored.
That assumption suits integration across incomplete sources. If one system has no record of a supplier relationship, an OWL reasoner does not conclude the relationship is false. It is a poor basis for “how many active customers do we have?”, where the population, the grain, and the treatment of missing records must be defined in advance.
What does a knowledge graph cost to build?
Knowledge engineers and ontologists define the concepts and relationships, while data engineers map sources and resolve duplicate identities. Teams must also assign ownership and keep mappings current as source systems change. Many of the pitfalls of building an enterprise knowledge graph show up during this ongoing maintenance, when identities, mappings, or relationships fall out of date.
A practical guide to how to build a knowledge graph for AI agents therefore covers schema design, source mapping, entity resolution, population, query access, and continuous monitoring.
How do GraphRAG and context graphs differ from an enterprise knowledge graph?
Microsoft’s GraphRAG method answers questions across document collections, while an enterprise knowledge graph represents business entities and relationships across systems. According to Edge et al. (2024), the method derives an entity knowledge graph from source documents and pregenerates community summaries for groups of closely related entities. That lets it answer questions directed at an entire text corpus. It is a retrieval and summarization method, and it leaves governed metrics to other systems.
GraphRAG focuses on retrieving and summarizing information from documents. A context graph vs knowledge graph comparison asks a different question: whether the graph also carries runtime signals such as state, policy, and decision history. Neither changes the semantic layer’s job of computing governed metrics.
What does the evidence say about grounding LLMs in each?
The evidence does not show that knowledge graphs beat semantic layers, or the reverse.
Across the cited tests, LLMs did better when they received modeled business meaning or a relevant subset of the schema. Each result is still bounded by its dataset, question type, model, and setup, and none of them isolates a single cause.
What did the knowledge graph benchmark actually compare?
According to Sequeda, Allemang, and Jacob (2023), zero-shot GPT-4 achieved 16.7% average execution accuracy when generating SQL from data definition language (DDL), compared with 54.2% when generating SPARQL against a knowledge graph representation. The benchmark used 43 questions and 13 of 199 tables from an insurance model. Its manually created database held only a couple of rows per table, and the questions used projections and joins without filters.
The conditions differed in more than the query language. The SQL prompt received DDL, while the SPARQL prompt received an OWL ontology describing business concepts and relationships. R2RML mappings virtualized the graph over the same relational tables. The result compares the raw schema with the schema plus modeled meaning, on the same stored data.
SQL scored zero only in the two high-schema-complexity quadrants. The 2023 paper ties low question complexity to business reporting and high question complexity to metrics and KPIs:
| Question and schema complexity (Sequeda et al., 2023) | SQL | Knowledge graph |
|---|---|---|
| Low question, low schema (reporting) | 25.5% | 71.1% |
| High question, low schema (metrics and KPIs) | 37.4% | 66.9% |
| Low question, high schema (reporting) | 0% | 35.7% |
| High question, high schema (metrics and KPIs) | 0% | 38.5% |
How should the 2023 result be read today?
The study is an arXiv preprint, and all three authors were affiliated with data.world, which ran the virtual knowledge graph. The 2023 figures are also a historical baseline: on the same dataset, dbt’s 2026 rerun measured text-to-SQL at 64.5% on its 11-question subset, up from 32.7% for GPT-4 in 2023. The same distinction explains why enterprise text-to-SQL needs business context when physical table and column names do not express the intended relationships.
A follow-up added an ontology-based query check and up to three rounds of LLM repair. According to Allemang and Sequeda (2024), the method reached 72.55% average execution accuracy, returned an unknown result 8% of the time, and had a 19.44% error rate. Those figures describe the follow-up method alone.
What did the semantic-layer replication show?
dbt Labs (2026) reran 11 questions from the 2023 Sequeda benchmark on the same insurance dataset, running each question 20 times on Claude Sonnet 4.6 and GPT-5.3 Codex. With the original data models in that 2026 rerun, text-to-SQL scored 64.5% for both LLMs. The semantic layer scored 72.7% overall in 2026: 100% on questions it could answer and 0% on questions that needed more entity hops than MetricFlow supported.
After an LLM created three additional dbt models, dbt reported in 2026 that accuracy reached 98.2% for Claude Sonnet 4.6 and 100% for GPT-5.3 Codex through the semantic layer. Text-to-SQL on the same modeled project scored 90.0% and 84.1% in the same 2026 test. This was an 11-question, one-dataset test published by dbt Labs, which sells the tested semantic layer. The text-to-SQL condition also received the entire schema as context, which the authors say is not practical for larger datasets. The broader text-to-SQL vs semantic layer choice still depends on whether the question fits the model.
When does graph retrieval help text-to-SQL?
According to Neo4j (2026), retrieving a relevant subgraph of tables, columns, join paths, and business glossary terms cut token use from about 18,000 per call to roughly 1,800 to 7,300. In its three-question demo, with each question run ten times, accuracy on the complex questions rose by about 10 percentage points.
The vendor-authored demo is too small to establish a general accuracy gain. It does show the mechanism: graph retrieval selected a smaller, question-specific slice of the schema before SQL generation. Teams evaluating a Neo4j knowledge graph vs. a managed metadata graph still have to decide who maintains the joins and business terms used for retrieval.
Graph retrieval does not remove the text-to-query problem. According to CypherBench v1 (2024), the benchmark contained 11 property graphs with 7.8 million entities and more than 10,000 questions. In that 2024 evaluation, the best model, Claude 3.5 Sonnet, reached 61.58% execution accuracy, while no model with fewer than 10 billion parameters passed 20%.
What do the numbers add up to?
Taken together, the studies support a narrower conclusion: modeled meaning and relevant schema context improve results over a raw or overbroad schema. An ontology supplied business relationships, additional semantic models brought more questions into scope, and graph retrieval selected only the schema context a question needed.
None of these benchmarks tests a knowledge graph as a replacement for a semantic layer in metric computation. The dbt test also shows the opposite boundary: its semantic layer declined questions that needed unsupported entity hops. The same scope question matters when choosing between Cortex Analyst and custom text-to-SQL.
Which questions need which?
Start with what the question asks the system to do: calculate a number, trace connections, resolve a business definition, or summarize documents. Use this as the default route, then check what your own stack already supports, since many products now cover part of both jobs:
| If the question asks for | Default route | Why |
|---|---|---|
| A number: totals, ratios, trends, KPIs, or period comparisons | Semantic layer | It applies defined metric logic, joins, filters, grain, and aggregation |
| A path: impact, dependency, cross-system identity, or “who else” | Knowledge graph | It follows typed relationships across multiple entities and systems |
| A definition: what a term means, which metric implements it, and who certified it | The layer connecting both | It binds the graph concept to the metric definition and its owner |
| Themes across tickets, contracts, or other documents | GraphRAG or document retrieval | It retrieves and summarizes text rather than computing a metric or traversing enterprise entities |
For questions about themes across tickets or contracts, teams may also weigh a vector database against a knowledge graph. Questions about business definitions expose metric conflicts between analytics teams, such as finance and sales using different rules for “active customer” or “revenue.”
How does one request use both?
Consider this request: “Which of our 50 largest accounts depend on products containing components from the supplier involved in this recall, and how much revenue is at risk?” No single system should answer all of it. It contains four jobs:
- Rank the accounts: The semantic layer applies the approved ranking rule, such as trailing-12-month invoiced revenue, to the whole customer base and returns the 50 largest accounts.
- Trace the dependency: The knowledge graph follows supplier to component to product to account and returns the affected accounts and products.
- Match the identities: A maintained crosswalk maps each account the graph returns to its warehouse account key, so the semantic layer can filter on the same entity. Someone has to own that mapping.
- Calculate the exposure: The semantic layer computes “revenue at risk” with the definition its owner approved, for example trailing-12-month revenue from the affected products only, for the affected accounts in the top 50.
The graph finds which accounts are affected, and the semantic layer computes the number. The binding between them makes both systems use the same definitions of “account,” “largest,” and “revenue at risk,” and lets the answer cite the metric version and its owner.
How are vendors closing the gap from both sides?
The ontology vs. semantic layer boundary is narrowing as semantic-layer and graph products add each other’s capabilities:
- On the semantic-layer side, according to Microsoft Learn (2026), the Fabric IQ ontology is in preview and can be generated from a Power BI semantic model. Measures appear in the ontology as metrics while the source semantic model remains the owner of the DAX expression, and graph is an optional execution layer for multihop and dependency questions. The Microsoft Fabric IQ design keeps that division of labor.
- In the warehouse, BigQuery supports GQL and SQL/PGQ over property graphs built from tables. According to Google Cloud (November 2026), BigQuery measures are now generally available and build on BigQuery Graph, so measures are defined on the graph entities they describe.
- In standards, Apache Ossie (2026), the incubating project formerly called Open Semantic Interchange, describes itself as an open specification for both semantic layer and ontology.
- From the graph side, Neo4j retrieves schema relationships and business terms for text-to-SQL, while ontology-based semantic layers such as Timbr start from the graph side.
Fabric IQ and BigQuery now keep metrics computed at the source and put a graph of concepts and relationships above them. When the same term lives in several tools, each concept-to-metric link still needs an owner. Atlan keeps those links in its Enterprise Data Graph, where human experts review and certify them.
When do AI agents need both, and what connects them?
AI agents need both once a single request crosses the boundary: a metric, a relationship path, a definition, an owner, and a policy check in one answer.
A semantic layer calculates “active customers,” while a knowledge graph connects those customers to products, contracts, and policies. If the two systems define “customer” differently, the agent gets two answers that both look valid.
A system of semantics connects definitions that would otherwise stay isolated. An enterprise context layer records the links between concepts, metrics, assets, and policies without taking metric computation away from the semantic layer or relationship traversal away from the graph.
A context layer aligns both systems through five explicit links:
- Concept to metric: “Revenue” points to the approved metric that calculates it.
- Entity to record: A graph entity such as an account maps to its warehouse key.
- Metric to lineage: The metric traces to its source fields and transformations.
- Metric to owner and certification: A named owner approves the definition and resolves conflicts.
- Asset to policy: Each asset points to the access and use rules that apply to it.
The difference from a semantic layer alone, set out in context layer vs. semantic layer, context layer vs. knowledge graph, and context layer vs. data catalog vs. semantic layer, is that these links have an owner and a version. Teams implementing an enterprise context layer can use a context layer reference architecture to assign that owner for each link.
How does Atlan connect semantic layers and knowledge graphs?
Atlan brings supported semantic assets into its Enterprise Data Graph alongside glossary terms, lineage, owners, quality signals, and policies. Agents get connected, certified context, while metric calculation stays in the semantic layer and its query engine.
| Operational need | Atlan capability | What it changes |
|---|---|---|
| Reuse existing business meaning | Enterprise Data Graph, built from connectors, Context Agents, and lineage | Atlan’s semantic offerings reference lists Power BI semantic models and Databricks Unity Catalog metric views as supported. They join their source tables, terms, owners, and policies in one graph. |
| Build relationships from evidence already in the estate | Context Agents: Lexis builds the business glossary from column patterns, Nexus links columns to the business terms analysts use, Sage finds conflicting metric definitions and locks one answer, and Orion maps the ontology connecting domains and metrics | Agents draft descriptions, term links, and relationships from lineage, SQL, and existing definitions. Owners review and certify the result, keeping humans on the loop, which supports ontology design without boiling the ocean. |
| Trace a definition back to data | Data lineage for AI | Owners and agents see the upstream and downstream dependencies of supported assets, so a metric is never an isolated label. |
| Test and serve certified context | Context Engineering Studio, Context Lakehouse, and the Atlan MCP server | Domain experts bootstrap context, run evaluations against it, and package it into Context Repos, which Atlan describes as versioned, bounded, portable units of context any agent can consume. Context Repos expose context through MCP, so agents read the same certified definitions, glossary terms, and lineage. The Context Lakehouse stores context on Apache Iceberg, with time travel for point-in-time retrieval. |
What stays in the semantic layer?
In operational terms, this is the difference between context engineering and a semantic layer. The semantic layer keeps calculating the metric. Atlan connects that metric to the business meaning, evidence, ownership, and policy an agent needs to use it correctly.
Real stories from real customers: shared definitions agents can use
"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."
Joe DosSantos, VP, Enterprise Data and Analytics, Workday
"Context is the differentiator. Atlan gave our teams the shared vocabulary and lineage to move from reactive data management to proactive AI enablement."
Kiran Panja, Managing Director, Cloud and Data Engineering, CME Group
Choosing where each definition lives
Semantic layers and knowledge graphs answer different questions, and the benchmarks reward whichever one carries real business meaning to the model. The architectural decision that remains is where each definition lives, who owns the link between a graph concept and the metric behind it, and how an agent finds both before it answers.
FAQs about semantic layer vs. knowledge graph
Short answers to the questions teams ask most when they choose between the two.
1. Is a semantic layer a type of knowledge graph?
Not in the analytics sense. An analytics semantic layer models metrics, dimensions, and join paths that compile to SQL, while a knowledge graph models entities and typed relationships for traversal. Some products implement both, and the knowledge-management use of “semantic layer” includes graphs, which is where the confusion comes from.
2. Do I need a knowledge graph if I already have a semantic layer?
Only if your agents must trace relationships between entities spread across systems, such as which products a recall touches or which records describe the same customer. If the workload is governed KPIs inside the modeled data, the semantic layer is the stronger base.
3. Do knowledge graphs make LLMs more accurate?
They can, when they add business meaning to a raw schema. In a 2023 data.world benchmark, GPT-4 scored 16.7% writing SQL from DDL alone and 54.2% writing SPARQL with an OWL ontology over the same tables. The gain came from the added business meaning; both conditions queried the same tables.
4. Is a semantic layer or a knowledge graph better for text-to-SQL agents?
A semantic layer is better for governed metrics within its modeled scope. Graph retrieval can help a text-to-SQL agent select relevant tables, joins, and glossary terms from a large schema, but it does not replace the metric definitions.
5. What query languages does each use?
Semantic layers usually compile requests to SQL. RDF knowledge graphs use SPARQL, property graphs use Cypher or GQL, and SQL/PGQ adds graph pattern matching inside SQL systems.
6. Why do metrics usually live in a semantic layer rather than a knowledge graph?
Because a semantic layer fixes the formula, grain, and join path once, so every request for a metric compiles the same way and avoids double counting from one-to-many joins. Graph queries can aggregate too, but unless measures are defined on the graph, each query author decides the grain.
7. Is GraphRAG the same as an enterprise knowledge graph?
No. Microsoft’s GraphRAG method extracts entities and communities from documents to improve retrieval and summarization. An enterprise knowledge graph models business entities, data assets, and their maintained relationships.
8. Are vendors merging semantic layers and knowledge graphs?
Partly. Microsoft Fabric IQ generates an ontology from Power BI semantic models and keeps the DAX measures as metrics, and BigQuery defines measures directly on graph entities. Each still keeps metric logic in one governed place.
9. Which should we build first?
Start with the question type that matters most and reuse the semantic models, lineage, and glossaries already in the estate. Build the smallest model that answers a real agent question, then add the other representation when the workload crosses from numbers to paths or back.
10. How do you keep a semantic layer and knowledge graph consistent?
Bind each graph concept to the metric that computes it, then attach lineage, an owner, certification state, and policies. Keep a set of real agent questions with expected answers. Rerun it whenever someone proposes a metric or ontology change, so a concept that now resolves to a different metric fails before it ships.
11. How do a semantic layer, ontology, knowledge graph, and context graph differ?
A semantic layer computes governed metrics. An ontology defines the classes and relationship types of a domain. A knowledge graph holds the actual entities and relationships that follow that model. A context graph adds runtime signals such as state, policy, and decision history.
12. Does lineage connect a metric back to its source data?
It can. Atlan builds column-level lineage automatically from SQL, pipelines, and APIs across 80+ systems, so an answer an agent produces can be traced back through the lineage graph to the data that produced it.
13. Are access policies enforced across both systems?
Each engine enforces its own access rules. Microsoft documents that Fabric IQ ontology authoring and querying respect access to bound data, including row-, object-, and column-level security. A context layer records which policy applies to each asset, so an agent sees the rule before it queries either system.
14. Can one set of definitions serve many agents and tools?
Yes, if the definitions live in one versioned place that every consumer reads. Apache Ossie describes itself as an open specification for both semantic layer and ontology, and Atlan’s Context Repos expose the same certified context to any agent through MCP.
Sources
- A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model’s Accuracy for Question Answering on Enterprise SQL Databases, arXiv
- Increasing the LLM Accuracy for Question Answering: Ontologies to the Rescue!, arXiv
- Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update, dbt Labs
- Joins, dbt Labs
- CypherBench: Towards Precise Retrieval over Full-scale Modern Knowledge Graphs in the LLM Era, arXiv
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization, arXiv
- OWL 2 Web Ontology Language Primer (Second Edition), W3C
- SPARQL 1.1 Overview, W3C
- BigQuery Graph and ISO standards, Google Cloud
- Introduction to BigQuery Graph, Google Cloud
- BigQuery measures is now GA: Unifying BI metrics and knowledge graphs for AI accuracy, Google Cloud
- What Is Ontology (Preview)?, Microsoft Learn
- Overview of semantic views, Snowflake
- Apache Ossie (Incubating): The New Name for Open Semantic Interchange, Apache Ossie
- How a Neo4j semantic layer makes your Text-to-SQL agent smarter and cheaper, Neo4j
- What is the Difference Between a Semantic Layer and a Context Layer? When to Use a Knowledge Graph vs. a Context Graph, Enterprise Knowledge
- Shapes Constraint Language (SHACL), W3C
