The pitch is familiar: deploy an agent, give it a goal, watch it manage your workflow autonomously. Having spent a long time building integration systems for companies that tried exactly this, my observation is that most agent deployments fail on data quality — and almost none of them fail loudly.
There are no stack traces. No alerts. Just a system making decisions from incomplete, inconsistent or stale information, and nobody noticing until the damage has compounded.
I watched a reconciliation agent go live that was supposed to match supplier invoices to orders. Within 48 hours it had "resolved" two hundred transactions by classifying them all as duplicates, because the incoming records had no reliable timestamps and duplicate was the best explanation available to it. The agent worked exactly as designed. The data was the problem.
Why agents are different
Conventional software engineering has a luxury we rarely acknowledge: developers see the bugs. Process a payment twice and someone finds the duplicate charge. The failure surfaces.
Agentic systems remove that feedback. You give the system a goal, grant it access to data, and step back. It makes decisions autonomously, often thousands of them, often in parallel. There is no single output for a human to inspect.
Three specific ways bad data breaks them:
Agents make assumptions about consistency. If a field is sometimes present and sometimes absent, the agent has to guess what its absence means. It will guess consistently — probably wrongly — across every decision it makes. A human hitting the same ambiguity asks someone. The agent doesn't know there's a question to ask.
Agents inherit the shape of your business process. Data quality gaps are rarely random; they encode how your organisation actually works. One region skips a field because their workflow never needed it. The agent learns that pattern as a rule and extrapolates it into situations where it is nonsense.
The explanation is only as good as the inputs. Agents give reasons: "flagged as duplicate because no distinguishing timestamp." That sounds like transparency. It isn't, quite — it tells you what the agent saw, not whether what it saw was true. A decision that is well-reasoned from bad data looks identical to a good decision.
Schema-first governance
What has worked for me is unglamorous and non-negotiable.
Define the schema explicitly. Field names, types, null handling, constraints, enumerations. Where a field can be absent, document what absence means — not applicable is a different thing from not yet known, and an agent cannot tell them apart unless you say so.
Timestamp everything. Created, modified, processed. Agents reason about sequence and staleness, and cannot do either without time. Most of the silent failures I have seen trace back to this one line.
Validate at the source, not in the prompt. There is a strong temptation to patch data problems by adding instructions to the agent: "ignore records where the supplier name is blank." That moves the problem somewhere less visible and less testable. Fix it in the pipeline, log failures loudly, and quarantine bad records rather than letting them through with a caveat.
Version the schema. Evolve it additively. Changing a field's meaning in place is how you get an agent confidently applying last quarter's semantics to this quarter's data.
Fix the data in the pipeline, not in the prompt. A prompt-level workaround is an undocumented business rule living in a text field.
What the difference looks like
A rebate reconciliation agent for a large agricultural retailer, first attempt: three source systems producing "clean" CSV exports. No timestamps, duplicate records, supplier names spelled inconsistently across systems, currency implied rather than stated. The agent flagged around 40% of perfectly valid transactions as anomalies — useless, because a queue that size is one nobody works through.
We then did the boring work: validation in the ETL layer, timestamps on every record, canonical reference tables for suppliers and products, deduplication before ingest. Second attempt flagged under 2%.
The agent did not change. Same model, same prompts, same logic. The data changed. I find that the single most useful fact to put in front of anyone who believes their agent problem is a model problem.
Before you deploy
Six questions. A "no" to any of them is a prediction of how the deployment fails.
- Is the schema documented, including what null means for each field?
- Are enumerations explicit, or are there free-text fields the agent will have to interpret?
- Does every record carry timestamps?
- Is validation happening at the source rather than in the agent's instructions?
- Do you know your dirty data ratio — the actual number, from a sample?
- Can you trace any single decision back to the exact records that informed it?
That last one is the one people skip, and it is the one that matters most in a regulated setting. If you cannot reconstruct what the agent saw, you cannot explain a decision to a regulator, an auditor, or an angry customer — and you cannot debug it either.
None of this is exciting work. It is also the entire difference between an agent that compounds value and one that compounds errors.