Check the data when the agent uses it, not only when it is loaded. If a fact it needs is missing, stale, contradictory or malformed, the agent holds rather than acts, records why, and routes the problem to the data's owner. The fix happens at the source, never as a workaround inside the agent, and the pattern is reviewed weekly.
Why are data problems more dangerous with an agent?
Because people compensate without noticing. An experienced clerk sees a postcode missing and looks it up; sees two addresses and knows which is current; sees an amount that looks wrong and checks it. An agent does exactly what the data supports. If the data is wrong, a confident wrong action follows, at volume.
The answer is not to make the agent guess better. It is to make the agent recognise bad data and stop.
What problems should the agent detect, and what should it do?
| Problem | How the agent detects it | What it does | Who fixes it |
|---|---|---|---|
| Missing field | Required field empty | Holds; asks the customer if the fact is theirs to give | Data owner, or the customer |
| Stale data | Timestamp older than the freshness limit | Holds; does not use the old value | Owner of the feed or extract |
| Conflict between systems | Same fact differs in two sources | Holds; shows both values | Owner of the system of record |
| Malformed value | Wrong format, impossible value | Refuses to use it; flags it | Data owner |
| Duplicate record | Two records match the same customer | Holds; flags possible duplicate | Data owner |
| Weak source | Fact only from an external or unverified source | Uses it for drafting only; never to authorise | Verification team |
Every hold carries a reason code like "data quality: stale", so the pattern can be counted.
What are the steps, and who does each?
- Process owner: list the data the agent depends on. Every field each capability reads. Evidence: the data dependency list.
- Data owners: accept ownership per source. A named owner for each system or feed. Evidence: the owner register.
- Data owners and process owner: write quality rules. Required fields, freshness limits, valid formats, which system wins in a conflict. Evidence: the rules, versioned.
- Platform team: check at the moment of use. Each fact carries its source and time; the rules run before any action. Evidence: check results on each verdict.
- Agent: hold and route. On failure, it holds and routes to the data owner's queue. Evidence: the hold with its reason code.
- Data owner: fix at source. Correct the record or the feed. Evidence: the correction record.
- Agent operations lead: review weekly. Counts by reason code and source. Evidence: the review note and actions.
Some fixes can be drafted by an agent too, at depth 2, with people approving; fixing data quality issues in customer records with an AI agent covers that.
What does this look like in practice?
Take a credit union's member services team. Its agent prepares annual statements and responds to address-change requests. In the first week, the agent holds a noticeable number of statements with the reason "conflict between systems": the member system and the mailing system hold different addresses.
The operations lead groups the holds and finds most come from members who changed address through one channel that updated only the member system. The data owner for the mailing system confirms the member system is the record for addresses, fixes the channel so both update, and corrects the existing mismatches in a controlled batch. The agent releases the held statements once the records agree. Without the holds, statements would have gone to old addresses.
How is this different from data drift?
Data quality problems are errors: values that are wrong, missing or out of date. Data drift is a change in what correct data looks like over time, such as a new type of customer request or a new document format. Drift does not trigger these checks, because each value may be valid. It shows up instead as rising holds, refusals or edits on a capability, and is dealt with by re-testing the agent on recent cases.
Data checks belong in the shadow stage of deploying an AI agent, where live data shows problems that test cases miss.
Questions people ask
Should we clean all our data before deploying an agent?
No. Clean the data the first capabilities depend on, and let the agent's holds show you where the rest of the problems are.
Can the agent fix bad data itself?
It can draft corrections for a person to approve. Changing a record of truth on its own judgement is a separate capability with its own testing and depth.
What if the data owner does not fix the problem?
Escalate through the process owner. Persistent holds from one source are a cost the source's owner should see.