Everyone in data is talking about the context layer right now. a16z put a name on it in March with "Your Data Agents Need Context", and since then just about every data vendor has published a "context layer vs. semantic layer" take. The takes don't agree with each other, but the energy is real.
Cube Core is the largest standalone open-source semantic layer, so I keep getting some version of the same question: is the semantic layer old news now that there's a context layer?
My answer is no — and the "versus" framing is the wrong way to think about it. The context layer is real, and it's the superset: everything an agent needs to answer a business question correctly. The semantic layer sits inside it as the one part that actually executes.
The context layer came from a real failure
Through 2024 and 2025, almost every company wired an LLM to its data warehouse and expected "chat with your data" to just work. Most of it didn't. What's interesting is why: it wasn't the models. Models write syntactically perfect SQL. The agent failed because it didn't know whether "revenue" meant gross or net, which of the three customer tables was the source of truth, or whether the person asking was even allowed to see the rows it was about to return.
That's a context problem, not a model problem. The industry has now mostly accepted this and named the missing piece the context layer. The name is right. But naming the problem is where a lot of the current takes stop being right.
Most of what we call context is descriptive
Look at what usually gets listed under "context": catalogs, glossaries, ontologies, lineage graphs, freshness signals. All of it is useful, and all of it does the same kind of work — it tells the agent about the data. A catalog says this table exists and who owns it. A glossary says roughly what "active customer" means. An ontology says how a customer relates to an account and an order. Lineage says this number came from that pipeline.
None of it executes: nothing here produces an answer or enforces a rule. Hand an agent purely descriptive context and it still has to author its own SQL from a description, getting the joins and the grain right on every single query. What it produces is a confident guess with citations attached — and there's still no runtime enforcing a permission boundary between the agent and the data. Nothing stops it from returning a row the user was never allowed to see.
A semantic layer is executable context
A semantic layer is a different kind of thing. It isn't documentation of what revenue means — it's the governed, executable definition of it: measures, dimensions, joins, and access policies, defined once in code and computed consistently everywhere. When an agent works through a semantic layer, it doesn't read a description of revenue and reconstruct the SQL. It selects the certified revenue measure, and the layer compiles the exact query — with the user's row-level and role-based access rules already applied. Governance happens before the SQL exists, not as a filter someone hopes gets applied afterward.
In Cube, the interface for this is Semantic SQL: regular SQL with one extension. Instead of improvising SUM(CASE WHEN status = 'completed' THEN 1 END) / NULLIF(COUNT(*), 0) and hoping the grouping level is right, the agent writes MEASURE(completed_percentage), and the layer's rewrite engine expands the measure at the correct aggregation level, in the target warehouse's dialect, with the access rules compiled in. Models pick this up with minimal prompting because they already speak SQL fluently — we've seen agents that struggle to define a metric correctly from scratch use a certified measure reliably.
This is why I describe a semantic layer as executable context. Descriptive context helps an agent choose; executable context makes the chosen answer correct and permitted. It's the difference between an agent that knows what a term means and an agent whose answer you can put in front of a customer.
Three kinds of context
An agent answering a business question draws on three kinds of context:
- Executable context. The semantic layer: metrics, dimensions, joins, and access policies. Computes the governed answer and enforces permissions when the query is compiled.
- Descriptive context. Everything that informs the agent without executing anything: catalogs, glossaries, ontologies, entity definitions, lineage — and the "why" that lives in docs, tickets, and tribal knowledge. Some of it is structured metadata, some is a paragraph in a wiki; either way it's read at query time (in Cube, over MCP (Model Context Protocol) Connectors) and helps the agent choose and explain.
- Memory. What was decided before and why — the exception that became precedent, the definition change that explains a break in a trend. Written as decisions happen, retrieved when they're relevant again.
An agent needs all three, and they compound — the context layer is the whole stack, not any one piece. But they aren't interchangeable: descriptive context and memory make an agent informed; executable context makes it correct and governed. You build the informed layers around an executable core, not the other way around.
Where each piece belongs
If you've read any context-layer explainer, you've seen the checklist: semantic layer, entity resolution, policy enforcement, lineage, memory. You need all of it. The interesting question is where each piece belongs — and sorting them with the three kinds of context shows the semantic layer isn't one item on a checklist. It's the runtime the rest organize around.
Policy enforcement → the executable core. This one belongs inside the semantic layer, and it has to be deterministic. A rule the agent is merely told about in a prompt is a rule it can reason its way around. Enforcement has to be a property of how every query is built — row-level and role-based rules applied when the query compiles, before any SQL touches the warehouse.
Entity resolution, ontologies, and business meaning → descriptive context, over MCP. One consistent answer to "what is a customer" across the CRM, billing, and support systems is a real problem — and much of that business meaning doesn't live in the warehouse at all. It lives in ontologies, Notion pages, Google Docs, wikis, and tickets. Whether it's a formal ontology or a paragraph in a wiki, the right move is to pull it in over MCP at query time, not to pretend you can hand-model all of it into the layer up front.
Lineage → split across the boundary. There are two kinds, and conflating them is a mistake. Semantic lineage — how a metric is composed from other metrics and definitions — should absolutely be exposed to the consuming agent; it's part of understanding the answer. Physical table lineage — the full graph of underlying tables and transformations — is implementation detail. The agent building the semantic model needs it; the agent consuming data doesn't, and feeding it the full table graph adds noise and risk. This is David Parnas's information hiding applied to data: expose the interface, hide the implementation. The semantic layer is that boundary.
Memory → the agent harness. A ledger of what was decided before and why belongs in the harness — the runtime scaffolding around the model. And the harness should be built around the semantic layer, because the semantic layer is the executable piece everything else coordinates through, not an accessory bolted onto the model afterward.
One executable core, context assembled around it
Put together, the context layer has a shape — an agentic loop. At the center is the semantic layer: the executable, governed engine that turns a question into a correct, permitted answer. The agent harness is built around that engine. And the rest of the context — business meaning, tribal knowledge, docs, tickets — is assembled at runtime, mostly over MCP, exactly when the agent needs it. That's the architecture behind Cube's AI Context Layer.
In practice, each of these pieces is exposed to the agent as a set of tools. The semantic layer, the entity and ontology definitions, the memory of past runs — the agent reaches each of them over MCP as callable tools, not as a fixed pipeline. On every run it decides which tools to call and in what order: read the core business concepts from the entities doc, search the semantic layer's data model for the right measures and dimensions, pull any relevant memory from earlier runs, and then run a query against the semantic layer.
That last step is different in kind from the ones before it. Reading concepts, searching the model, retrieving memory — that's all context gathering. The query is execution: it's where a governed answer actually gets produced. Everything upstream helps the agent decide what to ask; only the semantic layer turns that decision into a correct, permitted result.
From there the agent can end the run or keep looping — investigating further, gathering more context, or taking action through tools that do more than read: build a dashboard, send an email, update a system of record. The semantic layer sits at the center of that loop as the one tool that executes.
Build all of it — catalogs, lineage, business rules, tribal knowledge. Just make sure the core is a real runtime. A semantic layer done right is code: version-controlled, tested, and served live over MCP to every agent that needs it. The "stale YAML nobody maintains" picture that shows up in some of the context-layer discourse describes a semantic layer someone built and abandoned — an implementation failure, not a property of the thing itself.
Two more convictions follow from the same root. First, a context layer that ships as a feature of a single BI tool wraps trust around a seat you're already locked into. Agentic analytics is a platform decision: the governed model should reach every agent you run — in a chat interface, in your own product, in Claude or ChatGPT over MCP — which is why we built Cube AI-native around the governed model rather than adding a chat box to a dashboard. Second, an agent answering business questions is a production system, and production systems have tests. Cube Evals exists so you can prove that a context or model change actually improved answer accuracy before it ships, instead of eyeballing outputs and hoping.
The semantic layer, after AI
The semantic layer didn't get less important because of AI. AI is the reason it stopped being optional: agents surface every ambiguity a human analyst used to quietly resolve, at a volume no human review can absorb. When Brex built Spaces — the AI-powered financial reporting workspace embedded in their product — they evaluated Cube against other semantic layers and chose it because, as their team put it, "the semantic layer is what makes the AI useful." The agent understands what "spend" means at Brex because that meaning is encoded, computed, and governed in the layer — not guessed from column names.
If you're designing a context layer right now, start with the executable core and assemble the rest around it.