Agentic AI does not fail on the model. It fails on the join.
Months of building an emissions benchmark on public registers, and the model was never the bottleneck. Identity was. Coverage was. Lineage was. What a data foundation has to do before an agent's answers mean anything.
The interesting failures in agentic AI are not model failures. They are join failures. An agent that cannot establish which company a row belongs to will still answer your question, fluently, and you will have no way to tell that it is wrong.
This is not a warning from the sidelines. I spent months building an emissions-intensity benchmark out of public registers, on my own account, and the model was never the bottleneck. Identity was. Coverage was. Lineage was.
So here is the sentence this piece has to defend: a data foundation is not the phase you finish before the agents arrive. It is the thing that decides whether their answers mean anything.
Volume is not value
Row counts are the vanity metric of data platforms. They measure ingestion, not usable ground truth.
My pipeline holds 4,838,763 verified emission rows. From that, the number of companies with a defensible emissions intensity was two orders of magnitude smaller: a hand-built cohort of 1,289 companies produced 61 measured company-years in the final benchmark table. Four point eight million rows in. Sixty-one honest answers out.
An agent makes this gap worse, not better. Ask it “what is this company’s emissions intensity” and it will happily reason over the 4.8 million rows and produce a number. Nothing in the ingestion count tells the agent, or you, that the number rests on nothing.
To be fair to the rows: they are not waste. They are the raw material that made the 61 possible. The mistake is quoting the input as if it were the output.
Entity resolution is the product, not the plumbing
In any cross-source data foundation, the entity spine (knowing which rows belong to which company) is the highest-value asset you will build. It is also the one nobody budgets for.
The facility-to-company join in my build went from 38.7 percent to 87.6 percent coverage across eight country adapters. Every point of that came from adapter work on registration-name formats. None of it came from model work.
The thing that actually worked was a hand-built crosswalk: 1,289 companies mapped by a human, with 92.9 percent name-match agreement, and that file became the source of record. The automated matcher, cleverer on paper, produced a small fraction of that.
Two country bridges died on contact with reality. Poland, because only one register namespace was ever loaded, so there was nothing to bridge to. Australia, because the identifier my matcher needed does not exist anywhere in that data. No amount of matching sophistication survives a missing key.
Hand mapping is gold. Name matching is a guess with good manners.
The trade-off, named: hand mapping does not scale, and saying so is not a defence of it. It scales exactly as far as one motivated human and then stops. The defensible position is narrower. A hand-built spine for the cohort you actually sell into beats a fuzzy spine for a universe you cannot verify. That is a scoping decision, not a technical victory.
And it is precisely the layer an agent cannot bluff. An agent can generate plausible company names all day. It cannot invent a key that two sources agree on.
Lineage is what makes an answer checkable
Accuracy is a claim. Lineage is a receipt. For agentic systems the receipt matters more, because the agent’s fluency removes every other signal you had for detecting nonsense.
The benchmark’s read API has a lineage endpoint that recomputes each CO2-equivalent figure from the underlying source rows and asserts that the recomputation matches the stored value. On the demo entity it returns matches_stored: true. Every figure carries a confidence tier: measured or estimated.
One story proves the point. A read-only correctness pass found that two register categories, total carbon dioxide and carbon dioxide excluding biomass, were both being summed for the same physical facility. 88 company-years were overstated. The fix dropped 102 facility-year rows.
Now the part that is the actual reason to tell the story: fixing the bug did not improve the estimator at all. The leave-one-out error stayed essentially where it was. The bug was real and worth fixing, and it was not the cause of the weakness. Lineage is what let both of those statements be true at once, and provable. Without it, the fix would have been a nice story about a bug found, and the real weakness would have kept hiding behind it.
The trade-off here is compute and constraint. Recomputing on read costs cycles and it limits how you can model. Doing it for a benchmark of 61 company-years is easy. Doing it at platform scale is a real engineering bill, and anyone claiming otherwise has not sent the invoice yet.
Know your ceiling, and say the number out loud
The most useful output of a data foundation is often a hard boundary, not a bigger number. Most teams never compute their ceiling, so they cannot tell the difference between “we need more engineering” and “the data does not exist”.
I ran a diagnostic that asked how many additional company-years could ever join the measured tier, given the loaded sources. The answer was zero. 61 was not a milestone on the way to more, it was the complete structural ceiling for that cohort. Of the 1,289 companies, 1,242 were absent from the measured tier, and most of them were absent because they had no emissions, no revenue and no facility code in the system at all. That is not a wiring gap a sprint can close. The data does not exist.
The decision that followed was the expensive one. The estimated tier, measured honestly, came out weak: a median absolute error of 123.5 percent, with 10.7 percent of estimates landing within a 50 percent band. Restricting to thicker peer groups improved that to 88.9 and 14.8 percent, which is still weak. So the estimated tier was dropped from what buyers see, and the pitch now leads with 61 measured company-years and the lineage behind them.
That decision shrank the sellable surface of the product. It is a smaller claim, and it is the only claim that survives a competent question.
An agent has no instinct for the edge of its own evidence. Ceilings and confidence tiers are how you give it one, and they only exist if a human computed them first.
What this means for agentic AI
An agent inherits your data foundation’s honesty. It cannot add any. Without an entity spine, its output is fluent and unattributable. Without lineage, its output is unfalsifiable, which is worse than wrong, because wrong is detectable. Without a stated ceiling, it will answer confidently past the edge of the evidence, because nothing in the data ever told it there was an edge.
The practical version, if you run a team: the useful question before an agent pilot is not which model. It is “can we produce, for one representative answer, the chain of rows that supports it”. If the answer is no, the pilot will succeed on the demo and fail on the audit.
And the ordering claim, since it is the whole title. This is not “build the perfect warehouse first, then do AI”. That is the old, slow answer, and it is how data programmes die. The claim is narrower and harder: build the spine and the lineage for the narrow slice you are actually going to answer questions about, then put an agent on that slice.
A note on method, and where it is weak. The coverage and error figures above come from the build’s own verification runs on public register data, and the error measurement is leave-one-out validation over the same 61 measured company-years. That is a thin base for error statistics, which is one more reason the estimated tier stays out of the pitch. This is also one benchmark, in one domain, built by one person. Treat the numbers as a worked example, not a law.
The benchmark ended up smaller than it started, and that is the part worth publishing. 4.8 million rows produced 61 defensible company-years, each of which can be recomputed from its source rows in front of a sceptic. A model can be swapped in an afternoon. The spine took months, and it is the only reason any answer built on top of it means anything.
Written with AI as a tool: research, structure and drafting with Claude; the judgment and every claim are mine.