Key takeaways
- Agents fail in production because the data is incomplete, stale, duplicated, or malformed, not because the model reasons poorly; demos run on curated records.
- The numbers agree: 95% of GenAI pilots show no P&L impact (MIT), 42% of companies abandoned most AI initiatives in 2025, and Gartner expects over 40% of agentic projects canceled by 2027.
- Every failure maps to a dimension: wrong answers to timeliness, contradictions to uniqueness, "I don't know" to completeness, malformed actions to validity, compliance leaks to PII safety.
- Bad data does not stop an agent; it steers it, producing fluent, confident, wrong results that fail silently at the speed of automation.
- Measure before you ship: score the exact objects and fields the agent will read, dimension by dimension, and treat that score as a launch gate.
The agent demo looked flawless. It answered every question, took the right action, and closed the loop without a hitch. Then it shipped, and the support queue filled with confused customers and escalations. Nothing about the model changed between the demo and production. The data did.
Demos run on curated data. Someone hand-picked the records, cleaned the fields, and removed the duplicates before anyone watched. Production runs on your real CRM: the Account created in 2019 that nobody has touched since, the two contact records for the same person with different email addresses, the free-text notes field with a Social Security number pasted into it. The agent is the same. The ground it stands on is not.
This is the pattern behind most agent failures. The reasoning layer gets the attention because it is new and impressive. The data layer gets the blame it deserves once the failures start.
Why do most AI agents fail in production?
Most AI agents fail in production because the data feeding them is incomplete, stale, duplicated, or malformed, not because the model reasons poorly. An agent grounded in your CRM inherits every gap and contradiction in that CRM. When the underlying records are wrong, the agent confidently returns wrong answers, and confidence makes the failure harder to catch.
The model is rarely the weakest link. Modern language models handle reasoning well enough for most support, sales, and operations tasks. What they cannot do is know that the entitlement record they just read expired eight months ago, or that the account they are quoting was merged into another one last quarter. The agent trusts what the data tells it. If the data lies, so does the agent.
This is why so many pilots stall before they ever reach real users. Gartner projects that through 2026, organizations will abandon 60% of AI projects that are not supported by AI-ready data. The projects do not fail because the technology cannot work. They fail because the data underneath was never ready to be trusted.
What happens when an AI agent gets bad data?
When an AI agent gets bad data, it does not error out or ask for help. It produces a fluent, confident, wrong result, and it acts on that result. Bad data does not stop an agent; it steers it. A missing field becomes an unhelpful “I don’t know,” a stale field becomes a wrong quote, and a duplicate record becomes a contradiction the agent cannot see.
This is more dangerous than a system that fails loudly. A crashed integration gets noticed and fixed. An agent that reads a wrong balance, drafts a confident reply, and sends it to a customer looks like it is working perfectly right up until someone downstream discovers the damage. The failure is silent, and it scales at the speed of automation.
The specific failure depends on which kind of bad data the agent hits. That is worth mapping precisely, because each failure mode traces back to a measurable weakness in the data.
What the numbers say
The numbers around AI adoption are sobering once you separate ambition from outcome. MIT’s 2025 study “The GenAI Divide: State of AI in Business” found that about 95% of enterprise GenAI pilots deliver no measurable P&L impact. The pilots run, the demos impress, and the profit-and-loss statement stays flat.
Abandonment is climbing too. S&P Global Market Intelligence reported that in 2025 the share of companies abandoning most of their AI initiatives before production jumped to 42%, up from 17% a year earlier. That is not a slow drift. That is a step change in how many teams pull the plug before going live.
Agentic projects specifically are on the same trajectory. In June 2025, Gartner projected that over 40% of agentic AI projects will be canceled by the end of 2027, citing cost, unclear business value, and inadequate risk controls. And the underlying tax has been known for years: Gartner’s widely cited estimate puts the cost of poor data quality at an average of $12.9M per year per organization. Agents did not create that problem. They inherit it and amplify it.
The failure taxonomy
Every agent failure in production maps to a data quality dimension. Name the symptom, and you can usually name the dimension behind it. This table is the shortest path from “the agent is acting weird” to “here is what to measure.”
| Agent failure mode | Data quality dimension behind it | What it looks like in the wild |
|---|---|---|
| Wrong answers | Timeliness (stale data) | The agent quotes a price, entitlement, or status that was correct months ago and is wrong now |
| Contradictory answers | Uniqueness / Consistency (conflicting duplicates) | Two records for the same customer disagree, so the agent gives different answers to the same question |
| “I don’t know” gaps | Completeness (missing fields) | The agent stalls or deflects because the field it needs is blank on the record |
| Malformed actions | Validity (bad formats) | The agent tries to send to a broken email, dial a malformed phone number, or write an out-of-range value |
| Compliance leaks | PII safety (exposed PII) | The agent surfaces a Social Security number or card number sitting in a free-text notes field |
Wrong answers come from stale data. A LastActivityDate from 2019 does not stop the agent from reading the record; it just means the values on that record describe a customer who no longer exists in that form. Timeliness is the dimension that catches this, by flagging records that have aged past a threshold you set.
Contradictory answers come from duplicates that disagree. When one Account says the customer is on the Premium plan and a duplicate Account says Basic, the agent has no way to know which is true. It picks one, and the next time it picks the other. Uniqueness surfaces the duplicates; consistency surfaces the records that drift from the expected standard.
“I don’t know” gaps come from missing fields. If the renewal date is blank, the agent cannot answer a renewal question, so it deflects. Completeness measures exactly this: the share of records where the fields the agent depends on are actually populated.
Malformed actions come from invalid formats. An email like john@company passes a human’s glance and fails the send. The agent attempts the action, the action bounces, and the workflow breaks halfway through. Validity checks whether fields match the format their type requires.
Compliance leaks come from PII sitting where it should not. A card number pasted into a case comment becomes something the agent can retrieve and repeat. PII safety scans free-text fields for these patterns before an agent ever reaches them. For the Agentforce-specific version of these symptoms, walked through one by one, see the Agentforce-specific breakdown. These five map to the broader five dimensions of data quality that every scan is built on.
A case walk-through
Consider a composite scenario, typical of what happens in the first weeks after an agent goes live. It is not a specific customer, but the shape of it repeats across orgs.
A support agent handles a chat from a customer asking what their plan covers. The AI agent reads the linked Account, finds the entitlement field, and cheerfully quotes the Premium support tier: 24/7 coverage, two-hour response. The customer is delighted. The problem is that this customer churned four months ago and downgraded before that. The record the agent read was a stale duplicate. The original Account had been superseded by a newer one when Sales re-created the customer during a failed renewal, and nobody merged them.
So two data problems stacked. The LastActivityDate on the quoted record was months old, a timeliness failure. And a second Account existed for the same customer with the correct, downgraded status, a uniqueness failure. The agent had no signal that either was true. It read the first record it matched and answered with total confidence.
The customer later demands the coverage they were promised. The support team spends an afternoon reconstructing what happened, and only then discovers the duplicate. Had the org scanned these Accounts beforehand, both signals would have surfaced: the stale record flagged by a freshness check, the duplicate flagged by a uniqueness check. Neither is exotic. Both are measurable before an agent ever touches the data.
The readiness gate
The lesson is not “clean everything first.” It is “measure before you ship.” You cannot fix what you have not counted, and you cannot trust an agent whose data you have never scored. Treat data quality as a gate the agent has to pass through, not a cleanup you do after it fails.
That means scoring the org dimension by dimension before the agent goes live. This is where Data Quality Sense fits. DQS is a Salesforce-native platform for defining, scanning, and visualizing data quality across any SObject. You configure a scan in DQS Builder, pick the object and fields your agent will actually read, and set thresholds per field. The batch engine runs the scan, on demand or on a schedule, and Insight Studio returns the results.
The output is a weighted score from 0 to 100, broken down by dimension. Completeness tells you how many of the fields the agent needs are actually filled. Timeliness (shown in-product as Data Freshness) tells you how much of the data has aged past your threshold. Uniqueness counts the duplicates. Validity checks the formats. PII safety scans your free-text fields for exposed Social Security numbers, card numbers, emails, and phones before the agent can surface them. Dimensions you do not scan are excluded from the score rather than penalizing it, so the number reflects what you actually chose to measure.
DQS does not clean the data for you. It detects and reports, and it turns findings into follow-up: Tasks and Chatter posts on the impacted records so a human can act. That distinction matters. The point of the gate is not automated magic. It is visibility: knowing your completeness is 71% and your duplicate count is in the thousands before you point an agent at those records, not after a customer discovers it for you.
The uncomfortable truth
The agent is rarely the problem. When an AI project stalls in production, the instinct is to blame the model, swap the framework, or tune the prompts. Those are the visible, new, interesting parts. But the failure almost always traces down to the data layer that everyone assumed was fine because it had been fine enough for humans.
Humans compensate for bad data instinctively. They notice the record looks old, remember the customer churned, and mentally reconcile the duplicate. An agent does none of that. It takes the data literally and acts at scale. That is precisely why bad data that a team lived with for years becomes a production incident the moment an agent touches it.
So before you ship the next agent, score the ground it will stand on. Measure completeness, timeliness, uniqueness, validity, and PII exposure on the exact objects and fields the agent will read. If you want a fast read on where your org stands, start with the AI readiness assessment. Find the gaps before your customers do.
Artur Kolasa
Co-Founder, Data Quality Sense
Salesforce Certified Technical Architect helping global enterprises turn business goals into scalable Salesforce strategies. A decade of delivery and architecture leadership across Accenture, PwC, IBM’s Waeg and Publicis Sapient.