The semantic layer has been around for decades. AI just made it urgent.

Ask a data analyst for last quarter's revenue and you won't get a number. You'll get a question. "Do you mean gross or net? Before or after refunds? In USD or local currency? Including the subsidiary we acquired in March?" The analyst is doing something important: they're resolving ambiguity before producing a figure.

Now ask an AI agent the same question. The agent won't ask. It will query the database, find a column named revenue, aggregate it, and present a confident answer. That answer might not match what finance reports. A $60,000 annual contract signed on March 15th gets reported as a $60,000 win by sales but only $2,500 in recognized revenue by finance for that quarter - and an AI agent querying the raw table wouldn't know which number to return.

This is why the semantic layer is suddenly everywhere. The underlying idea is decades old, but AI has removed the human buffer that used to absorb ambiguity - and that buffer is not coming back.

What the semantic layer actually is

A semantic layer sits between your data warehouse and the tools that query it. Instead of asking a BI tool or an AI agent to write SQL against raw tables, you define business concepts - revenue, active user, churned customer, lead - in one place. Every dashboard, every notebook, every API call, and now every AI agent pulls from the same definition.

The idea is decades old. BusinessObjects had one in the 1990s. Looker built its entire product around LookML. More recently, dbt introduced its Semantic Layer powered by MetricFlow, Cube turned it into a headless API, and MetricFlow tried to make it version-controlled. What changed is the consumer.

Before, the semantic layer served business analysts. Analysts are patient. They read documentation, ask follow-up questions, and spot a number that feels wrong. AI agents aren't patient. They do what they're told with the context they have. If the context is a raw table with cryptic column names, the agent will hallucinate a business rule around it.

What changed

Large language models can now write SQL, call APIs, and generate reports. Vendors are racing to bolt AI onto BI tools, data catalogs, and even spreadsheets. The demos are impressive: an executive asks a chatbot for "revenue by region" and gets a chart in seconds.

The demo hides the problem. In the demo, the question is simple and the data is clean. In production, the question is ambiguous and the data isn't.

Consider what happens when an AI agent queries a typical warehouse directly. The agent sees a table called orders with columns amount, currency, status, and created_at. It writes:

SELECT region, SUM(amount) AS revenue
FROM orders
WHERE created_at >= DATE_TRUNC('quarter', CURRENT_DATE)
GROUP BY region;

This query is syntactically perfect and semantically dangerous. It ignores cancelled orders, mixes currencies, includes test transactions, and counts refunds as negative revenue or not at all depending on how the table was built. A human analyst would know to ask. The agent doesn't.

The semantic layer exists to prevent this exact failure. In a governed semantic layer, revenue is a definition that lives upstream of any table. It specifies the tables, the filters, the currency conversion logic, and the handling of edge cases. The agent asks for revenue, the semantic layer returns the pre-approved logic, and the resulting SQL is consistent with what the finance team expects.

A concrete example

Imagine a subscription business. The warehouse has two relevant tables:

-- subscriptions
id | customer_id | plan | start_date | end_date | mrr | currency

-- payments
id | subscription_id | amount | paid_at | refunded_at | payment_method

What is monthly recurring revenue (MRR)? Here are three reasonable definitions:

1. Sum of active subscription MRR at month-end, converted to USD using the exchange rate on that date.
2. Sum of payments received during the month, excluding refunds.
3. Sum of subscription MRR for subscriptions that started before the month and have not churned, using the exchange rate at subscription start.

These definitions produce meaningfully different numbers. The CFO's month-end MRR and the sales team's MRR can easily diverge by enough to change a hiring decision or a board presentation - not because anyone made a mistake, but because they were counting different things.

Before AI, this was manageable. A human analyst would know which definition to use for which audience. An AI agent given SQL access will pick the one that seems easiest to generate, or the one that happens to match the column name it finds first.

A semantic layer doesn't resolve these disagreements. It simply moves them upstream, where they become visible instead of hidden in different dashboards. Someone - ideally the CFO and the head of data together - decides which definition is canonical. The semantic layer enforces that decision everywhere else.

Where it gets difficult

Implementing a semantic layer sounds like a metadata problem. In practice, it's an organizational problem.

Who owns the definition?

If finance and product disagree on MRR, the semantic layer won't resolve the dispute. It merely moves it upstream. Suddenly the data team is running a negotiation process that looks more like corporate governance than engineering.

It doesn't fix data quality

A semantic layer can enforce a consistent definition of active_user, but if the underlying event tracking is broken, every tool will report the same wrong number. Consistency and correctness are different things.

Latency and complexity

Every query now goes through an abstraction layer. For large datasets, this can add overhead. Some semantic layers pre-aggregate data; others translate to SQL on the fly. The trade-off between freshness and performance returns.

Vendor lock-in

The semantic layer becomes the center of gravity for every downstream tool. Switching costs are high because dashboards, notebooks, and AI agents all depend on the specific dialect of the semantic layer. Moving from one vendor to another is a rewrite of your business logic, not a migration.

AI agents need more than definitions

A semantic layer tells an agent what revenue means. Governing the data is different from governing what the agent does with it. The layer doesn't tell the agent whether it's allowed to email the CFO with that number, or whether a human needs to review the query first.

Who should care

If you're a data engineer or analytics engineer building pipelines that feed dashboards and AI tools, you should care. The semantic layer is where your raw tables become trustworthy answers.

If you're a CTO or engineering leader deploying AI agents against your warehouse, you should care because the agent will eventually produce a wrong number in front of the wrong person. The semantic layer is your best defense against that meeting.

If you're running a small team with one analyst and three dashboards, you probably don't need a dedicated semantic layer product yet. A well-documented dbt project and some team conventions may be enough. The semantic layer becomes necessary when the number of definitions exceeds the number of people who can keep them in their heads.

The real question

The semantic layer is not a technology decision. It is a power decision.

When you implement one, you're not just optimizing queries. You're deciding who has the authority to say what revenue, active user, and churn mean in your organization. That authority used to be distributed across analysts, spreadsheets, and tribal knowledge. The semantic layer centralizes it.

That centralization is useful, but it's also risky. The semantic layer can become a bottleneck, a political battleground, or a single point of failure.

The technology is mature. The hard part is agreeing on the truth before the AI starts reporting it.

Sources

• dbt Semantic Layer documentation - dbt Labs
• Cube documentation: Introduction - Cube
• MetricFlow on GitHub - dbt Labs, Apache 2.0
• The Data Warehouse Toolkit - Ralph Kimball
• Designing Data-Intensive Applications - Martin Kleppmann