6 min read AI Infrastructure

Your agents are ready, but your data platform is not

Your agents are ready, but your data platform is not

Google Cloud published a post on 23 July 2026 whose title frames the question correctly: your AI agents are ready, is your data? It draws on a survey of 1,402 global IT leaders, whose most quoted finding is that 83% of organisations believe they need infrastructure upgrades to support production-grade agentic AI systems. Two other figures from the same report are more instructive: 43% of respondents name difficulty integrating with legacy APIs and data sources as their biggest gap, and 81% cite operational complexity and engineering overhead among the unforeseen expenses of scaling.

The instinctive reading of a figure like that is budgetary: buy more capacity. Independent academic data suggests that is almost never the problem. On Spider, the long-standing evaluation set for generating SQL from natural language, frontier models reach around 91% accuracy. On Spider 2.0, which uses realistic enterprise schemas rather than textbook databases, the same models fall to between 17% and 21%. No amount of additional memory closes a seventy-point gap obtained with the same models, the same SQL competence, and only the nature of the data changed. What those numbers describe is not a shortage of power, it is a shortage of meaning.

The 2 August article on what event logs reveal set out a process prerequisite before deploying agents. What follows sets out the platform prerequisite, which plays out on two distinct and frequently conflated levels: the load an agent imposes on your systems, and the meaning those systems are able to hand back.

Tree structure starting from a single point and widening into dozens of branches towards several systems.
A single user request propagates into hundreds of round trips across several systems.

An agent is not a chatbot, and the difference is measurable

Google Cloud's description of the load profile is accurate and worth keeping: a single prompt can trigger an agent to independently browse, query and execute across multiple systems. A conversational assistant produces one call and one response. An agent produces a tree.

The order of magnitude, though, does not come from vendors. A benchmark published on arXiv in July 2026 on long terminal tasks measures, across fifteen frontier models, an average of 9.9 million tokens per task, roughly 231 episodes and 85.3 minutes of execution per run. Those values come from a development context rather than a data warehouse, and do not transfer directly. But they give the amplification factor nobody sizes for: between the request a user formulates and the work actually demanded of the underlying systems, there are two orders of magnitude.

Three consequences follow, and none is solved by raw capacity. The first is concurrency: a hundred users asking a question do not produce a hundred queries, they produce thousands of simultaneous calls that hit your internal API rate limits long before saturating your warehouse. The second is compounded latency: a step at 400 milliseconds is excellent for a dashboard and disqualifying after two hundred iterations. The third is write access, which read-only architectures never had to handle and which becomes central as soon as the agent has to act rather than answer.

The real gap is semantic

Return to the seventy-point gap. What changes between the two evaluation sets is numerous tables with similar names, columns whose labels do not convey their business meaning, joins that assume an internal convention, and deprecated tables that nothing flags as such. In other words, your warehouse exactly.

Analyses of these errors converge on one point: the large majority of query generation failures come not from faulty syntax but from a mistaken understanding of the schema or the meaning of the data, that is, from a guess about what a column represents or what a join means. An agent writing perfectly valid SQL against the wrong table produces a wrong number, presented confidently, with no error signal anywhere in the chain.

The technical answer now emerging is the semantic layer, an intermediate level exposing defined entities and metrics rather than raw tables. Published measurements on this are encouraging and warrant a double caveat. A 2026 benchmark from dbt Labs reports, on board-level or audit-grade questions, a move from 90.0% to 98.2% accuracy for one model and from 84.1% to 100% for another, when substituting semantic-layer access for direct SQL generation. Academic work published on arXiv in June 2026 describes a semantic-layer-mediated agent with deterministic SQL compilation reaching 94.15% execution accuracy across the 547 tasks of a benchmark derived from Spider 2.0. The first measurement comes from a vendor selling a semantic layer, which does not invalidate the result but means it should not be cited alone; the second, independent, points the same way on a narrower scope.

The actionable point for a decision maker is not the exact percentage, it is structural: the same architecture that makes an agent reliable is the one that makes meaning explicit, and that architecture already existed as data governance good practice long before agents. The pattern recurring in the field is that teams who invested in a catalogue and shared metric definitions get immediately better results without changing anything about the model. Teams who did not read the same gap as a model shortcoming and switch vendors, to no effect.

List of the six tests to pass before scaling, only one of which concerns hardware capacity.
Six tests to pass before scaling, only one of which is about capacity.

Six tests before scaling

The practical consequence is a test protocol, to be run before opening to users rather than after the first incident.

Capacity, measured against the real profile rather than an average volume. Replay a day of expected traffic honouring the amplification factor, not the number of user requests.

Compounded latency. Time a complete task end to end, not the response time of a single query. It is the only number that decides whether the use case gets adopted.

Concurrency, and in particular the rate limits on your own internal APIs. They are almost always the first wall hit, and they appear in no capacity plan because nobody treats them as infrastructure.

Data freshness. An agent acting on a state that is six hours old produces correct decisions about a world that no longer exists. Write down, per use case, the maximum acceptable lag, and verify it.

The semantic layer. Take twenty real business questions and compare the accuracy obtained through direct schema access against access through definitions. The gap measured at your company beats any published benchmark.

Write access, finally, with the same rigour set out in the 13 July article on access control for agents: explicit scope, reversibility, and logging distinct from that of the user who made the request.

What to put in motion this week

Measure your amplification factor on an existing use case. Instrument one agentic task end to end and count the calls actually issued per user request. That single number changes all your sizing, and nobody on the team knows it today.

Take twenty frequent business questions and have an agent answer them with direct schema access. Count the correct answers. That is your baseline, and it will probably sit closer to twenty percent than to ninety.

Document the ten most queried tables first, with the business meaning of every ambiguous column and explicit marking of deprecated tables. It is the highest effect-to-effort intervention on this whole list.

Pull the rate limits on your internal APIs and set them against the amplification factor measured in the first point. The comparison will tell you whether your scaling problem is a budget question or a redesign question.

Finally, write down the maximum acceptable lag per use case, in minutes, and have the business validate it rather than the data team. It is a risk exposure decision, not a technical one.

Conclusion

The report opening this article should be read for what it is, a survey published by a vendor selling precisely the platform its conclusions call for, and its figures deserve that caution. What survives the caveat is solid, because the independent data points the same way while sharpening it: the upgrade most organisations need is not a question of machines, it is a question of definitions. An agent does not compensate for ambiguity in your data, it amplifies it and presents it with confidence, which is the worst possible combination for a decision.

Sources: As of July 2026

Godwin AVODAGBE