What is a semantic layer?

The short version

A semantic layer is a single, version-controlled definition of your metrics, entities, and relationships, mapped to the physical tables they come from. Every tool — dashboard, query engine, AI agent — reads through it. Definitions live in one place, change in one place, and apply everywhere.

What it actually contains

• Metrics: active_customer, net_revenue, arpu — with the SQL or expression that computes them.
• Entities: Customer, Order, Account, Product — and the keys that join them.
• Dimensions: the legal ways to slice each metric (region, segment, channel).
• Relationships: how entities connect — one-to-many, many-to-many, with which join key.
• Ownership: the team or person on the hook for each definition.

What it solves

Every company that grows past one team accumulates four definitions of active customer, three definitions of revenue, and a quiet civil war between finance and product about which is right. The semantic layer ends that war — not by political fiat, but by making the canonical definition the easiest one to use.

Why it matters more in the agentic era

Dashboards forgive ambiguity because a human reads them. Agents do not. Ask an agent "how is the business doing?" without a semantic layer and you will get a fluent, confident, wrong answer. With a semantic layer, the same agent can name the metric, the filters, and the owner — and let you click through to the canonical chart.

How to start

Pick ten metrics. Write them down. Get the owners to sign off. Implement them in whatever metrics layer your stack supports — dbt Semantic Layer, Cube, Looker, Malloy, or your warehouse's native one. Connect one agent. Iterate. The book walks through the full playbook in Chapter 7.