When an AI project fails, the post-mortem usually blames the model. In our experience it is almost always the data, and the failure was predictable before a line of code was written.
My colleague Ryan has written about why readiness is the real work from the business side. This is the technical version: the five specific properties your data needs before automation on top of it is worth building.
One: things have to be identifiable
An agent needs to know when two records are the same thing. If a supplier appears as three spellings, a customer exists twice with different addresses, and a product is identified by name rather than a code, then every question that groups or joins is wrong before the agent does anything.
This is the most common blocker and the least interesting to fix. It is also non-negotiable, because there is no clever technique that recovers from not knowing what is what. Reliable identifiers, or a decided way to match records, come first.
Two: fields have to mean one thing
Look at the status field in any long-running system and you will usually find it means several things. It started as a workflow state, then someone used it to flag priority customers, then a team adopted a value for something else entirely.
People handle this fine because they know the history. An agent cannot, and it will not tell you it is confused. It will produce output that assumes one meaning and be quietly wrong about the rest.
Every field an agent reads needs one definition that the business agrees on. Where a field carries two meanings, they have to be separated before automation, not after.
Three: history has to be preserved
A lot of systems overwrite. The record shows the current state and the previous state is gone.
That is fine for running the business today and it removes your ability to ask why. How long does this normally take, is this unusual, was it always like this. Those questions need a record of what changed and when, and if it was never kept, no tool can reconstruct it. You start capturing it now and wait.
This is the one people discover latest and it costs the most time, because the answer is months of accumulation before the interesting analysis is possible.
Four: the timing has to match the decision
Data that arrives daily cannot support a decision that has to be made hourly. Obvious, and routinely missed.
Before building, we ask how fresh the input actually is at the moment the agent runs. If a system syncs overnight and the agent needs to act on this morning's activity, it is working from yesterday's world. Sometimes that is fine. Sometimes it makes the whole thing pointless, and it is far better to find out at the design stage than at launch.
Five: it has to be reachable, programmatically
Data in a system with no API, or locked behind a report a person runs manually, is not available to automation in any reliable sense. Nor is data that only exists in a PDF a supplier emails, until something extracts it.
This is a practical question with a real answer per system, and it belongs in the assessment. It decides whether the first piece of work is the agent or the connection underneath it. Usually it is the connection.
Why we look at this first
Because these five things determine whether an AI project is a six-week build or a six-month one, and you deserve to know which before you commit.
None of it is wasted work either. Data that is identifiable, consistently defined, historical, timely and reachable is valuable on its own. It makes your reporting true and your decisions faster whether or not you ever put an agent on top. The readiness has its own return, which is exactly why it should not be treated as a prerequisite you rush.
