Introduction
Enterprise data architectures were designed around a single, comfortable assumption: a knowledgeable human would always sit at the end of the pipeline.
The traditional flow looked like this:
The platform’s job was simple: collect, transform, and present, whilst interpretation was the human's problem.
In reality, analysts were doing far more heavy lifting than any architecture diagram let on. A typical analyst already knew which table was authoritative, what cryptic abbreviations meant, whether "revenue" referred to gross billings or recognised revenue, whether Q2 meant the calendar quarter or the fiscal year, and when a number looked weird enough to cross-check.
Most of that organisational knowledge never existed formally inside the data platform. People just carried it around in their heads.
Take a simple output: revenue = 12.4
Is that $12.4 million or £12.4 million? Gross billings or net recognised revenue? Actuals or forecast? Calendar Q2 or Fiscal Q2?
The value itself might be 100% correct, but the meaning could be ambiguous. Previously, that was fine since humans bridged the gap. But this is now a bottleneck in this agentic era - however Databricks has already solve this problem too.
The agent problem
AI agents change the role of the data platform.
The traditional path is now more like:
Sources → Data Platform → Agent → Tool → Business System
We are no longer simply presenting information for someone to interpret. The AI agent is increasingly performing part of that interpretation itself, and in some cases using the result to decide what happens next.
That means context which previously lived in people's heads has to become part of the architecture.
To see where this starts to matter, I created a mock finance environment in Databricks.
The underlying data was deliberately representative of what you might find inside an established enterprise system.
A typical record contained fields such as:
geo_cd, prod_cd, metric_cd, scen_cd, amt_lc_m, amt_grp_m
And values such as:
EU, ENT, NREV, ACT, FCST, BUD
None of these values are incorrect.
In fact, someone who has worked with the finance data for years might barely notice the ambiguity.
They know that EU means Europe, NREV means Net Recognised Revenue, ACT represents actual performance, amt_lc_m means amount in local currency and amt_grp_m is equivalent group reporting value in GBP millions.
They also know context intuitively through their experience, for example, when Finance talks about performance, they are not asking which region generated the most revenue. What they mean is how actual Net Recognised Revenue performed against the approved budget.
That last definition is particularly important because it cannot be discovered simply by reading the rows of data.
I started with a straightforward question:
What was European revenue in FY26 Q2?
On the first run, Genie had access to the underlying tables but not the additional business semantics that I'll be showing later. The challenge I was testing for was whether the LLM knew what a particular question means by revenue.
And Genie got it right.
Even without the semantic layer.
The reason is modern AI models are increasingly capable of inferring meaning from table structures, values and relationships. This means that a semantic layer should not be constructed for artificially simple problems that the model is already capable of solving.
So I made the question harder, no additional context and gave it to genie.
Which region performed best in FY26 Q2, and which product was the biggest driver of that performance?
This looks like a perfectly normal question from a Finance Director.
But it contains a business rule.
What does performed best mean?
The region with the highest revenue?
The region with the fastest growth?
The region furthest above forecast?
The region furthest above budget?
There is no universally correct answer.
The answer depends on how this particular organisation defines performance.
Without that context, the agent has to choose.
And that is what happened.
With no definition to anchor on, the agent made a reasonable choice. It read performed best as highest total revenue and answered North America, the region with the largest absolute revenue in the quarter.
Nothing about that answer is wrong. But it quietly encodes an assumption the business never actually agreed to.
This is where the semantic layer changed the problem.
Using a Databricks metric view, I moved the Finance definitions into the platform itself.
Revenue became actual Net Recognised Revenue.
Plan became Approved Budget Revenue.
Revenue Variance became Actual Revenue minus Approved Budget.
And Performance became Actual Revenue divided by Approved Budget.
The underlying financial records are unchanged, what changed is that a piece of organisational knowledge that previously existed only implicitly now has an explicit, governed definition.
I then asked exactly the same question again.
Which region performed best in FY26 Q2, and which product was the biggest driver of that performance?
This time the answer was different.
Instead of North America, the agent named Europe as the top-performing region, roughly 103% attainment against the approved plan, with Enterprise the largest contributor to that variance.
Same question. Same underlying data, but a different answer and the one Finance would actually give.
Measured by absolute revenue, North America still leads. But measured against the approved plan, it is the only region that came in below budget, 98% attainment, the lowest of the three.
The region that looked strongest on raw revenue was the weakest on the measure the business actually uses to judge performance.
Without the semantic layer, the agent had no way to know what each of those measures meant. With it, there is nothing left to guess: the two readings are simply two defined measures, and the agent answered the one the business intended.
That is the value of the semantic layer.
It does not exist because AI is incapable of interpreting raw data but because enterprise questions eventually depend on concepts that cannot be reliably inferred from the data alone.
The model can understand the rows while the organisation must define what the rows mean.
Now the AI agent no longer has to infer which valid measure the business intends when someone asks for performance.
From tacit knowledge to infrastructure
This issue goes far beyond a single feature or tool. For decades, employees have acted as an invisible semantic layer. They held the definitions, exceptions, and edge cases in their heads.
Agents make that hidden reliance impossible to ignore. If software is going to analyse data directly, that tribal knowledge has to move out of people’s heads and into machine-readable infrastructure.
Data quality alone isn't enough anymore. A data platform now needs to explicitly communicate:
- What a metric actually means
- Which source is authoritative
- Whether the dataset is current
- Who has permission to see it
- What actions can safely be taken based on it
- Capture those definitions as governed metrics rather than tribal knowledge. In Databricks, that means metric views in Unity Catalog.
- Make the authoritative source explicit, so the agent is not guessing between three tables that all look plausible.
- Decide, and enforce, what an agent is allowed to do with each metric. Reading a number and acting on it are different levels of trust.
Unity Catalog is no longer useful only as a catalogue of tables. Metric views can encode shared business definitions. Genie can consume those semantics through natural language. Governance determines which data can be accessed. Tools such as MCP increasingly provide a controlled route for agents to interact with enterprise systems.
Viewed together, they point towards a broader requirement:
A data platform built for agents must not only serve data. It must explain what that data means and govern how machines are allowed to use it.
A wrong answer and a wrong action are not the same problem
This becomes more important as agents move beyond answering questions.
If an analyst sees an unusual revenue figure on a dashboard, there are several opportunities to catch the problem.
They may recognise that it looks wrong. They may compare it with another report. They may ask Finance.
Now imagine an agent interprets the wrong revenue measure and uses it to update a forecast, prioritise an account or trigger another workflow.
The cost of ambiguity changes.
Data → Human interpretation → Decision
starts becoming:
Data → AI Agent interpretation → AI Agent reasoning → Action
At that point, semantics and governance are no longer simply data-management concerns. They become part of the organisation's operational control system.
AI readiness starts before the model
It is easy to focus enterprise AI discussions on models, agents and orchestration. But an organisation can have excellent pipelines, Delta tables, strong models and sophisticated agent tooling while still leaving critical business meaning buried in people’s heads.
That is the gap agents expose.
Before asking which model to use, there is a more fundamental question:
How much understanding does our data platform currently expect a human to provide?
A practical way to answer it is to take one high-stakes question the business asks all the time — “which region performed best,” “is this account at risk,” “are we on plan” — and trace how it actually gets answered today. Every point where someone silently applies a definition, chooses the authoritative source, or knows which number to trust is a piece of context the agent does not have.
From there, the work is concrete:
None of this requires a more capable model. It requires deciding, once and explicitly, what your data already means.
Want to chat to use more about this, or hear how we've implemented solutions that fill this gap? Get in touch.
