Context Layer vs Semantic Layer: What AI Agents Need to Get Answers Right

A semantic layer defines metrics once and computes them the same way in every tool that asks. A context layer gives AI agents the wider business meaning they need to use that data: semantic models, documentation, lineage, glossary terms, and written knowledge. In most stacks, the semantic layer is one input to the context layer. Neither layer decides which definition of a business term is the approved one, and that missing decision is where most wrong AI answers start.

We tested this with one question against a sample data project on Snowflake. Without governed definitions, the agent found three defensible answers and had to guess which one we meant. With a Definition of Record in place, it gave one answer and explained why.

What is a semantic layer?

A semantic layer is a governed set of metric, dimension, and entity definitions that sits between your warehouse and every tool that queries it. You define net revenue once. Dashboards, notebooks, spreadsheets, and agents ask for net revenue and get the same SQL every time.

Semantic layers come in several forms. Some live in the transformation layer, like the dbt Semantic Layer. Some live inside the warehouse, like Snowflake Semantic Views and Databricks Unity Catalog metric views. Others are built into BI tools or run as standalone engines. They differ in where the definition lives and which engine runs it. All of them make the same promise: consistent computation.

What is a context layer?

A context layer is the business knowledge an AI agent reads before it writes SQL or answers a question. It usually bundles semantic models, model and column documentation, lineage, glossary terms, example queries, and unstructured knowledge from wikis and tickets, then exposes all of it to agents, often over MCP.

Vendors package it differently. Fivetran describes its Context Layer, now in public preview, as a context inference and management service that builds context from the sources you already ingest and the models you build in dbt, then publishes it as open tables in your warehouse. Most definitions you’ll find agree on the shape: the context layer is the superset, and the semantic layer is one of its inputs.

That answer is accurate. It also skips the step that decides whether the agent’s answer is right.

What a semantic layer does well

Credit where it’s earned. A good semantic layer moves metric logic out of individual dashboards and into one governed place. Definitions live in code or configuration, so they can be version-controlled, reviewed, and tested before they reach anyone. Joins come from declared relationships, which means analysts stop hand-writing join paths and stop getting them subtly wrong.

The payoff compounds as tools multiply. The same metric reaches a BI dashboard, a spreadsheet, a notebook, and increasingly an AI agent through an API or an MCP server, and every one of them gets the same number.

If you’ve ever sat in a meeting reconciling three dashboards that show three revenue numbers, you know what this fixes. Keep your semantic layer. The harder question is what it was never built to do.

Where a semantic layer stops: one question, three valid answers

We asked an AI agent running in Datacoves a plain business question against a Snowflake demo dataset: how many active vendors do we have? The agent had the dbt repo and read access to the project’s production schema. It read the model SQL, picked 25, and called it the project’s standard definition. Then it listed two other defensible answers, 24 and 21, and told the user the right one depends on what they mean by “active.”

It guessed right, and that’s the problem. The agent chose 25 because one model is named mart_active_vendors and the others aren’t. Rename a model, add a fourth one, or ask a different agent, and the “standard” answer moves. A table name was carrying a decision nobody had recorded.

None of these is a bug. Finance reviewing vendor risk may want twelve months. Procurement tracking supplier consolidation may want ninety days. The ERP admin trusts the status field because that’s what the ERP shows on screen. Each team has a reason, and each reason holds up.

A semantic layer will compute whichever one you encode, consistently, forever. Think of it as a calculator with a perfect memory: it never forgets the formula you gave it, and it never tells you the formula was the wrong one. Encode the 90-day version as “active vendors” and every dashboard and agent will agree with each other while disagreeing with the CFO.

The ERP flag shows how this goes wrong in practice. Five vendors marked inactive are still receiving purchase orders or invoices. One marked active hasn’t had either in twelve months. An agent that finds a column named status with a value of active will reach for it first, because it looks like the obvious answer.

Ask that agent again tomorrow, or ask a different agent, and you may get a different pick. Business users experience that as “the AI makes things up,” even though every number came from real, tested dbt models. We’ve written before about why LLMs still need people checking their work. This is the version of that problem that no model upgrade will fix.

What a context layer adds, and the decision it needs first

A context layer fixes a real problem: agents that don’t know which table holds vendors, what a column means, or how models connect. Give the agent lineage and documentation and it stops guessing at structure.

It leaves this problem untouched. In the vendor example, the context was already there. The agent found all three models, read their SQL, and described each one accurately. More context about an undecided term gives an agent more ways to be confidently wrong.

The missing step is agreement. Someone who owns the term chooses one definition, writes it down in plain language, and records the decision so it can be found, versioned, and challenged later. We call the result a Definition of Record.

A Definition of Record is a plain-English, versioned, attributed statement of what an organization has agreed a business term means, published so that people and AI agents use the same meaning.

The same question, with Atlas connected

Atlas is the agreement layer we built for this step. It records Definitions of Record and serves them to agents over MCP. We connected it and asked the same question in the same session. The agent returned one answer, 25 active vendors out of 34, and showed its work:

• It named the governed Active Vendor definition: at least one purchase order or invoice in the trailing 12 months, counted by vendor_id.
• It cited the column it used, BALBOA.L3_ACCOUNTS_PAYABLE.MART_ACTIVE_VENDORS.is_active.
• It told the user not to use the ERP status flag for this question and explained the six mismatches.
• It noted that the repo’s active_vendor_reference_counts test also expects 25 at 2026-08-01.
• It labeled the other 9 as dormant vendors, the governed opposite term, and offered the 90-day trend as a separate view.

That last point matters more than it looks. The 90-day number didn’t disappear. It just stopped borrowing the name of a number the business had already settled.

The same discipline carries into reporting. A dbt Charts dashboard built on the Atlas-governed dbt models shows 25 active vendors and the 6 ERP mismatches. Its 90-day trend chart is titled “Vendors with activity in the prior 90 days.” The words “active vendor” appear only on the governed number. One chart title did more for trust than a page of documentation would have.

Telling the agent how much to trust a term

Atlas also tells the agent where a term stands. A term is governed when an approved Definition of Record exists. It’s declared but thin when the business has named it but the definition still has gaps. It’s out of scope when nobody has defined it yet. An agent that knows which state it’s in can answer, hedge, or route the question to the owner instead of picking a column and hoping.

Atlas sits upstream of both your semantic layer and your context layer, and it replaces neither. Once a definition is approved, your team encodes it in whatever semantic layer you run, and your context layer serves it alongside everything else. Fivetran’s Context Layer infers context from what you already ingest and model. Atlas complements that kind of tool by recording which definition the business approved, who approved it, and every change since.

Where OSI fits

The Open Semantic Interchange launched in 2025 with Snowflake, Salesforce, dbt Labs, Databricks, and other partners. Its first specification shipped under Apache 2.0 in January 2026, and in July 2026 the project joined the Apache Incubator as Apache Ossie.

OSI gives teams a vendor-neutral format for metrics, dimensions, and relationships, so a definition written for dbt can move to Snowflake or Tableau without being rewritten. That’s useful, and overdue.

Portability has no opinion about correctness. OSI will carry the 90-day definition of “active vendor” into every tool as faithfully as the 12-month one. Portability without agreement just spreads the wrong number faster. The order that works is agree, encode, then port.

Context layer vs semantic layer: side-by-side comparison

Which one does your team need?

Pick based on where your agents are failing today.

Start with a semantic layer if your dashboards disagree with each other. That’s a computation problem, and any mainstream semantic layer handles it.

Add a context layer if your agents can’t find the right tables or misread columns. That’s a structure problem, and documentation, lineage, and glossary context solve it.

Put Definitions of Record first if your agents return confident numbers that business owners dispute, or two teams answer the same question differently. That’s an agreement problem. Encoding and retrieval can’t settle it, and building a semantic layer on top of it locks the disagreement in.

Stay with your semantic layer alone for now if agents only answer questions inside one well-owned metric set, such as finance querying its own revenue model. A single owner is already doing the agreement work informally.

Most enterprise data teams rolling agents out to business users are in the third situation, whether they’ve noticed or not. Start there.

Here’s a test you can run this week. Pick the ten business terms your agents get asked about most. Count how many models, views, or reports compute each one. Any term with more than one answer is a Definition of Record waiting to happen, and it’s probably why your pilot users have stopped trusting the agent.

For the thinking behind Atlas, read Introducing Atlas: an agreement layer for enterprise AI or listen to Atlas and the Agreement Layer. We also walked through this vendor example on the show floor in Datacoves Launches Atlas at dbt Summit 2026.