When the client’s data is worse than they said

Every forward-deployed engineer has the same week two.

You have access now. You run the first real query against the client's actual data, and it comes back wrong in a way that makes the agreed scope impossible. The customer table has duplicates that are not duplicates. The status field has values the schema does not document. A third of the records stop in March 2024 and resume in June with a different format.

Nobody lied to you. The people who described the system genuinely believe it works the way they said, because from where they sit it does — they interact with a reporting layer that has been quietly patching this for years.

This is the default condition, not a bad-luck engagement. Treating it as normal is what separates the third engagement from the first.

The one-day data triage

Before you tell anyone anything, spend a day producing findings rather than impressions. "The data is messy" is not actionable and sounds like an excuse. Numbers are actionable and sound like work.

Run these six checks on every table your use case depends on.

1. Completeness on the fields you actually need.

SELECT
  COUNT(*) AS rows,
  COUNT(customer_id)   AS has_customer,
  COUNT(closed_at)     AS has_closed_at,
  COUNT(category)      AS has_category
FROM orders;

Not every field — the three or four your feature depends on. A 4% null rate is noise. A 40% null rate is a scope change.

2. Time coverage, monthly. Count rows per month for two years. You are looking for cliffs and gaps. Every cliff has a story — a migration, an acquisition, a system swap — and nobody will volunteer it until you show them the chart.

3. Cardinality on anything categorical. SELECT DISTINCT on the fields that look like enums. If warehouse has 7 values and the company has 3 warehouses, you have found the normalisation work.

4. Duplicate identity. Count rows per supposed key. Real duplicates are easy; the expensive ones are near-duplicates — the same customer with a trailing space, a different case, an Inc versus Inc..

5. Referential reality. How many child rows point at a parent that does not exist? Orphans mean either a soft-delete you have not been told about, or a sync that has been failing silently for months.

6. Freshness. MAX(updated_at), per table. This is the one that most often ends a real-time feature. A table that was described as live and last updated eleven hours ago is a nightly batch with better marketing.

One day. Six numbers per table. Now you can have the conversation.

Saying it without detonating the engagement

The finding is not the problem. The framing is.

Do not lead with the data being bad. Your sponsor either does not know — in which case you have just told them their organisation is broken, in a meeting, in week two — or they half know and have been managing around it, in which case you have just made their private problem public.

Do lead with the consequence for the thing they asked for, then offer the options. The move is to stay on their side of the table and put the constraint on the other side.

A shape that works:

"I ran completeness checks across the four tables we need. Three are in good shape. On orders, the category field is empty on 38% of rows since the 2024 migration — so an agent that answers 'how many orders in category X' will silently be wrong by about a third, and it will be confident about it.

Three options. One: we scope category out of v1 and ship the other four question types on time. Two: we backfill category, which is roughly two weeks and needs someone from ops who knows the old mapping. Three: we ship it with an explicit 'partial data' warning on those answers, which I would not recommend for anything customer-facing.

My recommendation is one, then two as a fast follow. What would you like to do?"

Four things that framing does. It shows work. It quantifies the damage in terms of their use case. It gives them a decision rather than a problem. And it puts the choice with the person who owns the budget, which is exactly where it belongs.

The silent-wrongness principle

The reason data quality matters more for agents than for dashboards is worth stating plainly to a non-technical sponsor, because it is not obvious and it changes how seriously they take it.

A broken dashboard looks broken. A chart with a hole in it prompts someone to ask why.

An agent with a hole in its data produces a fluent, confident, complete-sounding sentence that is wrong. There is no visual cue. The failure mode of bad data plus a language model is not an error — it is an assertion.

That is the sentence that gets budget for a backfill. It is also the honest reason you should refuse option three above more often than is comfortable.

What you can still ship

Bad data does not mean no engagement. It means a different one, and often a more valuable one.

Narrow to the clean subset and be explicit about the boundary. If three of four tables are solid, ship the questions those three answer. An agent that handles 60% of questions correctly and says "I do not have reliable data on that" for the rest is genuinely useful. An agent that answers all of them and is wrong on 40% is worse than nothing, because it destroys trust in a way that takes a year to rebuild.

Make the refusal a feature. Wire the null-rate check into the retrieval path so the agent knows which fields it cannot trust and declines accordingly. This is a couple of hours of work and it is frequently the thing the client remembers about the engagement.

Ship the data-quality dashboard as a deliverable in its own right. You already ran the six checks. Turning them into something that runs nightly and alerts on drift costs you a day and delivers something the client did not know they needed. On more than one engagement this has been the artifact with the longest life.

Reframe the project honestly if it comes to that. Sometimes the truthful finding is: you do not have an AI problem, you have a data problem, and the AI project is how you found out. Delivering that clearly is a real outcome. Clients who get told this early, with evidence, tend to come back. Clients who get told it in month five do not.

The three-week rule

If the fix looks like more than about three weeks of data work, stop and escalate rather than absorbing it.

Engineers absorb this work. It feels like being helpful, and it feels faster than the conversation. But a data backfill inside an AI engagement is invisible on the invoice, it does not look like the deliverable, and when the timeline slips the story becomes "the AI project ran late" rather than "we discovered the ERP migration was never finished."

Escalate it as its own workstream with its own timeline. Whether they fund it is their call — but the record should show what it was.

Try this today — 45 minutes

Run the six checks above on the primary table of whatever you are working on right now. Client system, internal system, your own product's database — it does not matter.

Write the six numbers in a document. Then write one sentence for each: what would break for the user if this number stayed exactly as it is?

Most people find at least one number they did not expect, and about half find something that changes what they should build next. If everything comes back clean, you have earned genuine confidence in the foundation — which is also worth 45 minutes.

Keep the document. It becomes the baseline you compare against in month six, when someone says the agent "used to be better."

Related: Scoping an FDE engagement · When agents break · Wiring internal systems to agents · Live API vs ETL