On this page
- Key Takeaways
- Agent Budgets Pay for the Part That Demos Well
- Pipelines Decide What Your Agent Knows
- Entity Resolution Is Where Confident Wrong Answers Start
- Access Controls Belong in the Data Layer First
- The Three Line Items Nobody Budgets For
- Readiness Lags Deployment, and Projects Die in the Gap
- Boring Data Work Is What Makes Agents Feel Smart
- FAQ
Key Takeaways
- Agent budgets go to the visible layer. Model access, prompts and a chat interface get funded because they demo well. The data plumbing under them usually gets a line that says "TBD."
- Pipelines decide what an agent knows. An agent reading a stale or half-loaded table will give you a confident, well-written, wrong answer.
- Entity resolution is where most wrong answers start. If "Acme Corp," "ACME" and "Acme Holdings LLC" are three customers in three systems, your agent will treat them that way.
- Access controls have to live in the data layer. A prompt that says "don't show salary data" does not count as a control.
- Budget the data work first. Split the agent budget into model, interface and data line items before anyone writes a prompt, and expect the data line to be one of the biggest.
Most AI agent budgets have the same shape. There is a line for model access. There is a line for building the interface, whether that is a chat window, a Slack bot or a sidebar in the CRM. There is a line for prompt work and a pilot. And somewhere near the bottom, if it shows up at all, there is a line for "data integration" with a number that looks like it was picked to make the total come out round.
Then the pilot ships, and the agent starts answering questions with numbers from last quarter, merging two customers into one, or showing a sales rep a document they were never supposed to see. Nobody blames the data at first. They blame the model, swap it for a bigger one, and the answers stay wrong.
Gartner has been saying this for a while. In a survey of 1,203 data management leaders, 63% of organizations said they either do not have, or are not sure they have, the right data management practices for AI. The same release predicts that through 2026, organizations will abandon 60% of AI projects that are not supported by AI-ready data. (That second number is a prediction. I still think it is closer to right than wrong.)
So here is the claim this post is built around: agents fail on bad data before they fail on anything else, and the root cause is usually a budgeting habit. The work that keeps an agent honest is pipelines, entity resolution and access controls. It is boring, it does not demo, and it is almost always the line item that gets cut.
Agent Budgets Pay for the Part That Demos Well
Think about how an agent project gets approved. Someone builds a prototype on a clean export, puts it in front of leadership, and it answers five questions perfectly. The room gets excited. The budget gets written around what was in that demo: the model, the interface, the prompts.
What the demo did not show is that the clean export probably took an analyst a couple of days to prepare by hand. Production does not get that analyst. Production gets the live CRM, the ERP's nightly dump, the shared drive with four versions of the same contract, and a ticketing system nobody has cleaned since it was migrated.
The gap between those two worlds is data engineering. It is real work, and it can easily be the larger share of a production agent build. It is also nearly invisible in a demo, which is exactly why it gets underfunded.
Price the data work before you price the model
Before you pick a model or a vendor, list every system the agent needs to read, how fresh that data needs to be, and who is allowed to see it. Then estimate the work to get each one into shape. If that list makes the project look expensive, good. You just found out now instead of three months into a pilot.
Pipelines Decide What Your Agent Knows
An agent knows exactly what you feed it and nothing more. If the pipeline that loads your pricing table failed silently last Tuesday, the agent is quoting last week's prices with total confidence. It has no way to know the data is stale. Neither does the person reading the answer.
This is the first thing that breaks when an agent moves from a demo to production. Demos run on snapshots. Production runs on pipelines, and pipelines fail: an API changes, a column gets renamed, a load times out. A dashboard with a broken load usually looks broken. An agent with a broken load just writes a plausible paragraph.
The fix is the same discipline data teams have used for analytics for years, applied with more urgency: scheduled and monitored loads, tests on the tables that matter, freshness checks, and alerts that go to a person who owns the fix. None of it is new. What is new is that a language model will hide a data failure behind good grammar.
Ask how old every answer's source is
For each source an agent reads, write down how fresh it needs to be for the answers to be trustworthy. Inventory counts might need hourly loads. Policy documents might be fine monthly. Then make the pipeline enforce that, and make the agent able to say when its data was last updated. If it cannot tell you that, you cannot tell whether to trust it.
Entity Resolution Is Where Confident Wrong Answers Start
If I had to pick one piece of data work that sinks the most agent projects, this is it, and almost nobody budgets for it by name.
Every mid-sized company has the same customer, vendor or product stored three different ways in three different systems. The CRM has "Acme Corp." The ERP has "ACME CORPORATION." Billing has "Acme Holdings LLC" because that is who signs the checks. A person who has worked there for two years knows those are the same company. An agent does not.
So ask the agent "how much did Acme spend with us last year?" and it adds up one of the three records. Or it finds two and misses the third. Or it merges Acme with a different company that happens to share a name. The answer comes back clean and specific, and it is wrong.
Entity resolution is the work of deciding, once, what counts as a customer, a product or a vendor, and mapping every system's records to that single definition. It is unglamorous matching and modeling work. It is also the difference between an agent that can answer cross-system questions and one that can only answer questions about one system at a time.
Define your core entities once
Pick the five or six entities your agent will reason about most (customers, products, vendors, employees, contracts, locations) and build one clean model of each. Every system maps to that model. The agent reads the model, never the raw tables. When finance, operations and the agent all use the same definition of "customer," the arguments about whose number is right get much shorter.
Access Controls Belong in the Data Layer First
Here is the failure that scares me most, because it does not look like a failure. The agent works. It answers the question. It just answers it using data the person asking was never supposed to see.
This happens when an agent gets a single service account with broad read access, because that was the fastest way to get the demo working. Then someone puts "do not reveal compensation data" in the system prompt and calls it a control. No auditor will accept it as one. A prompt is an instruction, and instructions can be talked around.
Gartner's prediction that over 40% of agentic AI projects will be canceled by the end of 2027 names inadequate risk controls as one of three reasons, alongside escalating costs and unclear business value. Gartner does not break that down to access controls specifically, so I won't pretend it does. But I'd bet a fair share of those risk-control cancellations trace back to an agent that could see too much.
Give the agent the permissions of the person asking
The pattern that holds up is simple to describe and real work to build. Tag sensitive data at the source. Enforce role-based access in the data layer. Have the agent query on behalf of the user, with that user's permissions, so it physically cannot return a row the user could not open themselves. Log every query. Then the system prompt can go back to doing what prompts are good at: tone, format and task.
The Three Line Items Nobody Budgets For
When we scope agent work at PressW, this is the split I push for before anything else. Three data line items, each with its own owner and its own estimate, sitting next to the model and interface lines instead of underneath them.
| Line item | What it covers | What breaks without it | The early warning sign |
|---|---|---|---|
| Pipelines and freshness | Scheduled loads from every source the agent reads, with tests, monitoring and alerts | The agent answers from stale or partial data and sounds certain doing it | Answers that were right last month are wrong this month, and nobody can say why |
| Entity resolution | One definition of each core entity, with every system's records mapped to it | Cross-system questions return partial totals, duplicates or merged records | Two teams get different answers to the same question about the same customer |
| Access controls | Sensitivity tags, role-based access in the data layer, per-user queries, audit logs | The agent shows people data they should not see, or legal shuts the project down | The agent runs on one shared service account and the controls live in the prompt |
None of these line items is exotic. Every one of them is standard data engineering. The problem is sequencing and visibility: they get treated as setup tasks inside the agent build instead of as work with its own budget, so they get squeezed when the timeline does.
Split the budget before the build starts
Write the three data lines into the budget as separate items with separate estimates. If someone wants to cut one, make them say which failure in the table above they are willing to accept. That conversation alone tends to protect the money.
Readiness Lags Deployment, and Projects Die in the Gap
The survey data on agents specifically lines up with all of this. Fivetran's 2026 Agentic AI Readiness Index, based on a Redpoint Ventures survey of 400 data professionals at larger companies, found that 41% of organizations are already using agentic AI in production, while only 15% say they are fully prepared to support it. The most cited barrier to reaching their agentic AI goals was data quality and lineage, at 42%. (Fivetran sells data pipelines, so weigh it with that in mind. The direction matches Gartner's independent read.)
Read those two numbers together. A lot of companies have agents running on data foundations they themselves do not trust. That is the gap where projects quietly die. The agent goes live, users catch a few wrong answers, trust drops, usage drops, and six months later someone asks why the AI investment did not pay off.
I'll say the uncomfortable part plainly. A better model will not close that gap. Newer models are better at reasoning over what you give them. They are no better at knowing that what you gave them is wrong.
Fund a data sprint ahead of the agent sprint
If you have an agent project starting next quarter, put a short, focused data sprint in front of it. Map the sources the first use case needs, fix the pipelines, resolve the core entities, and set up access. Then build the agent on top. We do this as part of PressW's AI & Data Readiness Assessment, which traces each priority use case back to the sources, fields and permissions it depends on before any build starts.
Boring Data Work Is What Makes Agents Feel Smart
The agents people love using are rarely the ones with the fanciest model. They are the ones that are right about the boring stuff: the current price, the full customer history, the document you are allowed to see. That reliability comes from the data layer.
We saw the same pattern on PressW's RodeoTurtle work. The value came from structuring scattered, unstructured public data into a coherent relational database that people could query, then piping enriched leads into the CRM. The intelligence on top only worked because the data underneath was shaped first.
I don't have a clean formula for how to split an agent budget. It depends on how messy your systems are, and honestly most companies don't know that until someone looks. What I'm confident about is that the data line should be written first, estimated honestly, and protected when the timeline gets tight.
If you are planning an agent build and want a second set of eyes on what the data side will really take, that's the work our Data Engineering team does every day. Book a Discovery Call and bring your source list.
FAQ
The most common reason is the data underneath them. Agents that worked on a clean demo export often fail when they meet live systems with stale pipelines, duplicate records and loose permissions. Gartner predicts organizations will abandon 60% of AI projects unsupported by AI-ready data through 2026.
At minimum, an AI agent needs reliable pipelines from every source it reads, one consistent definition of core entities like customers and products, and access controls enforced in the data layer. Testing, monitoring and lineage keep that data engineering work trustworthy over time.
Entity resolution is matching records that describe the same real-world thing, like one customer stored three ways in three systems, to a single definition. Without it, AI agents return partial totals, duplicate records or wrong merges when they answer questions across systems.
It depends on how clean and connected your systems already are, so there is no universal percentage. The safer habit is to estimate pipelines, entity resolution and access controls as separate line items before the build starts. A data readiness assessment gives you a grounded estimate.
No. A system prompt is an instruction, and instructions can be worked around. Real access controls for AI agents live in the data layer: sensitivity tags, role-based access and queries that run with the requesting user's own permissions, plus audit logs.
No. Newer models reason better over the data they receive, but they cannot tell that a table is stale or that two records are the same customer. Fixing the data engineering underneath is what improves AI agent accuracy in those cases.
