Ask three people in a marketing team for the number of active customers and you will often get three numbers. Not because anyone is wrong, but because each person is carrying a slightly different definition in their head. One counts anyone with a login in the last 90 days. Another excludes free-tier accounts. A third quietly knows that the "active" flag in the main table has been broken since a migration two years ago and uses a different table instead.
That last person is doing something important and almost invisible. They are applying tribal knowledge: the unwritten rules about which field means what, which table is canonical, which "revenue" column is gross and which is net of returns. Every experienced analyst carries a private map of these traps, and it is how a human produces a sensible answer from a messy warehouse.
An AI agent has none of that map. Point an agent at your customer data and ask it to build a high-value churn-risk segment, and it will pick a field called revenue and a flag called active and a table called customers because those names look right. It cannot know that revenue includes cancelled orders, that active has been wrong since the migration, or that the canonical customer record lives somewhere else entirely. It will produce a segment, it will look plausible, and it will be wrong. Then, in an agentic setup, it will act on it.
This is the case for a semantic layer. It was a convenience in the dashboard era. For agents, it is closer to a prerequisite.
What a semantic layer actually is
Strip away the jargon and a semantic layer is a shared, governed dictionary that sits between your raw data and anything that asks the data a question. It holds the official definitions: what a metric means, how it is calculated, which tables and joins produce it, which filters belong in it, and who owns it.
When a tool or an agent asks for "monthly active users," it does not have to guess which columns to touch. The semantic layer already knows. It resolves that request to the agreed logic, distinct user identifiers with at least one session in the trailing 30 days, from the table the data team has blessed, and returns a consistent answer no matter who asked.
A practical semantic layer is built from a few object types. Measures are the quantities you sum, count or average, like revenue or order count, each carrying one definition that holds whether you slice it by region, product or month. Dimensions are the categorical and time axes you group by, like customer segment or fiscal quarter. Entities and their relationships are the joins that connect a fact table to the data enriching it, so a customer and the orders, sessions and support tickets attached to them are linked once and reliably. Filters encode business rules directly, so a definition of net revenue carries its returns exclusion rather than relying on whoever writes the query to remember it. Metadata covers ownership, descriptions, certification status that marks trusted definitions, and access controls. Those properties travel with the definition wherever it is used.
The important word in all of this is governed. A semantic layer is not a wiki of suggested definitions. It is the definition, versioned like code, with an owner and a change process, and every consumer bound to it.
Why dashboards tolerated what agents cannot
The semantic layer is not new. It is about as old as business intelligence itself. The French company BusinessObjects, founded in 1990, built a product that let non-technical staff query a relational database without writing SQL, through a metadata model it called a "universe" that mapped raw tables into business-friendly dimensions and measures and hid the joins underneath. BusinessObjects filed a patent for the approach in 1991. The semantic layer, as a named thing, is more than three decades old.
It then had an uneven history. The first wave of self-service BI tools in the late 2000s, Tableau and Qlik most prominently, made dashboards far easier to build but largely dropped the shared semantic model. Anyone could connect to a database and define a metric their own way. The cost, which the industry still pays, was a semantics vacuum where every team and every dashboard defined the same metric a little differently. The 2010s brought a partial fix. Looker treated semantics as code with its LookML modeling language, version-controlled and reusable, and the idea spread.
Here is the part that matters. Through all of that history, inconsistent definitions were a real problem but a survivable one, because a human always sat between the data and the decision. If a dashboard showed a revenue number that looked too high, an experienced person noticed. If two reports disagreed, someone reconciled them, usually by knowing which one applied the returns filter. The semantic layer made that human's life easier and the numbers more trustworthy, but the human was the real safety net. Companies ran for years on spreadsheets and tribal knowledge because the people holding the knowledge caught the errors before they became decisions.
Take the human out of that loop and the safety net goes with them. An agent does not pause at a number that looks off, because it has no sense of what "off" would be. It does not reconcile two definitions, because it does not know there are two. It takes the data at face value, applies confident logic, and produces an answer at machine speed and machine volume. The looseness the dashboard era absorbed becomes a direct path from a bad definition to a bad action. The semantic layer moves from a nice-to-have that improved analyst productivity to load-bearing infrastructure that decides whether an agent is right or wrong.
The failure mode, concretely
Being specific about how this goes wrong matters, because "the agent might make a mistake" is too vague to act on.
Start with the obvious temptation: just let the agent write the SQL. Modern language models are good at turning a plain-English question into a database query, a capability called text-to-SQL, and on public benchmarks they look excellent. The catch is that those benchmarks use small, clean, sensibly named schemas. Real enterprise warehouses do not. Michael Stonebraker, a Turing Award winner who helped build modern database systems, worked on the BEAVER benchmark, which tests leading models against a production-style warehouse. On a real Oracle warehouse, the best models scored around 10 percent accuracy, against the 80 percent and higher those same models post on the tidy academic benchmarks. Supplying the correct tables and join terms by hand only lifted it to roughly 30 percent. Real warehouses defeat text-to-SQL because they are full of cryptic column names, overlapping tables that mean almost the same thing, hundred-line queries, and naming conventions only a long-tenured employee understands.
The dangerous failures are not the queries that error out. Those you catch. The dangerous ones run cleanly, return a number, and are quietly wrong. An agent that joins two tables the wrong way, misses a returns filter, or picks the gross revenue column instead of the net one hands you a confident, well-formatted, incorrect segment. Nothing flags it.
Now put that inside a customer data platform and an agentic journey. The CDP is where customer data is unified and where segments are activated into email, ads, on-site personalization and the contact centre. Suppose an agent is asked to find high-value customers at risk of churning and enrol them in a retention journey with a discount offer. Without a shared definition, the agent decides for itself what "high-value" and "at risk" mean. It might use lifetime revenue gross of refunds, so a serial returner who placed and cancelled large orders reads as a top customer. It might treat a churn flag that is really just 30 days of inactivity as real risk, sweeping in seasonal buyers who were always coming back. The journey fires: discounts go to people who would have bought anyway, while the genuinely valuable, genuinely wavering customers are missed. The campaign runs and the money goes out. The segment was wrong from the first definition, and because the agent acted without a human reading the segment, nobody caught it.
Gartner put a number on the systemic version of this. At its Data and Analytics Summit in 2026, the firm predicted that by 2028, 60 percent of agentic analytics projects relying only on the Model Context Protocol, the common standard for connecting agents to data, would fail for lack of a consistent semantic layer. The point was not that the protocol is flawed. It was that a connection without shared meaning underneath it has nothing solid to stand on.
The named effort to fix it
The industry has noticed, and the response has a name. In September 2025, Snowflake announced the Open Semantic Interchange, an initiative to create a vendor-neutral, open standard for how business metrics and definitions are described, so a definition written once can be understood by any tool or agent. It is co-led by Snowflake, Salesforce, dbt Labs, BlackRock and RelationalAI, with early backing from data and BI companies including Cube, Atlan, Alation, ThoughtSpot, Hex and Mistral AI. In November 2025 the group added more members, among them Google and AWS, putting most of the major data platforms at the table.
The problem the standard targets is fragmentation. Most enterprises do not have one place where metrics are defined. They have several, a definition in the BI tool, another in the warehouse, another buried in a reverse-ETL job, and they do not agree. Without a common format, every connection between a tool and a semantic model is a bespoke translation, and an agent moving across systems re-learns the meaning of "revenue" at every step.
Alongside the standard, the underlying machinery is opening up. In October 2025, dbt Labs open-sourced MetricFlow, the engine behind its semantic layer, under a permissive Apache 2.0 license. MetricFlow takes metric definitions written in plain YAML files and compiles them into the correct SQL for whatever warehouse sits beneath. It is a concrete picture of a modern semantic layer: definitions as readable, version-controlled text, and an engine that turns them into queries so humans and agents both get the same governed answer.
A reasonable question is whether a customer data platform should hold this layer itself. Some CDPs are moving that way, positioning as the governed system of customer context rather than just a profile store. But the more durable pattern keeps the semantic layer as a distinct, shared service. Customer definitions should not be marketing's private property, because finance, product and service all need the same answer for what a customer is worth. The semantic layer sits between the warehouse below and the CDP, the BI tools and the agents above, as common ground all of them query. The CDP then does what it is genuinely good at, identity resolution and activation, on top of definitions it shares rather than owns.
What building one practically involves
A semantic layer is not a product you switch on. It is mostly organizational work, and being honest about that is the difference between a project that helps and one that stalls.
The first task is agreement, and it is the hard one. Someone has to get marketing, finance and product into a room and settle, in writing, what the core terms mean. What counts as an active customer. Whether revenue is gross or net of returns. Which customer table is canonical. These conversations are slow because the disagreements are real, not cosmetic. But this is the actual work. Encoding definitions is easy once they exist. The reason most organizations lack a semantic layer is that they have never forced the agreement.
The second task is encoding those agreed definitions in the tooling, as measures, dimensions, entities, joins and filters, with the messy logic captured once so no downstream query can omit it.
The third task is governance, which separates a semantic layer from a glossary. Every definition needs a named owner, a change process, and a certification status marking which definitions are trusted. When the meaning of "active customer" changes, it changes in one place and propagates everywhere. Treat the layer as governed infrastructure, not a document that drifts.
The fourth task is exposure. The definitions have to be reachable by an open interface, increasingly the Model Context Protocol, so an agent queries the governed metric the same way a BI tool does rather than improvising SQL against raw tables. This is also where you decide what an agent may not touch.
Start narrow. Pick the ten or twenty metrics and the handful of customer definitions that matter most, get those right, then expand. Modelling the whole warehouse before any agent runs is how the effort dies.
Where this leaves a marketing team
The agentic CDP is coming whether or not the groundwork is done. An agent on a flawed data foundation does not fail quietly; it amplifies the flaw, fast, across every channel it can reach. The unglamorous work of agreeing what "customer" and "revenue" and "active" mean is not a tax on the agent project. It is the agent project.
The adoption gap is wide. At its 2026 summit, Gartner reported that around 44 percent of data leaders had implemented a semantic layer, with roughly another 48 percent planning to by 2027. A large share of organizations now buying agentic tools lack the ground those tools require. Gartner's own framing is that organizations which put semantics first could, by 2027, raise the accuracy of their agentic AI by up to 80 percent and cut associated costs by up to 60 percent. Those are projections and should be read as projections, but the direction is not in doubt.
A human analyst can compensate for a chaotic warehouse because they carry the map in their head. An agent cannot. The semantic layer is how you write that map down, agree on it, and hand it to the agent before it touches your customers. Build it first.
Council summary
This post argues that the semantic layer, a convenience in the dashboard era, becomes load-bearing infrastructure once an agent acts on data with no human checking the result. The council verified every named claim against primary sources: the BEAVER benchmark accuracy figures, the BusinessObjects history, the Open Semantic Interchange launch and its expansion to Google and AWS, dbt Labs open-sourcing MetricFlow, and the Gartner predictions from its 2026 Data and Analytics Summit. One fix was made: the Gartner accuracy and cost figure now carries its 2027 horizon. The takeaway for a marketing team is plain. Agree on what "customer," "revenue" and "active" mean, govern those definitions, and do it before an agentic CDP starts acting on the gaps.
Comments