Build a reliable data foundation for agentic AI with proven strategies for governance, semantics, and production-ready AI agents.
Your agents work in the pilot. They stall in production.
The demo ran on three clean tables, with a helpful engineer sitting next to it. Production has dozens of source systems, two definitions of revenue, and nobody to ask. A data foundation for agentic AI is what closes that gap. It is not the same work as making data ready for a model or a dashboard. Teams keep treating it as though it were.
This piece names the five capabilities an agent needs, the five ways agents fail without them, and a five-phase roadmap with real durations. It also covers what drives the cost, what changes in banking, healthcare and manufacturing, and the three cases where you should skip this work.
A data foundation for agentic AI is what lets an autonomous agent find, interpret and act on enterprise data with no human in the loop. It needs five capabilities: traversable discovery, machine-readable semantics, permissions scoped per request, freshness set per decision, and an audit record of every agent action.
Note what is missing from that list. Pipelines, data quality, warehouse design and general governance are all missing, because they are the prerequisite, not the job. If that layer is still shaky, start with our earlier guide to AI-ready data infrastructure and come back.
The category has no agreed name yet. Practitioners on the r/KnowledgeGraph thread give roughly the same thing four names: intelligence layer, context layer, memory layer, semantic layer. That is a real problem when you are scoping work. So this piece sticks to the five capability names above.
Your decision is narrow. Which two of the five do you fix first, and which do you defer for a quarter?
A reporting platform assumes a person reads the output and catches the odd result. An agent removes that reader. Five assumptions break at once.
A human analyst asks a colleague which table is the real one. An agent cannot do that. So catalogue coverage stops being documentation hygiene and becomes a hard dependency.
That needs two things. First, table and column descriptions have to live in the catalogue itself, not a wiki page. Second, each business entity needs one marked authoritative dataset. Machine-readable beats well-written here.
Partial coverage is the trap. An agent quietly prefers what it can see, so a half-catalogued estate steers it toward whichever staging table happens to be documented.
An agent calling the warehouse sees columns. It does not see meaning. A semantic layer for AI agents holds metric definitions, join logic and business rules in a form the agent can read and cite.
Definitions that live inside a BI tool are invisible to an agent querying the tables directly. That is the single most common miss we find. The logic exists, it is just in the wrong place.
Here is how trust dies. Two teams hold two definitions of active customer. Two agents answer the same question. Both answers are defensible. Nobody believes either one again.
The shift is from a static role grant to a decision made per request. Reporting stacks rarely need that. Agents do.
Three things change. The agent needs its own identity, separate from the person it acts for. Its scope has to be narrow enough that a crafted prompt cannot widen it. And its write paths need governing rather than bypassing.
Writes are the real break point. An agent updating a record is running a transaction, so give it the controls a transaction gets. Data governance for AI agents is mostly this, plus the log in the next section.
Reporting tolerates a nightly window, because a person reads the dashboard next morning. An agent acting inside a workflow does not have that luxury.
Set a freshness budget per decision instead of a blanket real-time target. Real-time everywhere is the most expensive error here. Most decisions do not need it.
One insurance platform shows the shape of the problem. A 45TB Oracle estate supporting 1.2 million active policies ran 14-hour ETL windows. Underwriters worked on old data and could not react to intra-day loss events. Micro-batching for claims telemetry cut data latency from 24 hours to under 30 minutes, and query performance for multi-year actuarial analysis improved 70 percent.
Lineage of what the agent read is table stakes by now. The record of what it changed is not, and that is the gap.
The artifact is a per-action log: which agent, acting for whom, read or wrote what, under which policy, at what time. Query logs do not cover this. They tell you a statement ran, not who authorised it or why.
Use this test. Pick one agent action from six weeks ago and reconstruct it end to end. If you cannot, do not let that agent write yet.
The argument is live right now. In the seven days to 29 July 2026, four people who build this layer for a living made the same point in public.
Andi Gutmans of Google Cloud argued that a trustworthy data foundation comes before autonomous agents. For banks, he added, legacy architecture rather than regulation is what stops agents reaching production. Cassie Kozyrkov was blunter: nobody expects good advice from an advisor given no context, yet teams expect it from models. Ali Ghodsi of Databricks pointed at conversational access to business data as the thing people actually use. Werner Vogels of AWS pointed engineers at the Registry of Open Data, which agents can be aimed at directly.
Those are four opinions, so treat them as opinions. The number underneath is McKinsey's. Nearly two thirds of enterprises have tried agents. Under 10 percent ever reached real value at scale, and eight in ten blame limits in their data.
Agents fail on production data in five named ways, one per capability. Every page currently ranking for this topic describes those failures in adjectives instead: agents fly blind, results could be inconsistent, consequences could be severe. None of that helps you triage a stalled pilot.
The table below does. Score your platform row by row, then carry the two weakest rows into the roadmap in the next section. No product is named anywhere in it, and the test column works on any stack.
Two rows scoring badly is normal. Five means the pilot was never the problem.
Run these five phases in order. An agent ready data architecture gets built in this sequence, and the sequence is where most programmes go wrong.
Phase 1. Scope one workflow. Two to three weeks.
Phase 2. Catalogue and semantics, for that workflow only. Four to eight weeks.
Phase 3. Permissions and audit, before any write goes live. Four to six weeks.
Phase 4. Freshness, tuned per decision. Three to six weeks.
Phase 5. Widen to the second workflow on the same foundation. Ongoing.
Phase 3 sits before phase 4 on purpose, and teams push back on that constantly. Fast data feels like the bigger win. It is not. A quick wrong write costs more to unwind than a slow right one costs to wait for.
Phasing also contains the delivery risk. One global enterprise unified data across several ERP and point-of-sale systems onto a curated data lake with Redshift, EMR and Athena. It shipped as a three-phase data engineering rollout, not one cutover. Query time fell 50 percent, minutes down to milliseconds.
Nobody can price data readiness for AI agents from the outside, and any article that quotes a figure is guessing. You can price the drivers instead.
Five things move the number, roughly in this order of impact:
Two spends are worth deferring. Estate-wide catalogue coverage is one: catalogue the workflow, not the warehouse. Real-time streaming is the other, for any decision that tolerates an hour.
Phasing pays because the second workflow reuses the first one's foundation. ZS reports a difference here. Treating readiness as a platform investment, rather than a per-use-case build, reduced the cost of each added use case by as much as 40 to 45 percent in year one. That is ZS's own figure from its life sciences practice, not an independent benchmark, so weigh it accordingly.
The five capabilities hold everywhere. Which one binds first does not.
Banking, financial services and insurance. Freshness binds first, because the decision window is intra-day. An agent assessing exposure on stale positions is worse than no agent.
Auditability binds second. Supervisory review asks what the system did and why, so the per-action log has to survive a long look-back. Regulatory scope depends on your own assessment with your own counsel, and nothing here changes that.
Healthcare. Permissions bind first, and the reason is structural. Access to patient data is often scoped per encounter and per care relationship, not per job title. That is exactly the per-request model agents need, and most platforms lack it.
Semantics come next, because clinical coding varies between systems that are meant to agree. Again, scope is yours to assess.
Manufacturing. Semantics bind first and hardest. The same part number means different things in the MES, the ERP and a supplier feed, and reconciling that is most of the work. Discovery is usually easier here, because plant systems are fewer and better bounded. Freshness matters on the line and rarely anywhere else.
Three conditions where this work is the wrong call.
You have fewer than about three source systems and one agreed set of definitions. The five capabilities are overhead at that size. You would be building governance for a problem you do not have. Better: point the agent at the warehouse, put your metric logic in a version-controlled file, and revisit in two quarters.
Your agents only draft, and a person approves everything before it happens. Per-request scoping and per-action audit are premature, because the approver is the control. Better: spend the whole budget on discovery and semantics, which is where drafting quality actually comes from.
A platform migration is already in flight. Building agent readiness on infrastructure you are replacing means paying for it twice, and the second bill is larger. Better: finish the migration and write the five capabilities into the target design as requirements.
One thing we would advise a client against: do not buy an enterprise catalogue licence before one agent workflow runs in production. The workflow tells you which metadata matters. The licence does not, and you will populate the wrong half of it.
For some readers the honest answer this quarter is to fix definitions in a shared file and spend nothing else. That is a real option, and it is sometimes the right one.
If your agents work in a pilot and stall in production, the constraint is usually one of the five capabilities above. Usually not the one the team expects.
Entrans runs a 20-minute consult with our data and cloud architects. We score your platform against the five rows in the table above, then hand back the two phases to run first. On one insurance data platform, that work cut claims data latency from 24 hours to under 30 minutes. Book it through cloud and data engineering.
A data foundation for agentic AI is what lets an autonomous agent find, interpret and act on enterprise data without a human in the loop. Five capabilities make it up: traversable discovery, machine-readable semantics, permissions scoped per request, freshness set per decision, and an audit record of every agent action.
AI-ready data is about quality, coverage and governed pipelines, and a model or a dashboard can consume it. An agent adds four demands. It must discover data unaided, know what each field means, act inside per-request permissions, and leave an audit trail. The pipeline work is a prerequisite, not the same job.
An agent calling a warehouse directly sees columns, not meaning. A semantic layer holds metric definitions, join logic and business rules in machine-readable form. The agent then computes active customer the way the business defines it. Without one, two agents produce two defensible answers to a single question and trust collapses.
Agents complete tasks across several systems, so data has to be usable outside the tool that created it. Open table formats and documented interfaces let one agent read the warehouse, the operational store and the document index without a per-tool copy. Proprietary formats force duplicate pipelines, and every copy is another freshness problem.
Check two things: whether the definition is versioned and machine-readable, and whether the agent reports which version it read. If metric logic lives only inside a BI tool or an analyst's head, you cannot know. Make the semantic layer the single source, then require every agent answer to cite it.
No. A knowledge graph earns its cost when cross-system relationships are the hard part, such as linking a claim to a policy and an adjuster. If your questions sit inside a few well-modelled tables, a versioned metrics layer and a populated catalogue get you further for less money. Choose by question shape.
The opposite. Data engineering for agentic AI carries more weight, not less, because agents remove the person who used to notice that a number looked wrong. What changes is the output of the work. Catalogues, semantic models and audit trails now matter as much as the pipelines feeding them.
There is no list price. Five things drive it. Count the source systems the agent touches, the share of data that is unstructured, and the metric definitions that are contested. Then set a freshness budget per decision, and decide whether the agent writes or only reads. Scoping one workflow first keeps the number honest.
-1.svg){kind=small}
