Semantic layer vs dbt models vs BI cubes

Data teams often treat dbt models, BI cubes, and semantic layers as interchangeable. They are not. Each layer owns a different job, and agents expose the gaps when those jobs get mixed.

What dbt models own

dbt is the warehouse modeling layer. You define transforms in SQL or Python, test them, document them, and publish tables and views into the warehouse. That work is essential. Clean grain, clear naming, and tested joins live here.

dbt does not serve a request-shaped contract to a dashboard and an agent at the same time. A model is a relation. Callers still decide which columns mean revenue, which filters are allowed, and how to join adjacent tables. Humans paper over that with tribal knowledge. Agents do not.

What BI cubes own

BI cubes (and similar OLAP-style constructs) optimize how analysts slice and dice. They predefine measures, dimensions, and sometimes hierarchies so a UI can explore quickly. Cubes are great for interactive analysis inside one product.

They usually bind meaning to that product. Export the same question to another BI tool, a notebook, or an MCP client, and you often rebuild the measure. Cubes also tempt teams to push serving concerns into the warehouse or the BI app - rollups, caches, and UI-specific aggregates - without a portable contract that other consumers can reuse.

What a serving semantic layer owns

A serving semantic layer sits between the warehouse and every consumer. It publishes certified metrics as a governed contract: name, measure, allowed dimensions, and filters. The warehouse still holds transforms. The semantic layer is thin. It does not invent a second copy of your business logic.

In datahashi, that contract is a YAML model published as an immutable artifact. Humans and agents hit the same metric through the same request shape - REST, console, or MCP. MCP tools such as list_catalog, describe_metric, and run_semantic_query never accept or return SQL. Callers ask for a metric by name, not by inventing joins from a schema dump.

Why agents need the request-shaped contract

Agents are fluent at reading schemas and guessing. That fluency is dangerous. Given tables and columns, an LLM will invent joins, pick the wrong grain, and produce a number that looks confident. A dbt model alone does not stop that. A BI cube alone does not stop that if the agent is not speaking the cube’s API.

A serving semantic layer removes join invention from the agent loop. The agent lists certified metrics, describes one, and runs a semantic query. Metering exists so you can see who asked for what. The same request shape means a dashboard panel and an agent answer can be proven against one definition.

How to choose what to build next

Keep transforms in the warehouse with dbt (or equivalent). Keep exploration UX in your BI product. Put certified metrics behind a serving semantic layer when more than one consumer needs the same number - especially when one of those consumers is an agent.

Do not wait for every serving feature. datahashi ships rollups for hot questions, but does not claim p99 latency guarantees. What matters most is the contract: one metric definition, immutable publication, and the same request for humans and agents without hallucinated SQL.

If your stack already has strong models and a favorite BI tool, the missing piece is usually the serving layer - not another spreadsheet of metric definitions that nobody’s agent can call.