Introduction

Autonomous agents do not fix bad data. They act on it faster and hide the failure better. This is the central risk when a customer data infrastructure is repurposed to serve AI agents rather than dashboards, and it reframes the buying question. The question is no longer whether an organisation can deploy an agent; most can. It is whether the organisation’s data can survive one making decisions on it.

The distinction matters because agentic systems change the failure mode. Static automation fails where a person can see it. Agents fail where no one is looking. Readiness, therefore, is best understood not as a model-selection problem but as a property of the data layer beneath the agent — one that can be specified precisely and built in a fixed order. This article defines that property and sets out the ordered work, threaded through a single worked example. It is the roadmap that sits underneath the separate, testable question of whether a given platform can serve the result in time, treated in Datawhistl’s analysis of the readiness test most packaged CDPs fail.

Root cause: an agent reasons on bad data rather than breaking on it

Static automation tends to fail visibly. When a hard-coded marketing journey meets bad data, it breaks where a human notices: a merge field renders “Dear [FirstName]”, a segment returns empty, a report shows an obviously wrong number. A checkpoint exists, and the failure announces itself.

An agent fails differently. Given the wrong facts, an autonomous agent does not break — it reasons. It produces a confident, fluent, and incorrect decision that looks correct, then acts on it without escalation. The failure stays invisible until it surfaces in the customer experience or the profit and loss account.

The mechanism is visible in a concrete case. Consider a premium grocer such as Waitrose and a high-value loyalty member — for illustration, a MyWaitrose customer, historically a weekly online shop of roughly £230, now lapsed for 35 days. The prior approach fires a static “£15 off” email on the next batch run. The agentic approach hands the decision to an autonomous agent: read the full profile, infer why the customer lapsed, and act to win the account back within a defined window. That is a better outcome when the underlying data is sound. When it is not, the same autonomy becomes a liability. If the agent cannot see that the member logged a produce-quality complaint three days before the last order, it will confidently offer a price discount to a customer who left over quality, not cost. The action will read as personalised and intelligent. It will be wrong, and because the machine no longer requires a human to select its next step, no one will catch it. Bad data is not corrected by the agent; it is executed at machine speed and scale.

Readiness is a property of the data, not the model

Most “are we ready for AI?” discussions drift toward model choice, prompt quality, and agent configuration. That is the visible layer, and it is the wrong place to begin. Readiness is a data condition, and it can be stated as one requirement: agent-ready data is data an autonomous agent can retrieve as a complete, correct, and current view of the customer, fast enough to act on, under governance, and with a record of why it acted.

Five properties follow. Data is complete when the agent sees the whole customer rather than fragments; correct when the facts it reasons on are true; current when they are fresh enough for the decision at hand; governed when the agent acts within consent, permission, and hard limits; and auditable when the organisation can reconstruct what the agent knew and why it chose as it did. Every task on the readiness roadmap serves one of these five properties. None of them is a model capability; all of them are data infrastructure.

The analytics-ready foundation: rungs 1–4

The work is best understood as a ladder rather than a menu, because the rungs depend on one another. Trustworthy metrics cannot be computed before identity is resolved; autonomy cannot be granted before governance exists. Many organisations attempt to start at the top — deploy the agent — while the data sits on the bottom rung. The first four rungs correspond to what is conventionally called analytics-ready data: necessary for an agent, but, as the platform-level analysis argues, not sufficient.

Rung 1 — Connect the right sources, in the right mode. Inventory the systems that hold the truth — loyalty, ecommerce, service, in-store point of sale — and decide per source whether it must stream in near-real time or can arrive in batch. An agent can only reason on what is flowing. If the service complaint feed is never connected, the agent never sees the quality issue and defaults to the wrong discount. Completeness begins at the pipe.

Rung 2 — Resolve identity into one profile. Configure identity resolution so the web order, the app order, the loyalty card, and the service case collapse into a single customer, with defined match rules and a reconciliation cadence. Every downstream metric and decision silently assumes one person. Without resolution the agent sees two half-profiles — one “lapsed”, one “active” — and either double-contacts the customer or misjudges total value. This is frequently the most under-invested rung and among the most damaging to get wrong.

Rung 3 — Harmonise into a consistent model. Map each source’s fields into standard objects with agreed semantics: one definition of order value, one of order date, one of active customer. The agent reasons on the model, not the raw feeds. Without harmonisation, average order value means basket-including-VAT from the website but excluding-VAT from store, and any threshold the agent relies on fires inconsistently. Correctness lives here.

Rung 4 — Build trustworthy metrics, and prove them. Define the derived signals the agent actually decides on — days since last order, average-order-value band, discount sensitivity — and validate that they are both correct and fresh. These metrics are the agent’s premises; it does not re-derive them, it trusts them. A stale metric that reports a 35-day lapse for a customer who ordered yesterday will drive a confident, wrong “win-back”.

The serving bar: rungs 5–7

The final three rungs are where readiness stops being about the data in the abstract and starts being about whether the infrastructure can serve that data into a live decision. This is the serving bar the platform-level analysis drills into; the two treatments describe one staircase, where this ladder builds the whole structure and that test stress-tests its top rungs against real platforms.

Rung 5 — Align freshness to the decision. Map each data point to how current it genuinely needs to be. A lapse trigger has to be near-real time; a category affinity can be a day old without harm. The slowest layer on the critical path — streaming ingestion, a streaming metric, timely identity resolution — must meet that bar. “Real-time agent” is a marketing claim if any layer on the trigger path is batch. This is also where readiness becomes a question of whether the platform can actually serve the profile in the decision window. In Salesforce Data Cloud, for instance, the metrics an agent relies on are frequently computed on a scheduled cadence, so a 35-day lapse only registers when that job runs — the raw event may be fresh while the served profile lags. Whether a given platform clears this bar is a separate, testable question, treated in depth in the readiness test most packaged CDPs fail; this article does not re-argue the platform comparison and defers to that treatment.

Rung 6 — Govern: consent, PII, access, and enforced limits. Encode consent and channel permissions as data the agent is required to check, classify personal data, and — critically — enforce hard limits such as offer caps and suppression rules in code, not in prompts. An instruction that says “never exceed £20” is guidance a language model can reason around; a coded action that cannot return more than £20 is a control. An autonomous system acting on personal data without this layer is a compliance incident waiting to scale. Governance at serve time is what makes autonomy safe rather than reckless.

Rung 7 — Make it retrievable and auditable. Expose the unified profile so the agent can read it in one fast, keyed call — a headless, API-first customer data layer, where profile APIs replace the dashboard as the primary consumer — index any unstructured content the agent must ground on, and log every decision with its rationale and the facts it used. Retrievable grounding keeps the reasoning factual; the audit trail is how the system is governed after the fact and explained to a regulator, a customer, or a risk team. This rung is what turns ready data into data an agent can safely use, and it is the defining characteristic of customer data infrastructure built for AI agents rather than for reporting.

The budget is inverted from the attention

Rendered as a structure, the finished system is a pyramid. The agent — the layer that draws the demonstrations and the board slides — is a thin cap at the top. Beneath it sit six broad foundational layers: connected sources, resolved identity, a harmonised model, trustworthy metrics, aligned freshness, and governance. Attention flows to the cap; the work, the time, and the cost flow to the base.

This inversion is the single most useful point to convey to a sponsor. An agent programme is, in practice, mostly a data-infrastructure programme — six rungs of unglamorous foundation work — and the agent is the visible layer earned at the top. Organisations that invert the sequence, starting with the agent and assuming the data will hold, do not obtain a smarter customer experience. They obtain a faster, more confident, and harder-to-detect liability.

Conclusion

The pragmatic first move is not to select an agent use case and reverse-engineer the data. It is to take one genuine, contained use case — a lapsing high-value customer is a good example — and walk it down the ladder, testing each rung against current reality: which sources feed this decision, and are they connected; is the customer resolved to one profile; is every metric the agent would trust correct and fresh enough; are the limits enforced in code; can the decision be reconstructed afterwards. The gaps that exercise exposes are the real roadmap. Most teams discover they are not agent-ready but agent-curious, and the entire distance between the two lives in the data foundation, not the model.

Agentic AI raises the stakes on data quality because it removes the human who caught the mistakes and acts at machine speed. Readiness is accordingly a claim about whether the data is complete, correct, current, and governed enough to hand a machine the keys — and whether the organisation can prove, afterwards, why the machine did what it did. Once that work is understood, the next question is whether the platform can serve the result into a live decision — the seconds-horizon serving bar that most packaged CDPs quietly fail. This ladder builds the foundation; that test indicates whether the top of it will hold under a real-time agent.

Frequently asked questions