Many organizations have finished, or nearly finished, the first phase of warehouse modernization: data has moved to a cloud platform, pipelines run on modern tooling, and storage costs are under control. Then a new request arrives. Leadership wants employees to ask questions in plain language, and wants AI agents to pull figures into reports, forecasts and workflows. The first pilots look impressive in demos and then produce numbers that finance does not recognize.
The problem is rarely the language model. It is that the warehouse stores data, not meaning. What counts as “active customer,” “net revenue” or “on-time delivery” lives in dashboard formulas, spreadsheet macros and the heads of analysts. In 2026 the industry’s answer is converging on a governed semantic layer, expressed as code, shared by BI tools and AI agents alike. This article explains why that layer has become the second phase of warehouse modernization and how to build it.
Why AI Agents Break on Modernized Warehouses
A modern warehouse may have thousands of tables with technical names, multiple versions of similar datasets, and joins that only make sense to people who built them. A text-to-SQL agent sees the schema and has to guess. It may pick the wrong revenue column, double-count through a many-to-many join, ignore a filter that excludes test accounts, or apply a different fiscal calendar. Each mistake produces a plausible-looking answer, which is worse than an obvious error.
Salesforce describes this as “semantic drift”: storage and transformation have standardized, but business definitions remain locked inside individual tools, so marketing and finance can compute the same metric differently. When AI agents join the mix, drift multiplies, because every agent and prompt can invent its own interpretation. Salesforce’s own State of Data and Analytics research, cited in its January 2026 announcement, found that most data leaders expect agent interoperability to become a business requirement while fearing that inconsistent schemas will limit it.
The Semantic Layer, Revisited for the Agent Era
A semantic layer is a governed model that sits between physical tables and consumers. It defines business entities, the relationships between them, metrics and how to calculate them, dimensions to slice by, and the rules that apply, such as default filters and time grains. Consumers ask for “net revenue by region last quarter,” and the layer generates correct SQL.
The idea is not new; OLAP cubes and BI-tool models played this role for decades. What has changed is where the layer lives and who uses it:
- It lives in the data platform, not in one BI tool. Snowflake semantic views, Databricks Unity Catalog metric views and the open-sourced dbt MetricFlow all place definitions next to the data, governed by the platform’s permissions and lineage.
- It is expressed as code. Definitions are written in YAML or SQL, stored in version control, reviewed through pull requests and tested in CI like any other code.
- It carries context for AI. Modern semantic models include descriptions, synonyms, sample questions and usage instructions intended for language models, not just for humans.
- It is becoming portable. The Open Semantic Interchange initiative aims to make definitions movable between tools.
The Open Semantic Interchange
The Open Semantic Interchange (OSI) was launched in September 2025 by Salesforce, Snowflake and dbt Labs with other industry participants, and Databricks and others have since joined the working group. Its goal is a vendor-neutral way to represent datasets, metrics, dimensions, relationships and AI context so that a definition authored once can be read by many tools. The first specification was published in January 2026 under the Apache 2.0 license, and the effort has moved to the Apache Software Foundation as an incubating project. It is early, and tool support will take time, but it signals that the industry expects semantic definitions to be shared infrastructure rather than proprietary features.
An AI agent is only as trustworthy as the definitions it queries through. Put business meaning in a governed, versioned semantic layer before you put agents in front of executives.
Architecture of an AI-Ready Warehouse
An AI-ready warehouse adds a few deliberate layers to the modern stack:
- Curated data products. Clean, documented tables per business domain, owned by named teams, with tests and freshness expectations. Raw and staging layers stay out of the agent’s view.
- Semantic layer. Entities, metrics and dimensions defined as code over the curated products, with descriptions, synonyms and default filters.
- Access and policy layer. Row-level security, masking and role-based permissions enforced by the platform, so an agent acting for a user sees only what that user may see.
- Agent interface. Natural language and agent tools query the semantic layer first, falling back to raw SQL only for approved, well-described datasets. Protocols such as the Model Context Protocol are commonly used to expose these capabilities to agents.
- Observability and feedback. Logs of questions, generated queries, results and user feedback, reviewed regularly to improve definitions and catch misuse.
The key design principle is that agents should prefer governed metrics to free-form SQL. When a question maps to a defined metric, the answer is consistent with every dashboard. When it does not, the system should say so, or route the request to an analyst, rather than improvise.
A Step-by-Step Playbook
Step 1: Pick the questions that matter
Start from decisions, not tables. Interview leaders in two or three domains and collect the twenty to fifty questions they ask most often. These define the first set of metrics and dimensions, and they double as an evaluation set for the agent.
Record each question with the expected answer for a fixed period, the person who validated it and the data products it depends on. Include a few deliberately tricky questions: ones that span fiscal and calendar years, involve returns or cancellations, or require a filter people often forget. Those edge cases are where agents fail first, and catching them in the evaluation set is far cheaper than catching them in a board pack.
Step 2: Reconcile definitions before encoding them
Expect to find multiple definitions of the same metric. Resolve them with business owners and document the decision, including edge cases: refunds, intercompany transactions, test accounts, currency conversion and fiscal calendars. Encoding an unresolved definition simply automates the disagreement.
Step 3: Model curated data products
Ensure each metric is backed by a curated, tested table with a clear grain. If a metric requires joining six staging tables with complex logic, build the data product first; the semantic layer should be thin and declarative.
Step 4: Author the semantic model as code
Define entities, relationships, metrics and dimensions in your chosen layer. Add human-readable descriptions, synonyms people actually use, sample questions and explicit instructions such as “revenue always excludes internal accounts.” Store everything in the same repository as your transformation code.
Step 5: Test like software
Write tests that assert known metric values for fixed periods, check that joins do not fan out, and verify that default filters apply. Run the evaluation question set against the agent on every change and track accuracy over time. A falling score is a release blocker.
Step 6: Enforce access per user
Agents should act with the identity and permissions of the person asking, not with a powerful service account. Validate row-level security and masking through the agent path specifically, because some integration routes do not enforce every policy.
Log the identity behind every agent query, the metric or tables used and the result size. These logs serve three purposes: security review, usage analytics that show which metrics deserve investment, and a debugging trail when someone questions a number. Retain them under the same policies as other audit data, and make sure sensitive values in prompts and results are handled according to your data classification rules.
Step 7: Launch narrowly and expand
Release to a small group in one domain, collect feedback, fix definitions and only then expand. Publish which questions the system can and cannot answer so expectations match capability.
Choosing Where the Semantic Layer Lives
There is no single correct home for the semantic layer. Consider these options and criteria:
- Platform-native layers such as Snowflake semantic views or Databricks metric views are tightly integrated with governance and the platform’s own AI assistants. They suit organizations committed to one primary platform.
- Transformation-layer semantics such as dbt MetricFlow keep definitions next to transformation code and can serve multiple consumers. They suit teams already standardized on dbt.
- Independent semantic platforms sit across multiple warehouses and BI tools. They suit multi-platform estates but add another component to operate.
Decision criteria include how many data platforms you run, which BI and AI tools must consume the definitions, where your engineers prefer to work, and how much you value portability. Whatever you choose, favor options that commit to open interchange, so definitions can move if your tooling changes.
A Worked Example: Plain-Language Sales Analytics
Imagine a distributor whose modernized warehouse holds orders, invoices, returns and customer data. Sales leaders want to ask questions such as “Which regions missed margin targets last month and why?” An early pilot that pointed an agent directly at the warehouse schema produced inconsistent answers, mainly because there were three revenue columns and two customer hierarchies.
The team collects forty frequent questions from sales and finance, and finds four competing definitions of gross margin. Finance and sales agree on one, documented with rules for returns, rebates and freight. Engineers build curated order and margin tables at a clear grain, then define a semantic model with metrics for revenue, gross margin and margin percentage, dimensions for region, customer segment and product family, and synonyms like “GM” and “profitability.”
Tests lock in known monthly values. The forty questions become an evaluation suite run on every change. The agent is configured to answer from defined metrics only and to explain when a question falls outside the model. After a month with a pilot group, the evaluation score is stable, feedback has added a dozen synonyms, and the same definitions now also power the sales dashboards, ending a long-running debate about whose margin number is right.
Just as important are the questions the system declines. When sales leaders ask about pipeline forecasts, which are not yet modeled, the agent says so and points to the existing forecast report. That honest boundary does more for adoption than any clever answer, because users learn that whatever the agent does return can be trusted. The next quarter’s roadmap is set by the most frequently declined questions.
Measuring Whether the Warehouse Is Really AI-Ready
AI readiness is easy to claim and hard to prove, so define measures before launch and report them alongside traditional platform metrics. Useful indicators include:
- Evaluation accuracy. The share of questions in the fixed evaluation set that the agent answers correctly, tracked per domain and per release.
- Semantic coverage. The share of real user questions that map to a defined metric rather than falling back to free-form SQL or being declined.
- Definition consistency. The number of metrics with more than one active definition across dashboards, spreadsheets and agents, which should trend toward zero.
- Time to answer. How long it takes a business user to get a trusted figure compared with the previous request-to-analyst process.
- Policy incidents. Any case where an agent returned data a user was not entitled to see, which should be treated as a security incident.
Review these monthly with domain owners. Low coverage tells you which metrics to model next; falling accuracy usually points to a schema change that bypassed the semantic layer or a definition that drifted. Publishing the numbers also builds trust, because users can see that quality is managed rather than assumed.
Pitfalls to Avoid
- Boiling the ocean. Modeling the entire warehouse before launch delays value indefinitely. Start with one domain.
- Letting agents bypass the layer. If agents freely write SQL against raw tables, the semantic layer becomes optional and drift returns.
- Service-account shortcuts. Agents with broad credentials can leak data across roles.
- No evaluation set. Without fixed test questions, quality cannot be measured or protected.
- Definitions without owners. Every metric needs a business owner who approves changes.
Outlook and Conclusion
Over the next two years, expect semantic definitions to become as standard as table schemas: authored as code, shared through open interchange formats, and consumed by BI tools, notebooks and AI agents alike. Platforms will compete on how well their assistants use these definitions, and organizations with mature semantic layers will be able to switch or combine agents with far less risk.
For data leaders, the message is that warehouse modernization is not finished when the data has moved. Making the warehouse AI-ready means encoding business meaning in a governed, tested, versioned semantic layer and routing agents through it. That work is less glamorous than an agent demo, but it is what turns plain-language analytics from an impressive prototype into a trusted everyday tool.
How Hanoi Technology Can Help
Hanoi Technology helps organizations build curated data products and governed semantic layers so BI tools and AI agents work from the same trusted definitions.