Data readiness for AI agents

Ask most consultants whether your data is ready for an AI agent and you get the same answer. Fix the estate first. Build the catalogue, write the data contracts, stand up a semantic layer, agree ownership across every system, then come back in 9 months and we will talk about agents. The advice is not wrong. It is just unaffordable for almost every company that receives it, and it quietly kills more agent projects than weak models ever have.

Here is the reframe that changes what you do on Monday. Data readiness is not a property of your company. It is a property of one workflow. The refund approval process at a 60-person SaaS company can be completely agent-ready while the same company's reporting stack is a swamp nobody has touched since the last migration. Testing the swamp tells you nothing useful about refunds. Yet the estate-wide assessment tests the swamp, returns a red score, and the agent project dies of a verdict that was technically correct and practically meaningless.

This article is written for founders, CTOs, and operations leaders at companies roughly between 20 and 500 people who have a real workflow worth automating and no appetite for a data governance programme. If you run a regulated enterprise with 400 source systems and a chief data officer, the estate-wide programmes genuinely are for you, and this piece will feel too small.

You will get a working definition of data readiness for AI agents, why the estate-first sequence fails so reliably, the 7 checks that tell you whether one workflow is ready, how to score them honestly, what to do in days rather than quarters when a check fails, and a worked example with real numbers.

‍

Key takeaways

• Data readiness for AI agents is a property of a single workflow, not of your whole data estate.

• The estate-first sequence takes 6 to 12 months and usually loses its sponsor before it produces anything an agent can use.

• You can score one workflow in 3 to 5 days with 7 checks: access, meaning, freshness, ground truth, action, reversibility, permission.

• Ground truth is the check nearly everyone skips. If you cannot produce 50 past cases with known correct answers, you cannot tell whether the agent works.

• Agents need a narrower slice of data than a warehouse does, but they need a write path and an undo, which BI never needed.

• Gartner expects over 40 percent of agentic AI projects to be cancelled by the end of 2027, largely for cost, unclear value, and weak risk controls.

• Score 6 or 7 and build now. Score 5 and fix the gaps in 2 to 4 weeks. Score 4 or lower and pick a different workflow, because the fix is longer than the build.

• The estate work still happens. It gets funded by a workflow that already produces a result, which is a far easier budget conversation.

‍

What data readiness for AI agents actually means

Data readiness for AI agents is the state where an agent can reach the data a specific workflow needs, understand what that data means, act on it, and be checked and corrected when it is wrong. It is a property of a workflow plus the systems that workflow touches. It is not a score for your organisation.

That definition matters because agent readiness is not the same thing as analytics readiness, and teams keep applying the older standard. A dashboard reads. An agent reads and then does something: it issues the credit, updates the record, sends the message, books the slot. Preparing data for a dashboard means making numbers correct and consistent across the business. Preparing data for an agent means making one path reliable end to end, including the part where something changes in a system of record.

So the bar moves in two directions at once, and this is the part that catches people out. It is far lower on breadth. An agent handling supplier invoices does not care that your marketing attribution is a mess or that finance and sales disagree about what counts as a closed deal. It touches maybe 4 tables and 2 systems. The estate-wide assessment scores all 40 of your systems and returns a red light driven by 36 systems the agent will never see.

The bar is considerably higher on the narrow slice. Humans quietly repair bad data all day. An operations person sees a supplier name spelled 3 ways and knows it is one company. They notice the invoice date is obviously wrong and check the email thread. They know that a status of pending in the old system actually means approved, because of a migration in 2023 that nobody documented. An agent has none of that. It treats what it reads as true and acts on it, at machine speed, without the pause where a person thinks that looks odd.

That is the real work of data readiness for AI agents. Not cleaning everything, but knowing precisely which repairs a human was silently performing in this one workflow, and deciding for each one whether to fix the data, encode the rule, or route the case to a person.

‍

Why fixing the data estate first is the wrong first move

The estate-first sequence fails for a reason that has nothing to do with whether the work is worth doing. It fails because it puts 6 to 12 months of cost in front of the first piece of evidence, and most organisations do not survive that gap politically.

Watch how it plays out. A readiness assessment runs across the business. It produces a genuinely good document: fragmented ownership, undocumented definitions, no lineage, gaps in access control. Remediation is scoped as a programme. Somewhere in month 5 the sponsor changes role, or a funding round shifts priorities, or a competitor ships something and attention moves. The programme is descoped. Two years later the same company asks the same question again and gets the same document, because nothing about the estate improved and nobody ever built the agent either.

The second failure mode is subtler and more damaging, because it looks like diligence. The assessment returns not ready, and that verdict is treated as a fact about the company rather than an average across systems of wildly different quality. Averages hide the thing you actually need to know. Somewhere in that estate there are usually 2 or 3 workflows sitting on decent, well-owned, well-understood data, and those workflows just got blocked by the state of a CRM nobody was going to connect anyway.

It is worth being honest about why this advice is so common. Partly it is the safe answer, because nobody was ever criticised for recommending better governance. Partly it is who gives the advice: much of the loudest content on AI-ready data is published by companies selling catalogues, contracts, and semantic layers, and the recommended first step is reliably the thing they sell. And partly the underlying analysis is simply correct. Gartner's prediction that over 40 percent of agentic AI projects will be cancelled by the end of 2027 points at escalating cost, unclear business value, and inadequate risk controls. Weak data foundations feed all 3. The diagnosis is right. The prescribed sequence is what does the damage.

None of this means the estate work is optional forever. If you want to see what the full picture looks like when an organisation does commit to it, Martin Fowler's team published a thorough treatment of making your data ready for agentic AI, covering contracts, lineage, a context layer, and agent-ready access. It is serious engineering thinking and most of it is correct. Our disagreement is only about order. That work is what you fund after the first agent is running, using the running agent as the argument.

‍

‍

Get the AI blueprint we use for this

If you are picking a first workflow right now, our SaaS founder's AI Blueprint covers the same ground in a format you can take into a planning session: how to scope a first AI workflow, what to measure, and the places teams reliably overspend. It is free and takes about 20 minutes.

‍

The 7 checks that tell you if 1 workflow is agent-ready

Run these against a single workflow, not the company. Each one has a test you can complete in an afternoon, and each has a binary answer. Resist the urge to score anything amber, because amber is how a project talks itself into building on ground that will not hold.

1. Can the agent reach the data without a person in the middle?

The agent needs programmatic access to every system the workflow touches, under its own credentials, with the permissions it will have in production. Not a CSV somebody exports on Mondays. Not a screenshot. Not a colleague who runs a query when asked.

Test it by having an engineer pull the last 20 real cases through the actual interface in an hour. If they can, this check passes. If the answer involves a person, a spreadsheet, or a vendor conversation about API pricing, it fails, and you have just found the real cost of the project before you spent anything on it.

2. Is there 1 agreed definition of the key object?

Every workflow has a central object: an order, a claim, a shift, a patient visit, a ticket. The check is whether the people who run that workflow define it the same way, and whether the systems agree with them.

Ask 3 people who do the work to define it separately, in writing. If you get 3 different answers about when an order becomes an order, the agent will get all 3 and pick badly. This one is cheap to test and it is where most of the surprises live. You do not need an enterprise semantic layer. You need one written definition per workflow that the team signs off on.

3. Is the data fresh enough for the decision, not just accurate?

Freshness is judged against the decision, not against a general standard. A monthly forecast can live with data that is a day old. An agent deciding whether to release a shipment cannot work from a stock figure that syncs overnight, because it will confidently promise goods that left the warehouse this morning.

Write down the maximum staleness the decision tolerates, then measure the actual lag on the worst source in the chain. If actual lag exceeds tolerance, this check fails until you fix the sync or narrow the decision.

4. Can you produce 50 past cases with known correct answers?

This is the check that separates projects that ship from projects that argue. You need a set of real historical cases where you know what the right outcome was, so you can measure the agent instead of forming impressions about it.

Fifty is usually enough to start. They must be real cases with their real messiness, including the awkward ones, not a curated demo set. If nobody can assemble 50 such cases, either the workflow has no stable notion of correct, which means it is a judgement call and a poor first candidate, or the outcomes were never recorded, which is a fixable problem worth 2 days of somebody's time. Treat this as a hard gate.

5. Is there a way for the agent to act, not just answer?

An agent that can only produce text has moved the work rather than removed it. Someone still has to read the output and retype it into the system that matters. The workflow needs a write path: an API that creates the credit note, updates the record, or moves the ticket, and a service account allowed to use it.

Check whether that write path exists and whether anyone will approve the agent using it. The technical answer and the political answer are often different, and the political one takes longer.

6. Can you see what it did and undo it?

Every agent gets things wrong. Readiness is not about preventing that, it is about whether a wrong action is visible and reversible. You need a log of what the agent read, decided, and changed, plus a way to reverse a change without a database restore.

Ask what happens if the agent processes 200 cases incorrectly overnight. If the honest answer is that you would find out from a customer and fix it by hand, this check fails. The usual fix is small: write to a staging state that a person releases, or add a reversal path before you add autonomy.

7. Are you allowed to use this data this way?

The last check is legal and contractual, and it is the other hard gate. Does the workflow touch personal or special category data, does your privacy notice cover automated processing, does the customer contract permit sending this data to a model provider, and does the decision carry consequences for a person that trigger obligations under the EU AI Act.

The answer is usually yes with conditions, such as keeping processing in a specific region, logging decisions, or keeping a human in the approval step. Get those conditions written down before the build, because retrofitting them is where AI projects lose months. If you want a structured way to spot which workflows are worth this scrutiny in the first place, our guide to mapping the AI opportunities in your workflow pairs well with this test.

‍

‍

How to score it, and the honest cut line

Count the passes. The scoring is deliberately blunt, because blunt scoring produces decisions and nuanced scoring produces another meeting.

• 7 of 7: build now. Scope a first version at 6 to 10 weeks and put it in front of real users early.

• 6 of 7: build now, in parallel with fixing the one gap, unless the gap is check 4 or check 7.

• 5 of 7: spend 2 to 4 weeks closing gaps first. Most gaps at this level are access or reversibility, and both are ordinary engineering.

• 4 or fewer: pick a different workflow. The remediation is longer than the build, and you will spend the project's political capital on plumbing.

Checks 4 and 7 override the count. Without ground truth you cannot prove the agent works, so you will be arguing about impressions in every review, which is exactly how projects stall. Without permission you are building something legal will stop later, at a much worse moment. A workflow that passes 6 checks but fails ground truth is not a 6, it is a no.

One more thing worth saying plainly. A failed score is a good outcome. You spent 4 days and learned that this particular workflow is not the one, which is cheap. The expensive version of that lesson arrives in month 5 of a build.

‍

What to do when a check fails

Most failures have a fix measured in days. Here are the 3 we see most often and what they actually cost.

No programmatic access

An old system with no usable API is the most common blocker, and the most common overreaction is to propose replacing it. You rarely need to. A read replica of the database, a scheduled export into a small staging table, or a thin service in front of the legacy system usually gives an agent everything it needs within a week or two. Screen-level automation is a last resort, viable but fragile, and worth using only when the workflow's value clearly justifies the maintenance.

No ground truth

When the outcomes were never recorded, build the set by hand. Pull 50 to 100 past cases, sit with the person who does the work for 2 sessions, and have them state the correct outcome for each with a sentence of reasoning. This is the highest-value 2 days in the entire project. You get an evaluation set, and you get the decision rules the team has been carrying in their heads and never wrote down, which is usually more valuable than the set itself.

No undo

If a change cannot be reversed, do not start by making the agent autonomous. Have it write a proposed action into a queue that a person releases, and log every field it would have changed. You lose some of the time saving in the first weeks and you keep all of the learning. Once the evaluation numbers hold across a few hundred real cases, move the low-risk, high-confidence categories to automatic and leave the rest in the queue.

‍

A worked example: refunds at a 60-person SaaS company

Take a support team processing about 400 refund requests a month. Each takes roughly 9 minutes: read the ticket, check the subscription and payment history, apply the policy, issue or decline, write the reply. It is repetitive, it is expensive, and the team hates it. A textbook candidate.

Scoring it took 4 days. Access passed, because the billing provider and the helpdesk both have solid APIs and an engineer pulled 20 real cases through them in under an hour. Meaning passed after a short argument: 3 people defined an eligible refund almost identically, differing only on annual plans cancelled mid-term, which was resolved in one conversation and written down. Freshness passed comfortably, since payment data is current within minutes and the decision tolerates hours. Action passed, because the billing API issues credits and support already had a service account.

Three checks needed work. Ground truth failed at first, because outcomes lived inside free-text ticket replies rather than a field. Two afternoons with the support lead produced 80 labelled cases with reasoning, including 11 genuinely ambiguous ones that turned out to be the most useful examples in the set. Reversibility failed, since a credit issued in error required a finance person to reverse it manually. Permission passed with conditions: EU processing only, no card data in prompts, and a logged human approval for anything above 250 euros.

Score at the start: 4 of 7. Score 9 days later: 7 of 7, after building the label set and adding an approval queue for refunds over 250 euros. The build then ran 7 weeks. The agent handles roughly 70 percent of requests end to end and escalates the rest with a summary and a recommendation. Average handling time on the escalated cases dropped too, because the context arrives assembled.

The part worth noticing is that nothing about the company's wider data estate changed. The CRM is still inconsistent. Product analytics still disagree with finance. None of it mattered, because none of it was in the refund path.

‍

What happens after the first workflow

The second workflow is dramatically cheaper than the first, and this is the argument that wins the estate work later.

By the time the first agent is running you have built things that transfer. Service accounts and access patterns for 2 or 3 core systems. A logging and evaluation harness. An approval queue pattern. A written definition of one central business object. A legal review that has already answered the general questions about model providers, regions, and retention. The next workflow reuses most of that and typically scores 5 or 6 on its first pass instead of 3.

Do this 4 or 5 times and you arrive somewhere interesting. You have documented definitions for your most important objects, governed programmatic access to your main systems, decision logs, and evaluation sets. That is a meaningful share of what the estate-wide programme was going to deliver, except it was built in the order that produced value at every step, and each stage was funded by the result of the one before it. Sequencing is the whole argument. The destinations are not that different.

It is also the difference between a pilot that graduates and one that quietly dies, which we wrote about in more depth in why most AI pilots stall on the way to production.

‍

How we approach data readiness at Codelevate

When a client asks us whether their data is ready for an agent, we do not run a company-wide assessment. We ask which workflow, then run these 7 checks against that workflow with their team, usually inside a week, and give an honest answer including the answer nobody enjoys hearing, which is that a favourite workflow scores 3 and something less exciting scores 6.

Two habits matter more than the framework. First, we score against real cases, not descriptions of the process. What people believe the workflow does and what the last 20 tickets show are different documents, and the gap between them is where the project either succeeds or gets expensive. Second, we build the evaluation set before we build the agent, because a team that can measure the thing can improve it without us, and a team that cannot will be dependent on whoever built it.

If you want to see how that runs as an engagement, our AI automation agency page walks through the process, the team shape, and how a first workflow gets scoped.

‍

The short version

Data readiness for AI agents is a workflow-level property, not a company-level score, and treating it as the latter is why so many agent projects never start. Pick one workflow, run the 7 checks, and take the answer seriously in both directions: build when it passes, and walk away when it does not. You will get a real answer in under a week, for the cost of a few days of engineering time, instead of a programme that produces a document.

If you want a structured starting point, take the SaaS founder's AI Blueprint into your next planning session and use it to scope the first workflow properly.

‍

‍

And if you already have a workflow in mind and want a second opinion on whether the data behind it will hold, book a free call with our team and we will run the checks with you.