Two Agents, Two Revenue Numbers: The Layer Your AI Analytics Stack Is Missing

Why Do Two Agents Report Different Revenue?

The failure mode is now common enough to be predictable. Finance asks the AI assistant for last quarter's revenue by region. Sales asks its own agent, connected to the same warehouse through a different MCP server, the same question. The two numbers differ by seven percent. Both agents produced clean, well-formed SQL. Both returned an answer in under four seconds. Neither flagged any uncertainty, because neither had any reason to.

The discrepancy is not a bug in either agent. It is the organisation's own ambiguity, rendered visible at machine speed. Finance recognises revenue net of refunds and excludes intercompany transfers. Sales counts bookings at signature. Somewhere in the warehouse there are four tables with a column called 'amount', two of them in cents, one of them including tax, one of them a staging table nobody deprecated. A human analyst carries that knowledge in their head and applies it without thinking. An agent reading the schema has no way to know any of it exists.

This is the problem Gartner put a number on. At the Data & Analytics Summit in March 2026, analyst Andrés García-Rodeja predicted that 60% of agentic analytics projects relying solely on the Model Context Protocol will fail by 2028 because there is no consistent semantic layer beneath them. That is a striking claim to make about a protocol most enterprises adopted in the last eighteen months, and it deserves to be read carefully. Gartner is not saying MCP is the wrong choice. It is saying MCP solves a different problem than the one teams are using it to solve.

The same summit produced a second number worth sitting with: only one in five AI investments currently shows measurable ROI, while four out of five organisations increased AI spending. The gap between those two figures is not explained by model quality. In 2026, the frontier models are extraordinarily good at writing SQL. They are writing it against data nobody has taught them to interpret.

Why Isn't a Schema Enough for an Agent?

When you point an agent at a warehouse, you are handing it a list of table names, column names, and types. What you are not handing it: which of those tables is the source of truth, how the business defines the metrics those columns feed, which joins are valid and which produce silent fan-out, what a NULL means in this particular column versus that one, and which of the seventeen date fields represents the event the question is actually about.

The accuracy data on this is unusually clean, because the vendors publishing it have every incentive to show that raw schema access works and it still does not. Snowflake benchmarked Cortex Analyst across four BIRD-SQL datasets and found that average accuracy rose from 57% to 78% purely by adding a semantic model, with no change to the underlying LLM. The per-dataset spread is instructive: the thrombosis dataset went from 45% to 70%, the debit card dataset from 52% to 83%. The messier and more domain-specific the data, the larger the lift. Twenty points of accuracy from writing down what your columns mean is not a marginal optimisation, it is the difference between a system people trust and a system people quietly stop using.

dbt Labs' 2026 benchmark points the same way from a different angle, with 64.5% overall accuracy on raw text-to-SQL against 72.7% through a modelled semantic layer, and individual frontier models climbing into the high nineties once the modelling is in place. Note what is not moving those numbers: the model. Everyone reporting these results is comparing the same LLM against itself.

The benchmark itself is worth understanding, because it is the closest public proxy for enterprise conditions. BIRD runs 12,751 question-SQL pairs against 95 real databases totalling 33.4GB across 37 professional domains, with deliberately dirty values and questions that require external business knowledge. Top systems now reach roughly 82%, against human expert performance of 92.96%. And when the benchmark adds interaction, ambiguous questions that require the model to ask a clarifying question rather than guess, the best results collapse to around 16%.

That last figure is the one engineering leaders should internalise. Real business questions are ambiguous by default. 'How are we doing in DACH this quarter' contains at least four undefined terms. A model with only a schema to work from will resolve every one of those ambiguities silently, pick a plausible interpretation, and present the result with the same confidence it would apply to a row count. Gartner's summit summary put it bluntly: in 2026, the problem is AI being too confident about bad data.

It gets worse in the direction nobody tests. A wrong number that is obviously wrong gets caught. A number that is wrong by seven percent, in the right currency, with the right shape, formatted into a board deck, does not.

Does MCP Solve the Agreement Problem?

Model Context Protocol did something genuinely important: it made tool access a standard rather than a bespoke integration per agent, per vendor, per team. That is why adoption moved as fast as it did. But MCP is a transport and discovery standard. It describes how an agent finds a tool and calls it. It says nothing about whether the thing on the other end returns a governed, agreed, auditable definition of a business concept.

So what happened in most enterprises is entirely rational and entirely wrong: someone stood up an MCP server over the warehouse, granted it a service account, and pointed three agents at it. The agents can now reach everything. That is precisely the failure Gartner is forecasting. Reach is not comprehension, and it is not authority. Ten teams connecting ten MCP servers to ten copies of the same tables produces ten dialects of the truth, and the protocol layer has no opinion about which one is correct.

The correction is architectural rather than technical heroics. The agent should not be issuing SQL against raw tables at all. It should be selecting from a catalogue of governed metrics and dimensions, expressed in business terms, resolved into SQL by a layer that owns the joins, the filters, and the definitions. MCP is still the right way to expose that catalogue. It is just that the thing being exposed changes: not a generic 'run this SQL' tool, but 'list the available metrics' and 'query this metric by these dimensions with these filters'.

The tooling caught up faster than most teams noticed. dbt, Cube, AtScale and others now ship MCP interfaces over their semantic layers, so 'the agent selects from governed definitions' is a concrete protocol call rather than an architectural aspiration. Cube's open-source core exposes governed metrics over SQL, REST, GraphQL and MCP with row-level control. The dbt MCP server exposes existing metric definitions from projects teams already maintain, which for most organisations is the shortest path from where they are to governed AI analytics.

There is also a standards story now, which matters for anyone worried about writing definitions into a vendor's proprietary YAML. The Open Semantic Interchange specification, a vendor-neutral format for semantic metadata, has backing from Snowflake, dbt Labs, Cube, AtScale, Databricks, Salesforce and Tableau among more than forty partners. Definitions written against it are portable in a way that dashboard logic embedded in a BI tool never was.

Who Is the Agent Actually Querying As?

Here is the part that turns a data quality problem into a security incident. When you connect an agent to a warehouse through a service account, every user of that agent inherits the service account's privileges. The salesperson asking about pipeline and the HR business partner asking about headcount are, at the database layer, the same identity.

Row-level security in the warehouse does not save you here, because the warehouse sees one principal. Neither does prompt-level instruction. Telling an agent 'do not reveal salary data to non-HR users' is a policy enforced by a probabilistic system that an adversarial or merely curious user can talk around. We have watched teams discover this the hard way when an agent helpfully answered a compensation-band question for someone three levels away from having any business seeing it.

A semantic layer is where this gets enforced properly, because it is the only component in the path that knows both who is asking and what the data means. The user's identity propagates from the agent through to the layer, the layer applies row-level and column-level policy against governed dimensions, and the SQL that reaches the warehouse is already scoped. Fine-grained access control at the metric and dimension level is now standard across the mature semantic layer products, and it is the single strongest argument for putting one in the path even if you were perfectly happy with your text-to-SQL accuracy.

This is also where the compliance work starts to compound in your favour. If your organisation is already building for the EU AI Act's transparency duties or documenting third-party data access, an identity-aware semantic layer gives you one place to log every question asked, every metric resolved, and every row policy applied. Gartner expects spending on AI governance platforms to grow from $492 million in 2026 to over $1 billion by 2030, and a good portion of that spend is organisations retrofitting an audit trail they could have got for free by putting the semantic layer in the path from day one.

What Does an Agent-Ready Semantic Layer Contain?

The phrase 'semantic layer' has been in the BI vocabulary for twenty years, which causes a specific confusion: teams assume they already have one because they have a BI tool with saved metrics. A layer built for human analysts and a layer built for agents overlap, but the second one has requirements the first never needed.

Governed metrics come first. Each business metric needs one definition, one owner, and one implementation: the SQL expression, the base table, the valid grain, the required filters, and the exclusions. 'Net revenue excludes refunds, chargebacks and intercompany transfers, recognised at fulfilment date' is a sentence that has to live somewhere machine-readable, not in a finance team's shared understanding.

Then dimensions and valid joins. The layer must encode which dimensions a metric can legally be sliced by and how the joins are performed, because this is where agents produce their most damaging errors. A fan-out join that double-counts revenue across order lines produces a number that is wrong in a direction nobody notices until it is quoted externally.

Then the things that exist specifically for agents. Synonyms and business vocabulary, so that 'churn', 'attrition', 'logo loss' and 'cancellations' route to the same governed metric. Verified query examples, a set of question-to-query pairs that ground the model in how this business actually asks things. Entity resolution rules, so 'DACH' resolves to a defined region membership rather than a wildcard string match on a country column. Freshness and grain metadata, so the agent can say 'this data is complete through Tuesday' instead of quietly reporting a partial week as a decline. And explicit ambiguity handling: a documented list of terms the agent must ask about rather than resolve.

That last one is the hardest cultural sell and the highest-value item on the list. An agent that says 'do you mean bookings or recognised revenue' is a better system than one that always answers. The BIRD interaction results suggest most systems will never volunteer that question unless you build the affordance for it deliberately.

Who Actually Does This Data Engineering Work?

The reason so many organisations are stuck is not that they disagree with any of the above. It is that the work is unglamorous, cross-functional, and lands on the team that is already the bottleneck. Defining net revenue requires finance to commit to a definition in writing. Encoding valid joins requires someone who understands the warehouse's history, including which tables are load-bearing and which are archaeological. Building verified query sets requires sitting with the people who ask the questions.

The adoption numbers show exactly this shape. 44% of data and analytics leaders have implemented semantic layers, with a further 48% planning to by 2027. Nearly everyone intends to do this. Roughly half have. The gap between intention and implementation is staffing, not conviction.

The same research contains the most useful budgeting signal I have seen this year: organisations reporting the highest satisfaction with their AI programmes invest 1.78 times more in foundations than in tools, with foundations accounting for roughly 60% of total AI spend. Most organisations have that ratio inverted. They bought agent platforms, model credits and copilot seats, and left the data groundwork to be done by whoever had spare capacity, which is nobody. Meanwhile 28% of leaders admit zero confidence in the data quality feeding their AI systems, and only 37% are confident in their data practices overall.

This is the kind of work where a dedicated development team earns its keep, and it is worth being specific about why. A semantic layer build is a three to six month engagement with a clear artefact at the end, it requires sustained context about one organisation's warehouse rather than generic expertise, and it does not need to compete for the attention of the in-house engineers keeping the product roadmap moving. What it does need is timezone overlap, because the work is interview-driven: you cannot define net revenue without a live conversation with the person who owns the number.

That is the practical argument for nearshore delivery on this class of work specifically. A team in Belgrade shares a working day with Frankfurt, Amsterdam and London, which means the finance workshop happens on Tuesday afternoon and the metric definition is in version control on Wednesday. The same engagement run from a twelve-hour offset turns each definitional question into a twenty-four hour round trip, and a semantic layer build is nothing but definitional questions. At StepTo we staff this pattern with named senior data and backend engineers who stay with the codebase, because the value of the layer is entirely in the accumulated understanding written into it.

How Do You Test a Semantic Layer?

A semantic layer without evaluation is an untested dependency in the path of every executive decision. And the eval problem here is genuinely different from the one your application team solved for the product's AI features, because correctness is defined by the business, not by a schema.

Start with a golden question set. Fifty to two hundred real questions, collected from Slack, from BI ticket queues, from the analysts who field them, each with an agreed correct answer and the correct SQL. Include the ugly ones: questions with ambiguous time ranges, questions that reference a metric under an informal name, questions whose correct answer is 'that data does not exist at this grain'.

Then run three distinct checks rather than one. Execution accuracy asks whether the returned result matches the expected result. Metric fidelity asks whether the agent used the governed definition or invented an equivalent-looking one, which is the check most teams skip and the one that catches the seven percent discrepancies. Refusal behaviour asks whether the agent correctly declined or asked for clarification on the questions designed to be unanswerable.

Wire this into CI against your semantic layer repository. Every change to a metric definition, every new dimension, every join modification runs the suite. This is the mechanism that stops the layer from drifting back into the state you started in, where definitions live in people's heads and nobody can tell you when 'active user' changed meaning. The teams doing this well treat the metric layer with the same change discipline they apply to a public API, because functionally that is what it now is: a contract consumed by systems that cannot ask a follow-up question.

Publish the scores. An agent that answers 94% of the golden set correctly and declines cleanly on the rest is something a CFO can be told about honestly. An agent whose accuracy nobody has measured is a liability with a chat interface, and everyone senior enough to matter will eventually work that out.

How Do You Scope This to Ninety Days?

The instinct on hearing all this is to model the entire warehouse before letting an agent near it. That project takes eighteen months, loses sponsorship at month nine, and delivers nothing. The alternative is to pick one decision domain and make it genuinely trustworthy.

Weeks one to three: pick the domain and harvest the questions. One area, revenue or pipeline or support performance, chosen because a real team asks real questions about it weekly. Collect those questions verbatim. Identify the ten to fifteen metrics that answer most of them. Name an owner for each, from the business, not from the data team.

Weeks four to eight: model and govern. Write the metric definitions, the valid dimensions, the joins, and the exclusions into your semantic layer of choice, in version control, reviewed like code. Add synonyms and verified query examples. Wire identity propagation end to end so the layer sees the human, not a service account, and encode the row and column policies for the domain.

Weeks nine to eleven: evaluate and iterate. Build the golden set from the harvested questions, run the three checks, and fix what fails. Expect the first run to be worse than you hoped and the failures to be concentrated in ambiguity rather than SQL generation. That is the normal shape of this result and it is the argument for having done the eval work at all.

Week twelve: expose it over MCP and let the domain team use it, with the accuracy figures published alongside. Then take the second domain, which will move roughly twice as fast because the entity resolution, the identity plumbing and the eval harness already exist. This is also the point at which the layer starts paying for itself outside the agent use case entirely, because the same governed definitions serve your BI tools, your embedded product analytics, and any AI automation you build downstream. Gartner expects universal semantic layers to be treated as critical infrastructure alongside data platforms and security by 2030, and the market forecast reflects it: growth accelerating from 16% in 2026 to 30% by 2031, the fastest-growing sub-segment of the entire data intelligence stack.