Almost every conversational analytics demo that disappoints in production fails for the same reason: there is no semantic layer underneath it.
A model is asked, in natural language, what revenue did. It writes SQL. It runs the SQL. It returns a number. The number is wrong, or it is right but inconsistent with the number the CFO saw yesterday, or it is right today and wrong tomorrow because someone renamed a column. The model is blamed. The model is not the problem. The architecture is.
A semantic layer is the place where the definitions that matter to the business — metrics, dimensions, joins, filters, hierarchies, access rules — live in one governed location, separated from the raw tables underneath and from the tools that consume them on top. “Revenue” is defined once. “Active customer” is defined once. “Qualified pipeline” is defined once. Every dashboard, every agent, every export, every API call resolves through the same definitions.
Without that layer, every consumer reinvents the logic. The BI tool has one definition. The CRM report has another. The ad-hoc SQL in the analyst’s notebook has a third. The conversational agent invents a fourth on the fly. Leadership ends up reconciling instead of deciding. This is the state most organizations are in today, and it is the state that AI makes more painful, not less, because AI fanning out across inconsistent logic at machine speed produces inconsistent answers at machine speed.
The semantic layer is what makes “ask the data a question” work. The model does not write raw SQL against raw tables. It expresses the question against the semantic layer’s vocabulary — metric names, dimensions, time grains — and the semantic layer compiles that into governed SQL. The answer is consistent with every other consumer because every consumer is reading from the same definitions. Citation becomes possible because the lineage from question to number is traceable. Governance becomes possible because access control sits in one place.
This is the architectural shift that has quietly happened over the last two years. Source systems feed the warehouse. The warehouse holds clean modeled tables. The semantic layer sits on top of those tables and exposes business concepts. Above the semantic layer sit the consumers — dashboards, conversational analytics, knowledge agents, embedded analytics, downstream systems. The semantic layer is the new center of gravity. It is where the business meets the data.
The options in the market have converged enough that the choice is no longer paralyzing. The dbt Semantic Layer suits teams already standardized on dbt and looking for tight integration with their modeling workflow. Cube is strong for teams who want a more API-first, embedded-analytics-friendly approach. LookML, inside Looker, is the most mature and the most opinionated, and the right answer for teams committed to that ecosystem. Omni and AtScale serve teams who want strong governance with broader tool interoperability. The honest answer is that any of these, well-implemented, beats none of them perfectly chosen.
What matters more than the vendor choice is the discipline. A semantic layer that contains every metric anyone has ever requested is not a semantic layer. It is another mess. The starting move is to define the twenty to forty metrics that the business actually runs on, the dimensions those metrics need, the joins required to compute them, and the access rules that govern who sees what. From there the layer grows as new questions justify new definitions. “Good enough” shipped now produces vastly more value than “perfect” shipped in eighteen months.
There is a build-versus-buy decision underneath this, and the right answer depends on team capacity, not technology preference. Teams with strong data engineering can absolutely roll their own. Teams without should not. The cost of a half-built semantic layer is higher than the cost of paying for one that works — because a half-built one inherits all the inconsistency it was supposed to solve, plus the maintenance burden of pretending it does not.
One of the most underrated benefits of a semantic layer is what it does to the analytics team’s posture. Instead of producing one-off answers, the team is curating the vocabulary the entire business asks questions in. That is a different job, and a more strategic one. It changes the question from “what did revenue do last week?” to “is revenue defined correctly, governed correctly, and accessible to everyone who needs it?” The first question is endless. The second compounds.
If you are evaluating conversational analytics, knowledge agents, or any AI-native analytics product, the first question to ask is not which model it runs on. It is what semantic layer it expects underneath, and whether yours is ready. If the answer is “it will figure it out from your raw tables,” the demo will be impressive and the production rollout will be painful.
The semantic layer is not glamorous. It is plumbing. But it is the plumbing the next decade of analytics runs on, and the organizations that build it now will compound a structural advantage over the ones still treating definitions as a per-team responsibility.
At RightPath, we help teams pick a semantic layer, scope it to the metrics that actually run the business, and wire it to the agents and tools that depend on it.