Business Context

The semantic layer was always a good idea. Centralise metric definitions so reporting stays consistent. Useful. Important, even. But not exactly exciting infrastructure.

That changed the moment we started deploying agents against production data. An agent that queries revenue needs to know what revenue means -- which entities, which time boundaries, which exclusions. Get this wrong and the agent doesn't just produce a bad chart. It takes a bad action. The semantic layer quietly shifted from a reporting convenience to agent safety infrastructure. Most organisations haven't noticed yet.

The Problem: Agents Without Shared Meaning

Here's what breaks. A procurement agent needs to evaluate supplier risk based on "delivery reliability." But delivery reliability has three definitions across the business: logistics measures it as on-time percentage against the original promise date, finance tracks it as percentage of invoices matching POs, and operations calculates it against revised delivery windows. The agent picks one. Nobody knows which.

This is not a hypothetical. Imagine a mid-market retailer whose inventory agent orders excess stock for six weeks because it calculates "sell-through rate" differently from the merchandising team's definition. The numbers look plausible. The logic is coherent. The meaning is wrong. This is the kind of failure mode that emerges the moment agents act on ungoverned definitions.

The deeper issue: without a shared semantic contract, every agent effectively invents its own ontology. Multiply this across a dozen agents and you get an enterprise where automated systems are making decisions using incompatible definitions of the same business concepts. Semantic drift becomes action drift. The agent isn't malfunctioning -- it's operating faithfully on a definition nobody agreed to.

dbt's documentation on the semantic layer puts it directly: the semantic layer exists to ensure that metric definitions are consistent regardless of who -- or what -- queries them. The "what" part is new. And it changes everything about how we think about this infrastructure.

The Solution: The Semantic Layer as Agent Contract

Think of it through the lens of cartography. Before standardised map projections and shared legends, every cartographer drew maps using their own symbols and scales. Two maps of the same coastline could look entirely different. Navigation between them was guesswork. The Mercator projection didn't just standardise visualisation -- it created a shared language that made coordination between ships, ports, and nations possible for the first time.

The semantic layer does the same thing for agents. It's the shared legend.

Here's what this looks like in practice. A well-implemented semantic layer provides three capabilities that matter for agentic architectures:

Governed metric definitions. Revenue, churn, utilisation, margin -- each has exactly one definition, version-controlled and auditable. Agents don't calculate metrics; they consume them. This is a critical constraint. The agent can query "Q4 revenue for the Nordic region" but cannot invent its own revenue formula.

Dimensional context boundaries. The semantic layer doesn't just define what a metric is -- it defines how it can be sliced. Revenue can be broken down by region, product line, and customer segment. It cannot be broken down by individual employee (a privacy constraint) or by experimental cohort (an analytical constraint). These boundaries govern what questions an agent is permitted to answer.

Temporal consistency. Is "this quarter" calendar quarter or fiscal quarter? Does "year-over-year" compare to the same calendar period or the same trading days? The semantic layer resolves temporal ambiguity before it reaches the agent, not after it produces a misleading comparison.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#ffffff', 'lineColor': '#ffffff', 'background': '#0a0f1e', 'mainBkg': '#1a2540', 'nodeBorder': '#ffffff', 'edgeLabelBackground': '#1a2540'}}}%%
graph LR
    A["Agent Request:\nQ4 revenue by region"] --> SL["Semantic Layer"]
    SL --> MD["Metric Definition\n(one formula, versioned)"]
    SL --> DC["Dimensional Constraints\n(allowed slices only)"]
    SL --> TC["Temporal Resolution\n(fiscal Q4, not calendar)"]
    MD --> R["Governed Result"]
    DC --> R
    TC --> R
    R --> ACT["Agent Acts on\nConsistent Meaning"]
    style SL fill:#1a2540,stroke:#00d4ff,color:#00d4ff,stroke-width:2px
    style MD fill:#1a2540,stroke:#ffb347,color:#ffb347
    style DC fill:#1a2540,stroke:#ffb347,color:#ffb347
    style TC fill:#1a2540,stroke:#ffb347,color:#ffb347
    style R fill:#0a2a1e,stroke:#00ff88,color:#00ff88,stroke-width:2px
    style ACT fill:#0a2a1e,stroke:#00ff88,color:#00ff88
    style A fill:#1a2540,stroke:#ffffff,color:#ffffff

Frameworks like OpenClaw treat the semantic layer as the contract: agents may query data, but they may only act on meaning. NemoClaw enforces governed context boundaries. This is the direction the ecosystem is heading -- the semantic layer as a governance surface, not just a reporting convenience.

Implementation: Making This Real

I'll be honest: this is harder than it sounds. Most organisations have metric definitions scattered across BI tools, SQL views, Python notebooks, and tribal knowledge. Consolidating them is a political project as much as a technical one. Finance's revenue number and sales' revenue number are different for reasons, and those reasons have stakeholders.

Here's the approach I'd recommend:

Step 1: Audit your metric landscape. Pick the ten metrics that matter most to your business. For each, document every definition currently in use, where it lives, and who owns it. You will find duplicates. You will find contradictions. This is the point.

Step 2: Establish a single semantic layer. dbt's Semantic Layer provides a practical starting point -- define metrics as code, version-control them, and expose them through a consistent API. Databricks has been building metric views with a similar philosophy: centralised, governed, queryable. The tooling exists. The hard part is the organisational agreement on what each metric means.

Step 3: Expose the semantic layer to agents, not raw data. This is the critical architectural decision. Your agents should not have SQL access to underlying tables. They should query the semantic layer's API, which returns governed metrics with their dimensional context. The agent gets answers, not raw material to fabricate its own.

Step 4: Version and audit. When a metric definition changes -- and it will -- the semantic layer should version that change explicitly. Agents consuming the metric should log which version they used. This creates an audit trail that answers the question every regulator will eventually ask: "On what basis did the system make this decision?"

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#ffffff', 'lineColor': '#ffffff', 'background': '#0a0f1e', 'mainBkg': '#1a2540', 'nodeBorder': '#ffffff', 'edgeLabelBackground': '#1a2540'}}}%%
graph TD
    A1["Step 1: Audit\n10 key metrics"] --> A2["Step 2: Centralise\nMetrics-as-code"]
    A2 --> A3["Step 3: Agent access\nvia semantic API only"]
    A3 --> A4["Step 4: Version + audit\nevery definition change"]
    A1 -.- N1["Find contradictions\nacross BI, SQL, notebooks"]
    A2 -.- N2["dbt Semantic Layer\nDatabricks metric views"]
    A3 -.- N3["No raw SQL access\nfor agents"]
    A4 -.- N4["Audit trail for\nregulatory compliance"]
    style A1 fill:#1a2540,stroke:#00d4ff,color:#00d4ff,stroke-width:2px
    style A2 fill:#1a2540,stroke:#00d4ff,color:#00d4ff,stroke-width:2px
    style A3 fill:#1a2540,stroke:#00d4ff,color:#00d4ff,stroke-width:2px
    style A4 fill:#1a2540,stroke:#00d4ff,color:#00d4ff,stroke-width:2px
    style N1 fill:#1a2540,stroke:#ffb347,color:#ffb347,stroke-dasharray:5
    style N2 fill:#1a2540,stroke:#ffb347,color:#ffb347,stroke-dasharray:5
    style N3 fill:#1a2540,stroke:#ff6b6b,color:#ff6b6b,stroke-dasharray:5
    style N4 fill:#1a2540,stroke:#00ff88,color:#00ff88,stroke-dasharray:5

I'm not sure step 2 scales cleanly across organisations with hundreds of metrics and deep political history around definitions. The tooling handles the technical side. The organisational negotiation -- who owns the "true" definition of customer lifetime value -- is where most implementations stall. Budget time for it.

Example: What Ungoverned Semantics Look Like in Claims

Lemonade, the AI-first insurer, built its reputation on speed -- famously settling a claim in three seconds using its AI claims bot. That speed is possible because Lemonade controls its metric definitions end-to-end. "Claim complexity" means one thing across the system because they designed it that way from day one.

Now consider the typical insurer attempting something similar. Underwriting defines claim complexity by coverage overlap. Fraud detection defines it by pattern anomalies. Claims operations defines it by estimated processing time. An agentic triage system that picks one definition -- whichever it finds first in the data catalogue -- will route claims incoherently. Low-complexity claims with unusual patterns get fast-tracked. Genuinely complex claims with straightforward patterns go to investigation.

The fix is a governed semantic layer with a single "claim complexity" metric -- a composite score incorporating all three perspectives, with agreed weighting. When the definition needs updating, it changes in one place and every agent's behaviour changes consistently. Lemonade's advantage is not just AI speed. It is semantic clarity baked into the architecture.

Strategic Takeaway

The semantic layer is no longer a reporting nicety. It's the contract between your organisation's agreed-upon reality and the agents acting on that reality. Without it, you're deploying agents into a world where every automated system carries its own private dictionary. That's not an efficiency problem. It's a governance crisis waiting to surface.

Treat the semantic layer as critical infrastructure. Because your agents already do.

Sources

Daniel Piatkowski Data & Analytics veteran shaping AI-native enterprises elicify.ai