If you've watched an LLM confidently return the wrong number for a question your finance team would have answered correctly, you've watched a semantic layer fail.
The model and data weren’t broken. What was missing was a machine-readable description of what the numbers in your warehouse actually mean, including the exclusions, the edge cases, and the things you should not compute. Humans pick those up through years of context, but an agent has whatever you wrote down.
A semantic layer in the agentic era is the machine-readable definitions of every metric, dimension, entity, and relationship in your data, written precisely enough that an LLM querying your warehouse arrives at the same answer your domain experts would, every time. It sits between your raw data and the agents that consume it. It is what turns a SQL-capable model into a system that can be trusted with business questions.
This is not the semantic layer most teams have. Most teams have a BI-era semantic layer, built for human consumers reading dashboards. The two look superficially similar (both define metrics, both centralize logic) but they fail differently when you wire an agent up to them.
What a BI-era semantic layer was for
For roughly fifteen years, the dominant use case for a semantic layer was helping humans build consistent dashboards. The Looker LookML and dbt metrics movements of the 2010s were both designed around this premise: a business analyst wants to chart Net Revenue; you want every chart of Net Revenue to use the same definition; the semantic layer enforces that.
Built for that purpose, the layer optimizes for: a clean label visible in a dropdown, a small number of drill paths a human will actually use, a friendly description in tooltip-length text, and rough alignment between what the SQL computes and what most users intuitively expect.
These were reasonable optimizations for human consumers. They are not sufficient for agent consumers, and the gaps that didn't matter before now matter quite a lot.
Where BI-era semantic layers fail with agents
They underspecify edge cases. A human looking at a dashboard knows that "Active Users" doesn't include the QA team. An agent doesn't, unless that exclusion is written into the metric definition explicitly. A BI-era semantic layer rarely encodes exclusions. An agent-era one has to.
They lack disambiguation context. If your warehouse has both Net Revenue and Booked Revenue, a human knows from context which one to use for which conversation. An agent will pick whichever has the more confident match to the question, which can often be the wrong one. The fix is encoding when each metric should and should not be used, not just what each one is.
They don't describe relationships well. BI semantic layers focus on metrics. Agent consumers need to know how entities relate (an Account has Users, a User belongs to a Cohort, a Cohort was defined for a specific Campaign), because they often compose queries across joins a human dashboard wouldn't have. Sparse relationship modeling is one of the biggest sources of confidently-wrong agent answers.
They have no signal for "don't compute this." Some questions look reasonable to ask but produce misleading answers (averaging an already-averaged metric, summing a non-additive dimension, comparing periods with structural differences). A human analyst learns to flag these. An agent will compute them happily unless your semantic layer tells it not to.
What an agent-era semantic layer adds
The structural differences come down to four things. First, machine-readable definitions including exclusions, not just inclusion logic. Second, usage guidance per metric (when to use, when not to, what to compare against). Third, richer entity-relationship modeling, since agents compose across joins. Fourth, explicit guardrails for the questions that shouldn't be answered the way they're asked.
A useful test: if you handed your semantic layer to a careful new analyst with no domain knowledge, could they answer your top ten business questions correctly using only the layer's contents? For BI-era semantic layers, the answer is usually no, the careful analyst has to ask their manager three times. For agent-era ones, the answer needs to be yes, because agents don't have a manager to ask.
Why this is the highest-leverage rebuild for most established businesses
A Gartner analysis projects that through 2026, organizations that fail to make their data AI-ready will see their generative AI projects take twice as long and deliver half the value. The hidden infrastructure cost of agentic AI for most established businesses isn't the agents or the orchestration. It is the semantic layer that should have been written for agent consumers and was written for human ones instead.
Rewriting it is unglamorous work. It is also one of the highest-leverage things a data team can do over the next eighteen months. Almost every agent reliability problem traces back to it. Almost every "the technology isn't ready" conclusion is actually a semantic layer conclusion in disguise.
I will go deeper on what a practical rebuild looks like in a future essay, including the question of whether to retrofit your existing semantic layer or start fresh.
If this was useful, subscribe. And forward it to whoever is responsible for your data quality, even if no one technically is yet.
— Kyle