When you do not need a semantic layer yet

Not every team needs a semantic layer this quarter. Shipping one too early creates YAML theater on top of unstable transforms. Waiting too long, especially once agents arrive, creates metric fights that are faster and harder to unwind.

Here is an honest split: when to postpone, and when chaos makes a serving layer urgent.

Signals you can wait

Postpone a dedicated semantic layer when most of these are true:

• One primary consumer (usually one BI tool) and almost no programmatic reuse
• A small set of analysts who already agree on definitions in practice
• Transforms and grain are still changing weekly; naming a metric would freeze noise
• No MCP or SQL-capable agents in production paths to the warehouse
• Disagreements are rare and resolved by looking at the same dashboard together

In that world, invest in warehouse modeling quality first. Keep transforms where they belong. A thin semantic layer on top of thrashing tables will not save you.

Signals it is urgent

Move sooner when several of these show up:

• Multiple consumers need the same number: BI, an app, finance extracts, and now an agent
• Two dashboards disagree and the argument is about joins or filters, not about a bug in source data
• Someone proposed giving an LLM a SQL tool “just for internal Q&A”
• Credentials and row rules differ by team or tenant, and you cannot explain them in one place
• You are evaluating a second warehouse or a migration and do not want metric logic rewritten per vendor

Agents are the forcing function. An agent that invents SQL will pick a local definition and sound sure. If humans already argue about the number, the agent will pick a side.

What “semantic layer” means here

We mean a portable serving layer: author metrics as YAML, publish an immutable artifact, query via REST/console or MCP with one structured request shape. MCP tools (list_catalog, describe_metric, run_semantic_query) do not accept or return SQL. Governance is the request shape - grants and row rules on every read - not a post-filter. The warehouse still holds transforms; the layer stays thin. Metering covers usage. Rollups exist for hot questions, but they are not a reason to rush a purchase on latency theater.

That is different from “more documentation in the BI catalog” and different from vendor-native metric objects that only work inside one warehouse console.

A practical sequencing

1. Stabilize grain and core transforms for the few metrics leadership actually uses.
2. Publish those as certified metrics before you widen agent access.
3. Put agents on governed MCP credentials only after a same-number eval against the console.
4. Expand the catalog as consumers demand - not as a big-bang model of the whole warehouse.

If you only need better dashboards for one team, fix the warehouse model and BI definitions first. If you need humans and agents to share one number without hallucinated SQL, you need a serving layer in the middle.

Postpone when the model is still mush. Do not postpone once agents can reach the warehouse with a blank SQL prompt.