Everyone wants to talk about the tools. Agents, MCP servers, copilots, the new CLI that writes your code. Nobody wants to talk about the data those tools are standing on — because data is boring, right up until the moment it costs you a client. Here is the number I keep in front of every AI conversation I have: through 2026, Gartner predicts organizations will abandon 60% of AI projects that aren’t supported by AI-ready data. Not 60% of bad ideas. 60% of projects whose foundation was never built. The models are extraordinary. The foundations are the problem — and the foundation is the part you control.
What I’ll Cover in This Blog
✔️ Why AI doesn’t hide your data problems — it multiplies them
✔️ The six symptoms of an org that isn’t ready (a diagnostic you can run today)
✔️ The sequence that works: Data → Context → AI → Automation
✔️ What “AI-ready” actually means (and why clean data isn’t the same thing)
✔️ The five layers of a data foundation, in the order you build them
✔️ The honest counter-argument: “can’t AI just clean the data?”
✔️ The pitfalls that quietly sink AI enablement programs
Now, let’s dive in. 🔥
The Scenario
Meet Vantage Media, a 40-person content agency. Their business runs on conversations: sales calls, client interviews, daily stand-ups. Every meeting is transcribed, and an AI drafts the follow-up email, extracts action items, and suggests content ideas from those transcripts. It’s a genuinely good workflow — the kind I’d recommend.
Except the transcription engine doesn’t know the client’s name. “Halden Instruments” comes out as “Holden instruments,” sometimes “golden instruments.” So the follow-up email greets the wrong company. The action item gets filed against a client record that doesn’t exist. The content idea references a product line the client discontinued last year, because the CRM record behind it was never updated. And nobody notices — because the output is fluent. It reads like someone competent wrote it.
The founder’s fix is to re-listen to the call whenever something matters. That’s not an AI workflow. That’s an AI workflow plus a human doing the work twice.
Vantage isn’t behind. Vantage is normal. In that same Gartner research, 63% of organizations either don’t have the right data management practices for AI or aren’t sure whether they do. The tool wasn’t the problem. The layer underneath it was.
AI Doesn’t Hide Bad Data. It Multiplies It.
This is the part I wish more leadership teams understood before they sign the budget.
A bad record in a report is a small, contained problem. Someone runs the report, sees a number that looks off, and asks about it. The error dies in a meeting.
A bad record behind an agent is a different animal, for three reasons:
🔹 The error gets laundered into confidence. A dashboard shows you a weird number and you squint at it. An agent gives you a fluent paragraph with no hedging, no source, and no visible seams. Fluency is not accuracy, but our brains score it like it is.
🔹 The error scales to every conversation. One wrong record used by one analyst is one mistake. The same record feeding an agent that handles a few thousand interactions a day is a few thousand mistakes — all identical, all confident, all before lunch.
🔹 The error becomes an action, not just an answer. This is the real shift in 2026. Agents don’t just answer; they write records, send emails, update cases, trigger workflows. A wrong answer used to cost you a correction. A wrong action costs you a customer relationship and an audit trail you have to explain.
I wrote about the retrieval mechanics behind this in Is “Ask Anything” AI a Myth? — the short version is that an agent never reads your whole database. It reads a handful of retrieved chunks and answers from those. If the retrieved chunks are wrong, the answer is wrong, and no amount of prompt engineering repairs it.
Put plainly: AI processes bad information faster than your team ever could. If the data is wrong, AI is just a faster way to reach the wrong decision — and to reach it in front of a customer.
The Six Symptoms of an Org That Isn’t Ready
Every engagement that goes wrong shows the same six things underneath. Read this as a diagnostic — if you recognise three or more, the agent is not your next project.
🔹 Fragmented customer data. The customer exists in CRM, in the billing system, and in someone’s spreadsheet. The agent will answer from whichever one it was pointed at, and none of them is the whole picture.
🔹 Duplicate records. Three Accounts for one company means three different “truths” about their contract, and a 1-in-3 chance of the agent picking the right one.
🔹 Critical information in spreadsheets. If the entitlement matrix lives in someone’s file, it is not in your foundation. It is not permissioned, not versioned, and not retrievable — and the agent cannot see it at all.
🔹 Systems that disagree. Two systems, two statuses, no rule for which wins. A human resolves this with a phone call. An agent resolves it by picking one, confidently.
🔹 Incomplete history. A model reasoning about a customer relationship from 40% of the interactions isn’t being careful about the missing 60% — it doesn’t know it’s missing.
🔹 No declared source of truth. This is the one that quietly breaks everything else. If nobody has written down which system wins for each field, then every conflict is resolved by accident.
None of those are AI problems. They are all data problems that only look like AI problems once you put an agent on top — which is why replacing the model, the prompt, or the vendor never fixes them.
The Sequence That Works: Data → Context → AI → Automation
Most programmes run the sequence backwards. They start with the agent, then work down toward the data only when the agent embarrasses them. The order that actually works is bottom-up, and each step is a prerequisite for the next:
1️⃣ Data — unified, deduplicated, with a declared source of truth per field.
2️⃣ Context — the business meaning on top of that data: what the fields mean, what the metrics mean, who’s allowed to see what.
3️⃣ AI — grounded answers, with citations, on top of data and context.
4️⃣ Automation — only once answers are trustworthy do you let the system act on them unattended.
The failure mode is skipping straight to step 3 and hoping steps 1 and 2 are implied. They never are.
There’s a question hiding in this diagram, and it’s the one I now open every AI conversation with. Most teams walk in asking “where can we use AI?” The better question — the one that predicts whether the project ships — is “can our data support AI?” The first question generates a list of ideas. The second generates a plan.
“Clean Data” and “AI-Ready Data” Are Not the Same Thing
Here’s the distinction that changed how I scope these projects, and it comes straight from Gartner’s own framing: AI-ready data is data that is qualified for a specific use case — representative of the patterns, errors, outliers and edge cases that use case will meet. There is no way to make data “AI-ready in general,” or in advance. Readiness is relative to what you’re asking the AI to do.
That has a practical consequence most teams miss: passing your data-quality report does not mean you’re ready.
🔹 Your Account records can be 98% complete and still be useless to a service agent, because none of them carry the entitlement data the agent needs to answer “am I covered for this repair?”
🔹 Your Knowledge base can be immaculate and still ground a wrong answer, because half the articles describe a product version you retired and nothing marks which is current.
🔹 Your transcripts can be perfectly stored and still poison every downstream draft, because the vocabulary is wrong — which is exactly Vantage Media’s problem. No validation rule catches “Holden” when the truth is “Halden.”
So the first question isn’t “is our data clean?” It’s “what does this specific agent need to be right, and can it get that, correctly, every time?” Answer that and the scope of the foundation work becomes obvious and finite — which is the opposite of the open-ended “fix all our data” project everyone fears.
The Five Layers of a Data Foundation
This is the architecture I build toward, and the order matters — each layer only works if the one under it is real.
1️⃣ Ingestion — get the data reachable without copying it five times
Batch, stream, and increasingly zero-copy federation, where the AI queries data where it already lives instead of you building another pipeline and another stale replica. Every copy you create is a copy that can drift. I walked through a working cross-cloud example of this in Salesforce Data 360 × Google BigQuery.
2️⃣ Identity — one customer, resolved once
If the same company exists as three Accounts, your agent has three different truths and will pick one at random. Identity resolution isn’t glamorous, but it’s the single highest-leverage fix in most orgs. It’s also the layer that makes “give me the full picture of this customer” a sentence with an actual answer.
3️⃣ Quality and freshness — with a number, not a vibe
Quality means rules at the point of entry, monitoring after it, and an explicit freshness SLA per use case. A billing agent that reads a balance updated nightly is fine for a statement question and dangerous for a payment decision. Write the SLA down; it becomes a design constraint instead of an argument later.
4️⃣ Semantics — teach the system what your fields mean
Stage__c = 4 means nothing to a model. “Stage 4 = contract sent, awaiting signature” means everything. Field descriptions, help text, business glossaries, and a semantic layer with agreed metric definitions are what stop two agents from computing “active customer” two different ways. This is the layer companies skip most often and regret most quietly.
5️⃣ Access, lineage and retrievability — the part that makes it shippable
Retrieval has to respect permissions (the agent sees what the user may see, not everything), every answer needs a traceable source, and content has to be indexed in a form retrieval can actually find — chunked, embedded, and searchable by keyword and meaning.
Note where governance sits: around the stack, not bolted on at the end. On Salesforce this is largely inherited rather than invented — grounding runs with the requesting user’s permissions, so field-level security and sharing rules apply to what an agent can retrieve, and the Einstein Trust Layer sits between your data and the model. That’s a real architectural advantage, and it’s the same discipline I applied to securing Salesforce-hosted MCP servers.
“But Can’t AI Just Clean the Data?”
I get this question in almost every workshop, and it deserves a straight answer: partly, yes — and it changes the economics of the work, not the need for it.
🔹 Where AI genuinely helps. Fuzzy matching for duplicates, drafting field descriptions from usage patterns, classifying and tagging documents, extracting structure from PDFs, spotting anomalies in a column nobody was watching. Work that used to take an analyst a quarter can take a fortnight. Use it — I do.
🔹 Where it doesn’t help. AI cannot tell you which of two conflicting records is true. It cannot invent the entitlement data you never captured. It cannot decide who’s allowed to see what — that’s a business decision with legal consequences. And it cannot make an ungoverned pile of files safe to expose to a chat interface.
🔹 The trap. Using AI to clean data while AI is already in production on that data means you’re flying the plane and rebuilding the wing at the same time. Do the cleanup as a scoped, upstream project with a defined finish line, then ship the agent onto solid ground.
The economics matter here too. Fixing a data problem before deployment is a project. Fixing it after deployment is a project plus incident response plus a credibility rebuild with the users who stopped trusting the agent the second week. That trust, once lost, is the most expensive thing on the list — I’ve never seen a team win it back with a better prompt.
The Order of Operations I Recommend
Concretely, for a team standing at the start of this:
1️⃣ Pick one use case, not a platform. “Answer service questions about entitlements” — not “become an AI company.” Readiness is per use case, so a use case is what makes the work finite.
2️⃣ List exactly what that agent must read to be right. Usually 5–15 objects/fields and one or two document sets. That list is your foundation scope.
3️⃣ Measure those specific things. Fill rate, duplicate rate, staleness, ownership, permissions, retrievability. Numbers, not opinions.
4️⃣ Fix, then instrument. Repair the gaps, then add monitoring so they don’t reopen quietly.
5️⃣ Build the agent, with an eval set from day one. Thirty real questions with known-correct answers, run on every change. Without evals you’re not engineering, you’re hoping — a theme I hit hard in How to Give Your AI a Spine.
6️⃣ Then scale. Second use case, second slice of foundation. The second one is dramatically cheaper because layers 1–4 are already built.
The full sequencing, costs and governance model for a smaller organization is in The AI Enablement Playbook for SMBs, and the hands-on version of step 3 — the queries and checks I actually run — is in the companion post, The 30-Day Data Foundation Sprint.
Common Pitfalls
✔️ Boiling the ocean. “Fix all our data” has no end state and no budget owner. Scope to the use case and finish something.
✔️ Confusing a demo dataset with your data. Pilots run on curated samples; production runs on the mess. Demo on real, permissioned data as early as you safely can.
✔️ Skipping semantics. If the model doesn’t know what a field means, it will guess — fluently, and in front of a customer.
✔️ Treating permissions as a phase-two problem. Retrofitting access control to a shipped agent is the most common reason projects stall in review.
✔️ No freshness SLA. “Recent enough” is not a specification. Put a number on it per use case.
✔️ No eval set. If you can’t measure whether last week’s change made answers better or worse, you can’t improve — or defend — the system.
Conclusion
The uncomfortable truth is that the most valuable AI work is the least impressive-looking work. Nobody posts a screenshot of an identity resolution ruleset. But that ruleset is the reason the demo survives contact with production.
✔️ AI multiplies data debt, it doesn’t hide it — errors become confident, repeated, and automated.
✔️ The sequence is Data → Context → AI → Automation — skipping to step three is why pilots stall.
✔️ Ask “can our data support AI?” before “where can we use AI?” — the first question makes a list, the second makes a plan.
✔️ Clean is not AI-ready — readiness is judged per use case, never in general.
✔️ Five layers hold it up — ingestion, identity, quality and freshness, semantics, retrieval — with governance wrapped around them.
✔️ AI accelerates the cleanup, it doesn’t replace it — use it upstream, on a scoped project with a finish line.
✔️ Scope to one use case — that’s what turns an infinite data project into a shippable one.
✔️ The second agent is cheap — because the foundation is already paid for.
AI isn’t the foundation. Data is. If your AI outputs are impressive in the demo and unreliable in the real workflow, the model is almost never the problem — the ground underneath it is. And that’s exactly the kind of work I do.
Thinking about an agent, a copilot, or an AI workflow and not sure whether your data can carry it? Tell me what you want the AI to do and I’ll tell you what the foundation underneath it needs to look like.
What’s the worst thing bad data has made your AI say out loud? Tell me in the comments.
