Agentforce inherits every piece of technical debt in your Salesforce org. Before you build a single agent, audit your data quality, fix identity resolution, clean your metadata, and establish governance. The orgs succeeding with AI agents in 2026 are the ones that treated data readiness as Phase 1, not Phase 2.
In This Article
Here is a scenario that plays out more often than anyone in the Salesforce ecosystem wants to admit. A company spends three months configuring Agentforce. They build topics, write instructions, map actions to Apex classes. The demo looks incredible. Then they deploy to production, and within 48 hours the agent is recommending products the company discontinued two years ago, quoting pricing from a picklist value that should have been retired in 2023, and creating duplicate leads because [email protected], John D., and Customer #4521 are all the same person but nobody told the system that.
This is not an Agentforce problem. This is a data problem that Agentforce made visible.
A recent AI security report found that 64% of billion-dollar enterprises lost more than $1 million in the past year due to AI agent failures. Not from dramatic system crashes, but from the quiet accumulation of small errors at machine speed. An agent with excessive access modifying thousands of records. An automation loop triggered by inconsistent picklist values. API call volumes spiking because the agent kept retrying against bad data.
Agentforce inherits all your org’s technical debt. Every governor limit issue, every permission gap, every automation conflict that has been quietly lurking in your Salesforce instance for years, Agentforce will find it. Humans are slow enough to work around bad data. Agents are not.
The orgs that stumble with Agentforce are not the ones lacking AI skills. They are the ones that have been accumulating automation sprawl, permission creep, and data quality issues for years. The agent just turned the volume up.
When someone says “data readiness” in the context of AI, most teams hear “deduplicate your contacts.” That is maybe 20% of the work. Agent-grade data readiness is an architectural concern, not a data hygiene task.
Think of it this way: a human rep can look at a messy Account record, squint at it, check Slack, ask a colleague, and still close the deal. An agent cannot squint. It reads the data literally, acts on it immediately, and scales that action across every record it touches.
Duplicates, missing fields, stale records, inconsistent picklist values. The basics, but most orgs fail here. “Prospect” vs “Prospective” vs “Prospecting” should be one value.
Can your system reliably tell that two records are the same person or business? Without this, agents create duplicates at scale or miss context entirely.
Contacts linked to the right Accounts. Opportunities attached to the correct Contacts. Agents pull from multiple objects, and broken links mean blind spots.
Field definitions, automation logic, and object relationships must be consistent. If ARR is defined differently across objects, the agent’s reasoning drifts.
Permission structures, data sensitivity classifications, and consent records. An agent should be treated like an integration user, not a human, with least-privilege access.
If your agent uses Knowledge articles, those articles need to be current, correctly tagged, and mapped to the right data categories. Stale docs produce stale answers.
Most teams nail Layer 1 (eventually) and skip straight to building agent topics. Layers 4 and 5 are where the expensive failures hide. When metadata drifts, the agent’s world model drifts with it. The LLM isn’t confused. It is reasoning against a version of your org that no longer exists.
Salesforce renamed Data Cloud to Data 360 at Dreamforce 2025, and it was not just a branding exercise. This was a repositioning: from a marketing-focused CDP to the foundational data layer for the entire Agentforce platform. Every AI agent in the Salesforce stack now depends on Data 360 for context. Without it, agents operate with partial information. With it, they can access unified customer profiles, unstructured documents, and real time signals from across the enterprise.
The numbers tell the story. In Q3 of fiscal year 2026, Data 360 ingested 32 trillion records, up 119% year over year. Zero-copy records grew 341%. Unstructured data processing jumped 390%. This is not incremental growth. This is an entirely new data architecture becoming central to how Salesforce works.
What’s Actually New in Data 360
Processes PDFs, contracts, manuals, and transcripts through a low-code pipeline: chunking, embedding, vectorizing, and storing in a searchable knowledge graph. Agents can now surface answers from documents, not just database records.
Query data directly where it lives: Snowflake, BigQuery, Databricks, Redshift. No duplication, no ETL pipelines. But be aware: while Data 360 doesn’t charge for storage, the connected platform may charge for compute.
Translates data into business language and enforces consistent metric definitions across the Customer 360 Semantic Data Model. When your VP of Sales says “revenue,” every agent and dashboard means the same thing.
Configure and manage your entire Data 360 pipeline with plain language instructions. This lowers the barrier for admins, but the underlying architecture decisions still require someone who understands data modeling.
Data 360 is not plug-and-play. The consumption-based pricing model means every event streamed, every identity resolved, and every segment activated adds to your bill. Real-time streaming is great for personalization but expensive at scale. Batch ingestion is cheaper but introduces latency. Architecture decisions here have direct cost implications that most teams don’t model until the invoice arrives.
The FedEx case study is instructive. They harmonized 266 million fragmented profiles from 650+ data streams into 141 million unique individuals, achieved a 13% boost in customer activation, and reported a 2,000% ROI. But FedEx also had the data engineering resources to do it properly. Most mid-market orgs will need to start smaller and build incrementally.
The biggest mistake I see teams make is treating data readiness as a one-time cleanup project. “We’ll clean the data, then we’ll build the agents.” That framing is wrong. Data readiness is ongoing, and trying to clean everything before you start means you never start.
Here is a 90-day playbook that balances speed with thoroughness. It assumes you have at least one Salesforce admin, one architect (or senior admin who thinks architecturally), and executive sponsorship.
Even with solid data readiness, you will hit issues. Here is what to expect.
- Rules that assume human context (“Phone required when Source = Web”) fail silently when agents create records
- Agents may retry with the same bad data or give up entirely
- The customer sees “Something went wrong” instead of a useful response
- Fix: Audit every validation rule against agent actions before deployment
- Agents process faster than humans, which means they hit the 10-second CPU timeout more frequently
- Complex trigger logic + external service callouts in synchronous context are the usual culprits
- Bulkification matters more than ever when agents process records at scale
- Fix: Profile CPU usage for agent actions in sandbox before go-live
The Uncomfortable Truth About Data 360 Costs
Data 360’s consumption-based pricing catches teams off guard. Ingesting from Salesforce Clouds is free. External sources are not. Real-time streaming adds to your usage bill with every event. And here is the subtle one: Zero-Copy Federation means Data 360 doesn’t charge for storage, but the connected platform (Snowflake, BigQuery) will charge for compute when you query through it. You are shifting costs, not eliminating them.
Poor schema design in Data 360 leads to bloated profiles and inefficient queries, which drives up consumption. Identity resolution that is too loose creates noise. Too strict and you miss connections. Both cost you money, one in wasted compute and the other in missed opportunities.
As of early 2026, data masking is disabled for Agentforce to preserve contextual accuracy in planner and action workflows. Salesforce mitigates this by running all Claude-based models within their virtual private cloud. But this means your permission structure and field-level security are doing more heavy lifting than before. Get them right.
The companies I see succeeding with Agentforce in 2026 share a common trait: they treated data readiness as the project, not as a prerequisite to the project. They did not wait for perfect data. They scoped their first agent use case narrowly, cleaned the data that specific use case required, deployed, learned, and expanded.
Salesforce’s own acquisition strategy tells you where this is headed. The Informatica deal, at roughly $8 billion, was the clearest signal that data quality is the bottleneck. The Momentum acquisition fills the gap of unstructured call data that never made it into CRM fields. The Doti AI acquisition addresses enterprise search across disconnected systems. Marc Benioff called data “the true fuel of Agentforce.” These purchases are Salesforce backing that claim with real money.
For enterprise architects evaluating Agentforce right now, the question is not “should we build agents?” The question is: “If our best agent had access to our current data, would we trust the actions it takes?”
If the answer is no, you know where to start.