Why Agentforce Adoption Is Stalling: The Data Readiness Problem Nobody Budgeted For

The demo was flawless. The agent answered every question the steering committee threw at it, grounded on a demo org full of tidy sample records, and the VP who owned the budget left the call sold. Six weeks later that same agent is running against production data, and it has just told a customer their contract renewed in March 2024 and quoted a support tier your company retired last summer.

The agent did not get dumber between the demo and the pilot. It started reading your actual org.

That gap, between what Agentforce does with curated data and what it does with the data enterprises actually have, stopped being a practitioner complaint this month. It became a Wall Street thesis.

The week the analysts said the quiet part out loud

On July 9, KeyBanc Capital Markets downgraded Salesforce from Overweight to Sector Weight. Bernstein cut its rating to Sector Weight the same day. The stock fell more than 4% in premarket trading, to around $159 from a $166.58 close, leaving CRM down roughly 37% for the year at that point.

The KeyBanc note, from analyst Jackson Ader, is the one to sit with, because it is not really a valuation argument. Ader wrote there is "little to no evidence, other than the valuation multiple, that the stock lends itself to a bullish recommendation." His research surfaced two findings that anyone who has scoped an Agentforce pilot will recognize on sight: customer data "isn't organized enough" for meaningful AI work, and Agentforce "just isn't there" as a product yet, with partners only beginning to convert proof-of-concept work into real pipeline deals.

Bernstein brought a CIO survey. More CIOs plan to deprioritize or trim Salesforce spend over the next 12 months than plan to increase it, which made Salesforce, in Bernstein's words, "a standout for the wrong reasons." Bernstein also flagged that it had trouble finding evidence in Salesforce's financial filings that net-new average order value is growing faster than overall AOV, which cuts against the growth narrative management has been telling.

To be clear, this is not a finance site, and nothing here is a reason to touch your brokerage account. The downgrades matter for a different reason. Two analyst teams independently researched why Agentforce deals stall, and both landed on the diagnosis most architects reached quietly a year ago. The product demos beautifully, and then it meets the org's data.

Salesforce's own research sides with the bears

Here is the detail that should end the "the AI just needs another release cycle" debate inside your steering committee.

Salesforce published its 2026 State of Data and Analytics report on its own newsroom. In it, data and analytics leaders estimate that 26% of their organizational data is untrustworthy. A full 84% say their data strategies need a complete overhaul before their AI ambitions can succeed. 67% feel pressure to implement AI quickly anyway. 42% lack full confidence in the accuracy and relevance of their AI outputs, and nearly 9 out of 10 organizations already running AI in production have seen inaccurate or misleading outputs.

Read that sequence the way a CIO reads it. Leaders know a quarter of their data cannot be trusted. They know the strategy underneath their AI program needs rebuilding, and they are shipping anyway because speed pressure is winning. The company selling the agents is the one publishing this.

Gartner put a number on where that ends. Its February 2025 research forecast that through 2026, organizations will abandon 60% of AI projects that are unsupported by AI-ready data. The same research found 63% of organizations either lack the right data management practices for AI or are unsure whether they have them.

So the sell-side analysts, Gartner, and Salesforce's own research team are describing one failure mode from three angles. The useful question for you is no longer whether Agentforce works. It is whether your org is one of the ones where it can.

What an agent actually reads

"Data readiness" sounds like a kickoff-deck phrase, so make it mechanical.

An Agentforce agent is a reasoning loop wrapped around an LLM. When a request comes in, the agent retrieves context from its grounding sources: CRM records visible to its running user, Knowledge articles, prompt template merge fields, and, if you have wired it, harmonized objects in Data Cloud. The Einstein Trust Layer sits in the middle, masking sensitive values and logging the exchange. Then the model reasons over whatever came back.

Notice what is missing from that pipeline: any judgment about whether the retrieved data is good. Retrieval treats your org as truth. If Renewal_Risk__c was last updated in 2024, that number goes into the prompt with the same authority as a field updated an hour ago. If three account records exist for the same customer, retrieval hands the model whichever ones match, and the model does its confident best with a contradiction it has no way to detect.

Salesforce knows this, which is why so much of the Summer '26 release messaging is about grounding agents in trustworthy context, from the Agentforce Trust Layer to Tableau and Data Cloud grounding for accurate answers. When a vendor spends a release cycle talking about trust and grounding, it is telling you where its deployments have been bleeding.

Here is the arc that plays out when nobody checks the inputs first, and it deserves a close look because every stage feels like success until stage four.

The cruel part is the asymmetry. A flow that fails throws an error a user can screenshot. An agent grounded on bad data fails in fluent English, and a user who catches it once starts double-checking everything the agent says. Users who double-check everything soon stop using the agent, because double-checking is slower than doing the work themselves. The pilot does not fail loudly. It quietly stops getting used, and the product takes the blame in the retro.

The audit to run before you blame the agent

Everything below is checkable with tools you already have: reports, SOQL, Setup, and one honest afternoon. Scope it to the objects, articles, and Data Cloud objects your pilot actually touches, not the whole org.

Duplicate records. Run your matching rules against the pilot's primary objects and read the duplicate record sets report. If the same customer exists as three accounts, the agent grounds on whichever ones retrieval returns, and it may summarize them as if they were three customers. Decide the survivor record, merge or link the rest, and switch duplicate rules on so the problem stops regrowing. An agent cannot pick your source of truth for you.

Stale fields. List every field the agent's topics, actions, and prompt templates read, then check how old the values actually are. A report grouped by LastModifiedDate, or a quick SOQL pass, will surface fields that stopped being maintained years ago. Stale fields are worse than empty ones. An empty field gets skipped; a stale one gets quoted. If a field is no longer maintained, either fix the process that should maintain it or cut it from the agent's grounding entirely.

Ungoverned custom objects. Fifteen years of admins leave sediment. Custom objects nobody owns, picklist values the business retired but the metadata kept, two fields on different objects holding the same fact and disagreeing. You will notice this the first time the agent cites the wrong one of the two, because it has no way to know which field was abandoned in 2023. Before the pilot, assign an owner to every object in scope and pick one authoritative field per fact. Data quality work is unglamorous, which is exactly why it never got budget until an agent started reading the results aloud to customers.

Knowledge article currency. Service agents lean on Knowledge harder than any other grounding source, and Knowledge bases age badly. An article describing your 2023 refund policy is not history to an agent. It is an answer. Filter the articles in the pilot's scope by last published date, archive what is dead, and rewrite what is merely old. If two articles contradict each other, the agent will alternate between them, and users will file that as "the AI is inconsistent."

Data 360 unification coverage. If the pilot grounds on Data Cloud, check how much of your customer base identity resolution has actually unified. Match rules that reconcile only 60% of profiles give the agent two brains: unified answers for some customers, fragmented ones for the rest, with no visible difference in confidence. The Data 360 implementation guide covers the mechanics. The audit question is simpler: what share of the pilot's customers resolve to a single unified profile today?

The running user's visibility. This is the silent one. The agent sees the org through its running user: permission sets, object permissions, field-level security, sharing rules. Scope that user too wide and you have a compliance problem. Scope it too narrow and you get something sneakier, an agent that answers from the subset it can see and presents partial data as complete. Nobody gets an error. Log in as the running user, or run a permission analysis, and verify the agent can see everything the use case needs and nothing beyond it.

That is the whole audit, and none of it requires buying anything. Condensed into a checklist you can pin next to the pilot plan, it looks like this.

During the rollout, treat data quality as a live metric

The audit gets you to launch. Staying healthy is a separate discipline.

Test against your ugliest records, not your cleanest. Agentforce Testing Center lets you run scenario batteries before anything touches production, so build those scenarios from the records your audit flagged: the account that just survived a merge, the customer whose policy article was rewritten last week. An agent that holds up against your messiest data will handle the median fine. The reverse is not true.

Then instrument the triage. When the agent gets something wrong during the pilot, log whether the cause was reasoning or inputs. You will find the split runs heavily toward inputs, and that number is politically useful. It redirects the "the AI does not work" conversation toward the specific fields and articles that need owners. The Einstein Trust Layer audit trail gives you the raw material to reconstruct what the agent saw. Read it weekly instead of treating it as a checkbox you enabled once.

And hold scope until the data earns it. The Well-Architected guidance for Agentforce points the same direction: widen an agent's authority only as fast as you can verify its inputs. That goes double for triggered agents, which act on data-driven signals with no human reading the output first. A chat agent grounded on a stale field embarrasses you. A triggered agent grounded on one reassigns accounts.

Put the two ends of this side by side and the pattern is hard to unsee.

Same model. Same license cost. The org on the left concluded Agentforce is overhyped. The org on the right is quietly expanding seats. The analysts downgraded the stock because too many customers are still the org on the left, and Salesforce's own research explains why. You do not control any of that. The state of your org, you do.

What to do with this before your next scoping call

Pick the single process your Agentforce pilot targets, or would target if one gets approved. Spend one afternoon running the audit above against only the objects, articles, and permission sets that process touches. Write down four numbers: the duplicate rate on the primary object, the percentage of grounded fields updated in the last six months, the percentage of in-scope Knowledge articles reviewed this year, and unification coverage if Data Cloud is involved.

That one-pager changes the conversation. If the numbers are good, you scope the pilot with earned confidence instead of vendor optimism. If they are bad, you just found the real project, and you found it for the cost of an afternoon instead of a stalled proof of concept and a burned quarter of user trust. Either way, you now know something the steering committee does not: whether the agent was ever going to have a chance.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.