The Agentic Data Platform: AI’s Missing Foundation

Ninety-five percent of enterprise generative-AI pilots are delivering no measurable return on investment (MIT Project NANDA, The GenAI Divide, 2025). The instinctive reading is that the technology is overhyped. The more accurate reading is that almost none of those pilots failed because of the model. They failed because the model was the only thing anyone built. The demo ran on a clean spreadsheet and a helpful engineer. Production asked the same agent to read governed data across forty systems, answer correctly for thousands of users with different permissions, and act without leaking or inventing anything — and the platform that makes that possible was never there.

The Demo Works. The Deployment Doesn’t.

The pattern is now familiar in nearly every large enterprise. A six-week pilot produces an agent that answers questions impressively in a board demo. Everyone agrees it is the future. Then it enters production and disappears into a nine-month purgatory of “almost ready.” Gartner estimates that by the end of 2025, at least 30% of generative-AI projects will be abandoned after proof of concept — citing poor data quality, inadequate risk controls, and unclear business value as the dominant causes (Gartner, 2024).

The reason is not mysterious once you look at the gap between the two environments. In the demo, the agent had one curated dataset and a human who knew exactly which file was current. In production, it has to reach across dozens of source systems, none of which agree on what “customer” means, answer for thousands of users who are each allowed to see different things, and produce answers a regulator could audit. The model did not get worse between the demo and production. The absence of a foundation became visible.

That foundation has a name. It is an agentic data platform — and it is the part of enterprise AI almost nobody budgets for.

Why the LLM Is the Easy Part

The large language model is the most commoditised component in the entire stack. It is available through an API, it improves every few months without any work on your side, and it can be swapped for a better one in an afternoon. Spending the bulk of an AI budget agonising over which model to use is optimising the one part of the system that is already solved.

The hard part is everything between the model and the enterprise’s data and actions. A foundation model, on its own, solves none of the following three problems:

1. Getting the right data to the model at query time — governed. The model has no access to your transactions, your contracts, or your customers. Connecting it is the work, and connecting it safely is the hard work.
2. A shared definition of what the data means. Two tables both called revenue will give the agent two different answers. The model cannot tell which is correct; it will confidently pick one.
3. Letting the agent act without becoming a security liability. The moment an agent can do more than talk — trigger a refund, update a record, send an email — its permissions become an attack surface.

Buying a more powerful model to fix a missing data foundation is like hiring a brilliant analyst and handing them a shared drive of inconsistent spreadsheets with no indication of which is current, no rule about what they are allowed to open, and no log of what they touch. The analyst is not the problem.

What an Agentic Data Platform Actually Is

An agentic data platform is the governed layer that sits between foundation models and the enterprise’s data and systems. It supplies four things the model cannot: access to the right data, a consistent definition of what that data means, retrieval that respects security, and a safe path for the agent to take action — all under one policy framework.

It is not a model, and it is not a single product you buy. It is the connective foundation that turns a clever model into a colleague the business can actually trust — one that knows what the numbers mean, can only see what the person asking is allowed to see, and leaves an audit trail behind every action. This is the same governance discipline that underpins a unified data fabric, extended to the new demands of autonomous agents.

The Five Capabilities a Production Agent Platform Must Provide

The distance between a demo and a deployable system comes down to five capabilities. A do-it-yourself stack tends to have none of them; a real platform has all five.

1. Governed data access. The agent must inherit the entitlements of the person asking — row-level, column-level, attribute-based. When a sales rep asks an agent a question, it should see exactly what that rep is allowed to see, and nothing more. Databricks Unity Catalog and equivalent governance layers make this enforceable at the data layer rather than bolted onto the prompt.
2. A semantic layer. One definition of revenue, customer, margin, and active account — so the agent does not invent joins or guess which table is authoritative. Without it, the agent is fast, fluent, and wrong.
3. Vector search that respects governance. Retrieval-augmented generation grounds the agent in your documents and data, materially reducing hallucination. But an ungoverned vector index is simply a second copy of your sensitive data sitting outside your permission model. The embeddings have to be governed by the same policies as their source.
4. A security and identity boundary. Prompt injection, data exfiltration, and over-broad permissions are not edge cases — they are the default failure modes of an agent with real access. The platform constrains what the agent can see and do, by design.
5. An action and audit layer. An agent that can act needs approval thresholds and a logged, replayable trail of every action it takes. Autonomy without auditability is a liability, not a feature.

Databricks’ own analysis shows organisations running unified data and AI platforms deploy AI to production roughly three times faster than those stitching together separate warehouse and ML infrastructure (Databricks, State of Data + AI). The speed does not come from a better model. It comes from not having to rebuild these five capabilities for every new use case.

What “Unified” Actually Looks Like in Practice

Three patterns describe what the foundation unlocks — and none of them was made possible by a better model.

A customer-service agent that cannot leak. A retailer built a support agent grounded in a governed vector index over product manuals and returns policy, with the catalog enforcing which customer records the agent could read based on the identity of the customer it was speaking to. Hallucinations dropped because answers were retrieved, not generated from memory — and, critically, the agent could not surface data outside the requesting customer’s own account, because the entitlement was enforced at the data layer, not requested politely in the prompt.

A finance agent that stopped guessing. A multi-business group’s “ask revenue” assistant kept returning different figures for the same question, because it was choosing between tables that each looked plausible. The fix was not a smarter model. It was a semantic layer placed between the agent and the warehouses, giving it one authoritative definition of revenue and one set of approved joins. The agent stopped guessing.

A supply-chain agent that could safely act. A consumer-goods company deployed an agent that could trigger replenishment recommendations and, within limits, place them. The platform’s action layer enforced approval thresholds above a value ceiling and logged every action for audit. The autonomy was only acceptable because the boundary and the trail existed first.

How to Start

If your organisation has an impressive pilot and no path to production, the next step is not a better model. It is the foundation underneath it.

1. Start from one decision and one user — not one model. Pick a real workflow. Map exactly what data it needs, which definitions it depends on, which entitlements apply, and what actions it must take. That map is the specification for your platform.
2. Build the governed access and semantic layer before the agent. The agent is the last mile, not the first. Catalog, entitlements, and shared definitions come first; they are reused by every agent you build afterwards.
3. Treat the agent’s permissions as a security design, from day one. Identity-aware access, least privilege, and a full audit trail are not hardening you add later. For an agent that can see and act on enterprise data, they are the design.

The companies pulling ahead in enterprise AI are not the ones with access to better models — everyone has the same models. They are the ones who built the platform that lets those models work safely against real data.

A useful diagnostic to leave the next AI steering meeting with: if you swapped your agent’s underlying model tomorrow, how much of your work would survive? If the answer is “most of it,” you built a platform. If the answer is “almost none,” you built a demo.