Data quality used to be a reporting problem. Bad data made dashboards wrong, someone complained once a quarter, and the cleanup never got funded.

Agents changed the economics of that. A dashboard with bad data is misleading. An agent with bad data takes action on it, at volume, in ways that touch customers. The same underlying mess now has a much shorter path to consequence, which is why the cleanup that could not get budget for a decade suddenly has one.

Why agents amplify what reports only reveal

A report aggregates. Errors average out, and a human reads the total with some scepticism already applied.

An agent operates per record. It does not average anything. It reads one record, forms a view, and acts. If that record has a blank field where the process assumed a value, the agent does not see a slightly wrong average. It sees an absence and fills the gap with an inference.

Volume finishes the job. A person handling twenty records a day notices the odd one. An agent handling two thousand does not notice anything, and neither does anybody else until the pattern surfaces somewhere expensive.

The four problems that actually break agents

In practice the same four issues account for most of it.

Blank fields where the process assumes a value. The agent either declines, which frustrates people, or infers, which is worse.

Inconsistent picklist values, where the same concept is spelled three ways. To a human these are obviously the same. To an agent filtering or grouping, they are three categories.

Duplicates, where the agent updates one record and the organisation reads the other. This produces the specific failure where everything the agent did was correct and none of it appears to have happened.

Stale records that look current. Nothing marks them as superseded, so the agent treats a two year old note as a present fact.

• Blanks where a value was assumed.

• The same concept spelled several ways.

• Duplicates that split the truth across two records.

• Stale content with nothing marking it stale.

Fix it before the prompt, not after

The tempting sequence is to ship the agent, watch it fail, and patch the prompt to handle each case. This is how prompts reach nine hundred words and stop being maintainable.

Every instruction added to compensate for messy data is an instruction that has to be revisited on every model change, and that fixes the symptom for one agent while leaving the mess in place for the next one. Normalising a picklist fixes it for every consumer forever, including the reports that were quietly wrong the whole time.

The sequencing argument is simply that data fixes compound and prompt fixes do not.

Scope the cleanup to what the agent touches

The reason data quality projects fail is that they are scoped to the whole org, which makes them infinite.

An agent gives you a natural boundary. It reads a specific set of objects and fields. That list is usually small, often under twenty fields, and cleaning those twenty is a week of work rather than a programme.

• List the fields the agent actually reads.

• Measure completeness and value consistency on those only.

• Fix them, then expand scope with the next capability.

• Add validation so the same mess does not reaccumulate.

That last point matters more than the cleanup itself. Cleaning without preventing means doing it again in eighteen months, and the second cleanup is harder to fund than the first.

The short version

Bad CRM data was always a problem. Agents made it an urgent one, because they act on it per record and at volume rather than averaging it into a chart.

Scope the cleanup to what the agent reads, fix it before writing instructions to work around it, and add the validation that stops it returning. It is the least interesting work in an AI programme and it is usually the thing that decides whether the programme succeeds.