The Context Layer Needs a Semantic Layer - Cube BlogJuly 10, 2026Agentic Analytics<br>Artyom Keydunov<br>Co-founder and CEO at Cube

Table of Contents

The context layer came from a real failure

Most of what we call context is descriptive

A semantic layer is executable context

Three kinds of context

Where each piece belongs

One executable core, context assembled around it

The semantic layer, after AI

Subscribe to Newsletter<br>Get Cube updates to your inbox for building better data products.

Subscribe

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...