Agents Need a Ground Truth: Your Data Foundation Is Your AI Ceiling

A customer asked me last year to help them work out why their agent kept getting inventory availability wrong.

It was a reasonable question, asked in good faith, and it had nothing to do with the agent. We traced it for about two hours. The agent was retrieving availability from a reporting layer that had been built in 2014 to support a weekly planning meeting. It aggregated to plant level, it excluded consignment stock by a business rule somebody had encoded in a transformation nobody had opened in six years, and it landed nightly. Every one of those choices was correct for a weekly planning meeting. Every one of them was wrong for an agent being asked, in the moment, whether a specific thing could ship on Thursday.

The agent was not hallucinating. It was faithfully reporting a version of reality that the business had deliberately constructed, for a purpose that no longer applied.

I think about that engagement a lot, because it is the clearest example I have of the thing that actually limits enterprise AI. It is not the model. It is what the model is allowed to know, how current that is, who decided what it means, and whether anyone can still explain the decision.

Fluent failure is the dangerous kind

Classic reporting failed loudly. If a query broke, you got an error, a blank cell, a number so absurd that a controller caught it before the meeting. The system’s incompetence was legible.

Agents do not fail that way. Give an agent a stale or subtly wrong retrieval and it will produce a confident, well-structured, entirely plausible answer, complete with reasoning that sounds like diligence. Then somebody forwards it. This is the specific reason I have become much stricter about foundations over the last three years than I was about warehouses for the previous fifteen: the cost of being quietly wrong has gone up, because being quietly wrong now scales and reads well.

So when a customer tells me they want to scale agentic use cases across finance and supply chain, the first question I ask is not about use cases. It is: what would this agent ground on, and who owns the definition?

If the answer is a list of systems, we have work to do. If the answer is a person’s name, we are in much better shape than most.

What “ground truth” actually requires

Grounding is a word that has quietly expanded to mean “we connected it to some data.” The version that holds up in an enterprise landscape needs four properties, and I would rather have all four on a narrow slice of data than two of them across everything.

It has to be current enough for the decision being made. Not current in the abstract — current relative to the question. A nightly batch is fine for an agent summarizing last quarter’s spend variance. It is useless for one committing to a delivery date. Latency is not a technical preference, it is part of the use-case definition, and it should be written down next to the use case rather than discovered afterwards.

It has to carry a definition, not just a value. This is where most estates are weakest. “Available inventory” meant something specific to whoever built that 2014 layer. If the agent inherits the number without the definition, nobody can audit its answer, because there is nothing to audit it against. A semantic layer is not documentation overhead. It is the thing that makes an agent’s output contestable, and output you cannot contest is output you cannot govern.

It has to have lineage you can walk backwards. The first serious question after an agent gets something wrong is always “where did it get that?” If answering takes two hours and a tribal-knowledge phone call, the organization will lose confidence in the agent faster than you can fix the underlying issue. Traceability is what buys you the second chance.

Somebody has to own it, by name, with time in their week. Not a team. Not a centre of excellence in a slide. A person who is accountable for whether “available inventory” still means what it says, and who is expected to notice when a source system changes underneath it.

Which is why the unglamorous work is the work

This is the part customers find least satisfying, and I have stopped softening it.

If your integration still runs through a PI landscape that three people understand and two of them have left, you do not have an agentic AI programme. You have an agentic AI ambition sitting on top of a single point of failure. If your reporting estate is a BW instance that has accumulated fifteen years of undocumented transformations, then every agent you attach to it inherits fifteen years of decisions nobody can defend.

Moving PI onto BTP Integration Suite, moving BW onto Datasphere, establishing a grounding layer through Business Data Cloud — none of that appears in a board deck as an AI initiative. It should. It is the part that determines whether anything above it works, and the customers who did it before 2024 for unrelated reasons are the ones moving fastest on AI now. They did not plan it that way. They just happened to have a foundation when the capability arrived.

The reframing I use with executives is simple: your data foundation is not a prerequisite to your AI roadmap, it is a ceiling on it. You can spend as much as you like above the ceiling. You cannot get through it.

The counter-argument, which is partly right

Here is where I have to be honest, because the position I have just laid out has a well-known failure mode and I have walked into it.

Taken to its conclusion, “fix the foundation first” becomes a permanent reason to do nothing. Data estates are never finished. There is always another undocumented transformation, another source system with an owner who left, another definition two departments disagree about. A leader who insists on a clean foundation before the first agent ships will never ship an agent, and will lose the organizational momentum that was the actual scarce resource.

I have watched exactly this happen. A programme I was close to spent nearly three quarters on a data-quality remediation track that was genuinely necessary and genuinely well run. By the time it was ready, the executive sponsor had moved on, the budget had been re-cut, and the use cases the programme existed to enable were being done — badly, in a browser tab, on exported spreadsheets — by the business teams who had stopped waiting.

That last part is the real risk. If the governed path is too slow, people do not stop using AI. They use it somewhere you cannot see, on data you did not sanction, with no lineage at all. Perfectionism about foundations produces the exact ungoverned outcome it was trying to prevent.

So the honest position is narrower than “foundation first.” It is: pick the slice of the foundation that your first two use cases actually need, make that slice genuinely excellent, and ship on it. Narrow and trustworthy beats broad and approximate, and it gives you something real to point at in the next funding conversation. Then widen the slice with each use case, which is also how you find out which parts of the estate matter and which parts everybody has been maintaining out of habit.

What I would tell a customer starting now

Do not start with a data strategy. Start with one decision your business makes badly and often, work backwards to exactly what an agent would need to know to make it well, and get that specific path clean — current, defined, traceable, owned.

You will discover, reliably, that the path is shorter than the strategy would have implied and messier than the architecture diagram suggested. You will also have something in production, grounded on data someone will defend, within a quarter rather than a year.

Then do it again. After four or five, you will notice you have been building the foundation the whole time, in the order the business actually needed it — which is a better order than any of us would have designed up front.