Allocating Intelligence

You have decided your organization needs a semantic layer. You have read the vendor comparisons. You understand that AI agents without governed business logic are, as one industry analyst put it, "hallucination engines." Now comes the part nobody writes about: how do you actually build one?

Most semantic layer implementation guides are thinly disguised product documentation. They tell you how to configure a specific tool. They do not tell you how to get your CFO and your VP of Marketing to agree on what "revenue" means. They do not tell you which metrics to define first. They do not tell you how to avoid the political minefields that have killed more semantic layer projects than any technical limitation.

I have implemented semantic layers at companies ranging from 15-person startups to platforms processing millions of transactions. The technical work is rarely what stalls the project. The organizational work is what determines success or failure. Here is the practical guide I wish someone had given me ten years ago.

Step 1: Start With the Contested Metrics

Every organization has metrics that cause arguments. Revenue is the classic example. Sales includes pending invoices. Finance excludes them until payment clears. The CEO gets two different numbers in the same board meeting. Everyone gets quiet.

That $800,000 gap is not a data quality issue. Both numbers are "correct." They are just calculated differently. This is the exact problem a semantic layer solves.

Your first move is not to open a YAML editor. Your first move is to identify the five to ten metrics that generate the most disagreement across your organization. Talk to the heads of finance, marketing, sales, and product. Ask each of them: which numbers do you not trust when they come from another department?

Write those metrics down. Those are your first semantic layer definitions. Not because they are the most important metrics in the business, but because resolving them demonstrates immediate, visible value. When the CEO stops getting conflicting revenue numbers, every stakeholder in the building understands what the semantic layer does.

Step 2: Define Ownership Before You Define Logic

Every metric needs an owner. Not a tool. Not a team. A person. Someone who is responsible for the definition, reviews changes, and resolves disputes when the definition needs to evolve.

The ownership model I have seen work best in practice: finance owns financial metrics (revenue, margin, cost), product owns product metrics (active users, retention, engagement), marketing owns acquisition metrics (CAC, conversion rates, attribution). The data team does not own any metric definitions. The data team owns the infrastructure that makes the definitions operational. This distinction matters because it prevents the data team from becoming a bottleneck for every metric change request.

Document ownership in a simple table: metric name, owner, last reviewed date, approved definition. This table lives alongside your semantic model definitions in version control. Every pull request that changes a metric definition requires approval from the metric owner. This is not bureaucracy. It is the governance mechanism that prevents metric drift over time.

Step 3: Pick Your Architecture Based on Your Stack

Your architecture choice depends on three factors: where your data lives, what tools consume it, and how your team works.

If your team already runs dbt and your data lives primarily in one warehouse, the dbt Semantic Layer is the lowest-friction starting point. Your metrics are defined in the same YAML files, same Git repository, same CI/CD pipeline as your transformations. The workflow overhead is close to zero.

If you need to serve metrics to multiple applications, embedded analytics, custom APIs, and AI agents, Cube gives you the broadest API surface. REST, GraphQL, SQL, MDX, and DAX interfaces mean every consumer gets governed metrics through the protocol it already understands.

If your enterprise runs multiple BI tools and has a large base of Excel power users, AtScale's virtualization approach lets you deploy a semantic layer without changing how anyone currently accesses data. Excel still connects via OLAP. Tableau still connects via its native interface. The semantic layer is invisible to the end user.

If your data lives entirely in Snowflake or Databricks, their native semantic capabilities (Semantic Views and Metric Views respectively) offer the fastest path to production with zero external dependencies.

The wrong move is to spend three months evaluating tools before defining a single metric. Pick the architecture that matches your current stack. You can migrate later. The Open Semantic Interchange standard is specifically designed to make semantic definitions portable across tools. Getting started matters more than getting the tool choice perfect.

Step 4: Build the First Ten Metrics in a Sprint

Time-box your first implementation to two weeks. Define ten metrics. Deploy them to production. Connect at least one downstream tool. Ship it.

The goal of the first sprint is not completeness. It is proving the workflow works end to end. You need to validate that metric definitions can be authored, reviewed, deployed, and consumed by a real BI tool or AI agent before you invest in building out hundreds of definitions.

Here is the sprint structure that has worked reliably across my implementations:

Days 1 through 3: Definition workshops. Get the metric owners from Step 2 in a room. For each contested metric, agree on exactly one definition. Write it down in plain language first. "Revenue is the sum of all completed order amounts, minus refunds processed within the same fiscal period, excluding gift card purchases." Precision matters. Ambiguity in the English definition becomes ambiguity in the SQL.

Days 4 through 7: Semantic model authoring. Translate the plain-language definitions into your chosen tool's modeling format. In dbt, these become semantic models with entities, measures, and dimensions defined in YAML. In Cube, these become cubes and views in JavaScript. In AtScale, these become dimensions and measures in the modeling canvas. Write tests that validate the metric values against known correct outputs.

Days 8 through 10: Integration and validation. Connect the semantic layer to one downstream consumer. This could be a BI dashboard, a Slack bot, or an AI agent. Run the contested metrics through the new pipeline. Compare the outputs to the numbers stakeholders currently see. Resolve any discrepancies. The first time the CFO and the VP of Marketing see the same revenue number from different tools, the semantic layer sells itself.

Step 5: Expand Systematically, Not Organically

After the first sprint, the temptation is to let teams add metrics whenever they need them. Resist this. Organic growth without governance leads to exactly the metric sprawl the semantic layer was supposed to prevent.

Establish a cadence: monthly metric review sessions where the data team and metric owners assess which new metrics should be added, which existing metrics need updated definitions, and which metrics should be deprecated. Version-control every change. Require code review for every new metric definition, just like you would for any other production code change.

The 80/20 rule applies aggressively to semantic layers. Twenty percent of your metrics will serve 80% of your organization's analytical needs. Identify those high-leverage metrics first. A semantic layer with 30 well-governed metrics is infinitely more valuable than one with 300 metrics where nobody is sure which definitions are current.

Step 6: Connect AI Agents to Governed Logic

Once your semantic layer is in production with governed metrics, you have the foundation for trustworthy AI. This is where the investment pays compound returns.

The Model Context Protocol (MCP), open-sourced by Anthropic, provides a standardized interface for AI agents to query semantic definitions directly from governed models. Instead of writing custom prompts that embed business logic (which drift and break), your agents query the semantic layer for the canonical definition of every metric they need.

Cube offers a dedicated AI API endpoint. AtScale ships an MCP Server. dbt exposes metric definitions through JDBC and GraphQL. The tooling exists. What matters is that your AI agents are grounded in the same governed definitions as your dashboards.

Without this step, your AI agents are querying raw tables with no understanding of what the data means. They will generate syntactically correct SQL that is semantically wrong. They will return numbers that look plausible but diverge from the definitions your organization has agreed on. Internal testing across the industry shows that LLM accuracy on business questions improves from roughly 40% without a semantic layer to over 83% when grounded in governed definitions.

That accuracy gap is the difference between an AI agent your CFO trusts and one that gets turned off after the first wrong answer in a board meeting.

The Pattern That Never Changes

In 2018, companies hired data scientists and gave them a laptop. The data scientists spent 80% of their time cleaning data because the data foundation did not exist.

In 2022, companies built dashboards that nobody trusted because finance and marketing defined revenue differently.

In 2026, companies are deploying AI agents on data without a semantic layer, and those agents are confidently returning wrong answers.

Different era. Same mistake. The layer that was skipped changes, but the pattern is identical. For every dollar spent on AI, six should go to the data architecture underneath it. The semantic layer is the highest-leverage investment in that architecture. It is the layer that translates what your data means into something every tool, every person, and every AI agent can trust.

Start with the contested metrics. Define ownership. Pick an architecture. Ship ten metrics in two weeks. Expand systematically. Connect your AI agents to governed logic. That is the implementation playbook. The technology is solved. The organizational discipline is what separates the companies that get ROI from AI from the 61% that do not.