Why AI Agents Need Business Context, Not Just Data Access
An agent can query your warehouse in seconds, but a query is not an answer. Without a model of what drives each metric, who owns it and whether the last action worked, an agent produces confident output that nobody can trust. This guide explains the missing layer and how to expose it.
11 min read
Data access is not business context
Definition
Business context is the structured meaning an AI agent needs to reason about a metric: what the metric is, what causes it to move, who is accountable for it, and whether past actions changed it. Data access alone gives an agent the ability to read numbers. Business context gives it the ability to understand them.
Give an AI agent a connection to your warehouse and a semantic layer and it will answer questions quickly. Ask it why revenue fell last month and it will write SQL, run it, and hand back a number with a tidy explanation. The speed is genuine. The problem is that speed and correctness are not the same thing.
A semantic layer tells the agent how a metric is calculated. It standardises the definition of revenue, churn or activation so that two queries return the same figure. That is necessary and valuable. But it stops there. It does not tell the agent what drives revenue, which inputs to inspect when revenue moves, who is accountable for the result, or whether the last fix actually worked. The agent has the recipe for the metric but no map of the business around it.
So the agent does what it has always done. It correlates. It finds something in the data that moved at roughly the same time as the metric, narrates a plausible story, and presents it with the fluency that makes large language models so persuasive. Sometimes it is right. Often it is right for the wrong reason. And there is no way for the reader to tell the difference, because the agent has no model of cause to check itself against.
Why agents without a causal model are fast but wrong
A language model is a correlation engine by construction. It is very good at finding patterns and very bad at knowing which patterns mean anything. When you point it at a warehouse and ask why a number changed, it has no way to distinguish a driver from a coincidence unless you give it one.
- 1
It mistakes correlation for cause
Two columns that moved together last month are not a cause and an effect. Without a causal structure, the agent cannot tell which is which, so it guesses, and it guesses confidently.
- 2
It searches a flat space
A warehouse is thousands of tables and columns with no priority. The agent has nothing that says start here, then look below. It explores at random and stops when it finds something quotable.
- 3
It cannot trace a number to its inputs
Asking why a metric moved is a tracing problem. You walk down from the outcome to the input that caused it. With no tree to walk, the agent cannot trace, so it narrates instead.
- 4
It has no one to hand the answer to
Even a correct diagnosis is inert if it lands nowhere. Without knowing who is accountable, the agent produces a finding that no person is responsible for acting on.
- 5
It never learns whether it was right
With no record of past actions and their results, every analysis starts from zero. The agent cannot say we tried this before and it did not work, because nothing told it.
The core problem
An agent grounded only in data access optimises for a fluent answer, because that is all it can produce. An agent grounded in a causal model can optimise for a correct one, because it has a structure to be correct against.
What a semantic layer gives, and what it leaves out
It is worth being precise about the boundary. A semantic layer is not wrong and it is not optional. It is the foundation. But it answers a narrow question, and the questions an agent needs to act are wider. The difference is the difference between knowing how a metric is computed and understanding what it means.
| Question the agent asks | Semantic layer | Metric tree |
|---|---|---|
| How is this metric calculated? | Yes, this is its core job | Inherits the definition |
| What drives this metric up or down? | No | Yes, through causal links |
| Which input do I inspect when it moves? | No | Yes, by walking the tree |
| Who is accountable for the result? | No | Yes, through RACI on the metric |
| Did the last action actually work? | No | Yes, through the verified impact loop |
| Is this driver a cause or a coincidence? | No | Yes, links are causal by design |
Read down the right-hand column and a pattern appears. The semantic layer hands the agent a clean number. Everything that turns a number into a decision lives somewhere else. A metric tree is where it lives. It is the layer of meaning that sits above the layer of calculation, and it is precisely the layer that most agent deployments skip.
Why this matters now
Connecting an agent to a warehouse is the easy part and most teams have done it. The advantage no longer comes from access. It comes from the structure you give the agent to reason over once it is connected.
The metric tree is the context an agent can reason over
A metric tree places a headline metric at the top and decomposes it into the drivers, sub-drivers and inputs that cause it to move. Each link is a causal claim, not a correlation. That single property changes what an agent can do, because it converts a flat search into a directed walk. The agent no longer asks what in this warehouse moved. It asks which branch of this tree moved, then which branch below that, until it reaches an input it can name.
Ask an agent why net revenue retention fell against this tree and the work is bounded. It checks expansion, contraction and churn, finds that churn rose, walks down to activation rate, and confirms that activation dropped for accounts onboarded last quarter. That is a traceable answer. Every step is a causal link the agent can name and a person can check. Compare that to the same agent on a bare warehouse, free to correlate the fall with anything that happened to move.
The point is not that the tree makes the agent smarter. It is that the tree gives the agent something true to be smart about. Structure is what turns generative fluency into grounded reasoning. This is the same shift covered in why did my metric change: the question is answerable only when the causal structure exists to answer it.
Ownership and the verified impact loop
A correct diagnosis that lands nowhere is wasted. This is where two further pieces of context matter, and neither lives in a warehouse or a semantic layer. The first is ownership. The second is a record of what happened after the last action.
RACI on every metric
Each metric carries its Responsible, Accountable, Consulted and Informed roles. When the agent reaches a driver, it knows who owns it, so the finding goes to a named person rather than into a report nobody reads.
Push to the accountable owner
When a metric moves, the accountable owner is notified directly. The agent does not wait to be asked. The right person learns that activation has dropped before the next review, not during it.
Verified impact loop
After an action is taken, the loop checks whether the metric actually moved as expected. The agent gains a memory of what worked and what did not, so the next analysis is not starting from zero.
A reasoning trail
Tree plus ownership plus impact history gives the agent a path it can show its working on. Each conclusion ties back to a causal link, a named owner and a prior result.
The verified impact loop is the piece most agent systems lack entirely, and it is the piece that compounds. An agent that never learns whether its advice worked is condemned to repeat it. An agent that can see that reworking onboarding last quarter lifted activation, and that the lift held, reasons from evidence rather than from prose. This is the difference between metric ownership as an organisational chart and ownership as something an agent can act through.
“People change their behaviour when they can see the system, not when they are shown another dashboard. The same is true of an agent. Give it the system and it reasons. Give it a dashboard and it narrates.”
Exposing metrics, drivers and RACI through MCP
Structure that lives only in a dashboard is invisible to an agent. To reason over the metric tree, the agent has to be able to read it through an interface it understands. The Model Context Protocol, or MCP, is that interface. It is the standard way an agent connects to a source of structured context and queries it like a tool.
Exposing the tree through MCP means the agent does not ask the warehouse for raw tables. It asks the metric tree for the drivers of a metric, the RACI roles on each one, and the history of actions and their verified results. The agent receives meaning, not just rows. Each of these is a structured call with a structured answer, which is exactly what an agent needs to plan rather than guess.
- 1
Read the metric and its definition
The agent asks for the metric, inherits the calculation from the semantic layer, and knows it is reading the same figure every other tool reads.
- 2
Walk the drivers
The agent requests the causal children of the metric and recurses down, turning the open question of why into a bounded walk of named drivers.
- 3
Read the RACI on each driver
For any driver the agent reaches, it can read who is accountable, so a conclusion is attached to a person the moment it is formed.
- 4
Check the impact history
Before recommending an action, the agent reads what was tried before on this driver and whether the verified impact loop confirmed it worked.
The grounding, stated plainly
MCP does not make the agent more capable. It gives the agent something true to be capable about: a metric tree of causal drivers, RACI ownership, and a record of verified impact, all queryable as structured context. That is grounding, not magic.
There is more on the protocol itself in MCP servers for business performance, and more on the broader shift in agentic analytics. The thread through both is the same as the thread through this guide. The interface matters because of what it carries, and what it should carry is meaning.
What grounding does and does not promise
It is worth saying clearly what this is not. Grounding an agent in a metric tree does not make it omniscient and it does not remove the need for judgement. A causal model is a set of claims your team made about how the business works, and those claims can be wrong or incomplete. The agent reasons over the model it is given. If the model misses a driver, the agent will miss it too.
| Claim | What is true | What is not |
|---|---|---|
| The agent reasons causally | It walks links your team marked as causal | It does not discover new causes on its own |
| The agent is accountable to an owner | Findings route to the RACI owner of the driver | It does not replace the owner deciding what to do |
| The agent learns from impact | It reads verified results of past actions | It does not guarantee the next action will work |
| The agent is grounded | It reasons over structured business meaning | It is not more correct than the tree it reads |
The honest framing is modest and it is also the strong one. An agent grounded in a causal model, real ownership and a memory of what worked is far more useful than an agent let loose on a warehouse, precisely because it is constrained by something true. The constraint is the value. This is the same principle that sits underneath decision intelligence: the goal is not a faster answer but a better decision, and a better decision needs structure to rest on.
Where this is going
The first wave of agent deployment was about access. Connect the agent to the warehouse, wire up a semantic layer, and let it answer questions. That wave is largely done, and it has revealed its own ceiling. Access makes agents fast. It does not make them trustworthy, because a fast answer over an unstructured world is still a guess.
The next wave is about context. The teams that get value from agents will be the ones that gave them a model to reason over: a metric tree of causal drivers, ownership on every metric, a loop that verifies whether actions worked, and an interface like MCP that exposes all of it as structured context. The agent stops narrating and starts tracing. It stops correlating and starts reasoning. And the answers stop being plausible and start being checkable.
The shift in one line
Stop asking your agent to be clever about an unstructured warehouse. Give it a structured model of the business and let it be correct about that instead.
This is the layer KPI Tree builds: the metric tree, the RACI ownership, the verified impact loop, and the MCP interface that makes all three legible to an agent. Not as a feature bolted on, but as the substance an agent needs to act on business meaning rather than on raw rows. The dashboard told you a number changed. The structured model tells your agent why, who owns it, and whether the fix worked.
Continue reading
Agentic analytics
AI agents can query your data. They cannot understand your business.
MCP servers for business performance
From raw data access to actionable understanding
Why did my metric change
Stop guessing. Start tracing.
Decision intelligence
The problem was never a lack of data. It was a lack of structure around decisions.
Give your agents a model, not just a connection
KPI Tree turns your metrics into a causal tree with RACI ownership and a verified impact loop, then exposes all of it through MCP so your agents reason over business meaning instead of raw rows. Build the context layer your agents have been missing.
