TL;DR — An autonomous agent is only as good as the data layer it reads at the moment it acts. A packaged, CRM-native CDP hands it a stale, partial copy. A warehouse-native one hands it the live, complete record. The agent isn’t the variable — the data architecture is.

Agentforce didn’t miss on AI. It missed on data.

When Salesforce launched Agentforce in 2024, Marc Benioff said the company was “all in,” and pitched autonomous agents as the next evolution of enterprise software — software that would handle service, sales and marketing tasks on its own. Eighteen months later the market has repriced that bet hard: shares down more than 50% from their December 2024 peak, over $200 billion in value erased, and a rare same-day double downgrade from KeyBanc and Bernstein.

Read the analysts’ actual reasoning and it isn’t a story about AI being oversold. KeyBanc’s team, led by Jackson Ader, put it bluntly: “customers’ data is not in order to do meaningful AI work.” Their CIO survey found more organizations planning to deprioritize Salesforce over the next year than to expand it, and most Agentforce deployments still stuck in proof-of-concept. Customers weren’t rejecting agents. They were discovering they couldn’t feed them.

That is the entire argument here. An agentic CDP — a customer data platform that autonomous agents read from and act on — lives or dies on the customer data infrastructure beneath it, not on the cleverness of the agent. And the two dominant CDP architectures, packaged CRM-native and warehouse-native, hand an agent very different data. One of them is why Agentforce stalled.

One insurance renewal an agent gets wrong

Make it concrete. Take a single policyholder at a multi-line carrier: mid-tenure, one auto policy and one home policy, three weeks from auto renewal. A retention agent — autonomous, or copiloting a rep — has one decision to make: hold the price, offer a loyalty discount, or flag the account for manual review.

To make that call correctly, here is what the agent needs to see, and where it actually lives inside a real carrier:

• Current coverages and renewal premium — the policy admin system (Guidewire PolicyCenter or Duck Creek)
• A claim filed this morning — the claims system (Guidewire ClaimCenter)
• A premium payment that bounced yesterday — billing (BillingCenter, or a mainframe)
• Usage-based driving score — the telematics platform
• A competitor quote pulled an hour ago — the rating engine plus web analytics
• Whether they also hold the home policy (the household view) — identity resolution across all of the above
• Consent to use telematics data and to contact by channel — the preference store
• A prior complaint escalation — Service Cloud, the CRM

The CRM natively owns exactly one row of that: the complaint. Every signal that actually determines the right offer sits in a system Salesforce doesn’t own.

Now run it through a CRM-native CDP. To give the agent a unified profile, you replicate PolicyCenter, ClaimCenter, billing, telematics and rating into Data Cloud and reconcile identity there — because the same human is policy_no in the policy system, claimant_id in claims, account_id in billing, a VIN/device id in telematics, and contact_id in the CRM. That reconciliation runs on a copy, on a sync schedule. So the failure is mechanical, not vague. Claims sync overnight; the bounced payment posts in a batch; the competitor quote sits in a web tool that lands tomorrow. At 10am the agent reads its copy, sees a loyal multi-year customer with a clean history, and offers a retention discount — to someone who filed a total-loss claim at 8am and missed a payment yesterday, the two loudest churn-and-risk signals in insurance. It didn’t make a dumb decision. It made a correct decision on a stale world. (Figures illustrative.)

This is also the “we spent as much time preparing data as using the AI” complaint from the reporting, stated mechanically: to make that agent safe you first pipe six core systems into the vendor’s store and keep them reconciled and fresh forever. The data-prep tax never ends, because the copy is always drifting from the source.

Now run the same customer through a warehouse-native CDP. At most large carriers, PolicyCenter, ClaimCenter, billing, telematics and web already land in the warehouse — Snowflake, BigQuery or Databricks — because that’s where actuarial and pricing already run. It is the one place the complete customer already exists. Identity resolution builds the household graph there, across every source. The signals the agent needs — claim_filed_last_24h, payment_failed_flag, competitor_quote_last_7d, telematics_risk, holds_multiline — are computed in place and kept current. The agent queries that as source of truth. Same customer, same 10am decision: it sees the 8am claim and the bounced payment and routes to manual review instead of discounting a fraud-or-flight risk. Nothing was re-ingested, because the warehouse is the store, not a copy of it.

The difference isn’t a better agent. It’s the same agent, reading a data layer that is complete and current instead of partial and stale.

An agent fails on the data it can see, not on how smart it is

That renewal isn’t a special case — it’s the general rule in miniature. Strip away the model and an autonomous agent is a decision loop: read the current state of the customer, pick an action, take it. Every weakness in that loop traces back to what the agent could see when it read. Four properties decide that — and all four belong to the data layer, not the agent.

• Resolved identity. The agent has to know that these events, this policy, that complaint and this web session are one person — before it acts, not after. If identity is ambiguous, the agent acts on a fragment.
• Freshness at query time. The agent needs the state as it is now, not as it was at last night’s sync. An action taken on a twelve-hour-old copy is an action taken on a customer who may no longer exist in that state.
• Completeness. The agent needs the whole record — every system that holds a signal — not just the slice the CRM happens to own. A signal the agent can’t see is a signal it will act against.
• Consent, attached. The agent needs to know what it may use and how it may reach the person, carried with the data — or it will do something that is compliant on paper and wrong in practice.

None of these is a model capability. You cannot prompt your way to data you never loaded, resolve an identity you never stitched, or freshen a copy that syncs nightly. This is why “the agent isn’t smart enough” is usually a misdiagnosis. The agent is exactly as smart as its inputs, and the inputs are an architecture decision made long before the agent arrived.

The tell: Salesforce bought Informatica to fix the data layer first

If the data layer weren’t the real problem, Salesforce’s own spending wouldn’t say it is. The company that sold “just deploy agents” has spent this year buying its way into the plumbing — technology that automatically pulls customer data from external sources, and the acquisition of Informatica for data integration and governance — explicitly to get customers’ data in order before they deploy agents. That is the vendor conceding the sequence: foundation first, agent second. When the company with the most to gain from “the agent is ready” instead spends billions on data integration, the diagnosis is settled.

Here is the honest part, because the architecture doesn’t win every case. If you’re a monoline carrier — one line of business, one policy system tightly wired to the CRM, identity already clean and centralized — a CRM-native CDP may genuinely hold a complete-enough, fresh-enough profile, and a CRM-native agent will work fine. The structural failure isn’t universal. It bites when the customer truly lives across many systems: multi-line carriers, banks, telcos, retailers with separate commerce, loyalty and support stacks. That is most of the enterprise market — and it’s exactly the buyer typing “agentic CDP” into a search bar.

Agent-ready is a data question. Here’s the test.

The Agentforce story gets read as a verdict on agentic AI. It’s better read as a verdict on data readiness. Agents didn’t underdeliver because the models are weak; they underdelivered because most enterprises pointed them at a data layer that couldn’t answer in time or in full. The lesson isn’t “wait for better agents.” It’s “fix what the agent reads.”

So before you buy or build an agentic CDP, run a four-question test on your own stack, for each signal that matters. Is identity resolved across systems, or stitched per tool? Is the state fresh at the moment of the query, or synced on a schedule? Is the record complete, or just the slice the CRM owns? Is consent attached to the data, or sitting in a separate system the agent never checks? If the honest answer to any of these is “synced nightly into the CRM,” your agent isn’t ready — and the thing that isn’t ready is the data layer, not the agent.

Map your signals before you buy an agent

If you’re weighing an agentic CDP, start by finding where your customer signals stall before an agent ever reads them — which system each one lives in, and how stale it has gone by the time it lands. Our customer data ingestion diagnostic walks that assessment, so you can see what an agent would actually be acting on.

Frequently Asked Questions

What is an agentic CDP?

An agentic CDP is a customer data platform built for autonomous AI agents to read from and act on directly, rather than for humans to build segments in. The distinguishing requirement isn’t the agent — it’s a data layer that can serve one resolved, current, consent-aware profile at query time, because that’s what an agent needs to take an action safely.

Do I need a CDP to run AI agents in marketing?

You need a unified, current data layer; whether it’s branded a “CDP” matters less than whether it resolves identity, stays fresh, and carries consent. Many teams already have most of that in a warehouse and don’t need a separate packaged CDP to feed agents. The real failure mode is deploying agents against fragmented source systems with no unification at all.

Why has Agentforce adoption been slow?

Per KeyBanc, two reasons: data readiness and product maturity. Enterprises struggled to give agents clean, connected data — “customers’ data is not in order to do meaningful AI work” — and many deployments never left proof-of-concept. The bottleneck was the data foundation more than the agent itself.

Can a packaged, CRM-native CDP support autonomous agents?

It can, when the customer genuinely lives inside the CRM and identity is already clean and centralized. It struggles when signals are spread across systems the CRM doesn’t own, because it must copy and reconcile them on a sync schedule — leaving agents acting on stale, partial profiles. The more systems hold customer signals, the worse the fit.

What makes customer data “agent-ready”?

Four properties: identity resolved across all source systems, freshness at query time rather than by batch, completeness across every system that holds a signal, and consent attached to the data itself. Agent-readiness is a property of the data architecture, not of the model.

Warehouse-native or CRM-native for real-time agents?

Choose warehouse-native when signals live across many systems and agents must act on current state — the warehouse already holds the complete record, so agents query in place instead of waiting on syncs. Choose CRM-native when the CRM is genuinely the system of record for the whole customer and low-latency cross-system freshness isn’t required. The deciding question is how many systems hold the signals your agent must act on, and how fresh they must be.