A company can deploy the best AI model in the world. If the underlying customer data is wrong, outdated, or contradictory, the agent will not deliver reliable results either. Nowhere is this more evident than in the CRM.
An AI agent is expected to identify a customer, understand their history, take open cases into account, and then execute an appropriate action. For this, it needs more than intelligence. It needs context. And that context consists of data. This is precisely why the success of an Agentforce rollout is decided less by the choice of model than by whether the data can support the decisions the agent is supposed to make.
The CRM Becomes the Agent's Knowledge Base
Classic CRM systems were built for people. A sales representative opens a customer and sees contact details, opportunities, activities, cases, orders, and notes. What they do not find there, they fill in from experience: they know the account was renamed two years ago, that the contact person has changed, or that the duplicate record in the support tool actually belongs to the same company.
An agent cannot reliably fill in this missing context. It takes the data it finds and works with it. When information is spread across multiple systems or contradicts itself, there is a risk that the agent draws a wrong conclusion and acts on it. Data quality thus moves from a hygiene topic to a prerequisite for agentic CRM.
Salesforce is visibly responding to this shift. Data 360 is increasingly positioned as the data foundation for agentic applications. In parallel, Salesforce is expanding Headless 360 and exposing platform capabilities via APIs and MCP for authorised agents. Both developments point in the same direction: the CRM is no longer just read by humans, but used by agents as a knowledge base.
The Problem Starts With Customer Identity
Imagine a customer that exists in four systems:
| System | Name |
|---|---|
| CRM | Acme GmbH |
| Support system | ACME |
| ERP | Acme Gesellschaft m.b.H. |
| Marketing | Acme Austria |
For a person, it is probably immediately clear that this is the same company. For an automated process, this situation is considerably harder. This is exactly where entity resolution comes in: the system must recognise that these four records belong to the same entity.
Without this mapping, the agent works with an incomplete or even wrong customer context. It might see the open cases from the support system but not the contract status from the ERP. Or it answers a request based on the marketing profile, even though the relevant history lives in the CRM. The action is then technically successful and yet factually wrong.
An Agent Needs a Golden Record
The solution is not necessarily to copy all data into a single system. What matters more is a consistent identity. A so-called golden record defines which information counts as authoritative for an entity and how the local records in the individual systems relate to each other.
An example:
| Attribute | Value |
|---|---|
| Customer ID | 84721 |
| Company | Acme GmbH |
| ERP | Customer 103948 |
| CRM | Account 84721 |
| Support | Organization 5512 |
This gives the agent a stable point of reference. It does not have to decide on its own whether "ACME" and "Acme Austria" are the same company. That decision has already been made and is captured in a stable ID. This reduces the risk of the agent incorrectly merging information from multiple records or acting on the wrong one.
For agents, the rule should be: resolve the entity first, then act. The agent binds its actions to an unambiguous identity, not to the first hit a search returns.
More Data Does Not Automatically Mean Better AI
A common mistake goes: "Our agent needs as much data as possible." That is not necessarily true. More data can actually hurt. When an agent gets access to ten data sources, there are additional opportunities for contradictory information, outdated values, different definitions of the same term, permission problems, unnecessary context in the prompt, and higher cost per call.
The better question is therefore not "What data do we have?" but: What data does the agent need for this specific task?
A support agent might need current contract information, open tickets, the last communication, and order status. It probably does not need the customer's complete marketing history. Conversely, a sales agent needs opportunities, purchase history, and contacts, but not every single support ticket from the last three years.
This focus is not a renunciation of context. It is a decision about which context is relevant for which task. The tighter this scope, the fewer contradictions the agent has to resolve and the more traceable its behaviour becomes.
Structured and Unstructured Data
Agents also have to deal with different types of data. Structured data such as customer number, revenue, contract status, product, order number, or ticket status lives in clearly defined fields. Unstructured data such as emails, call notes, PDFs, support chats, and documents often contains the actual story behind those fields.
A helpful agent has to connect both worlds. An example: the CRM record shows that a customer has three open cases. The support notes explain that the customer has been waiting two weeks for a technical solution and has already followed up twice. Only the combination provides the full context. "Three open cases" becomes "a customer on the verge of escalation".
Connecting only the structured fields yields an agent that knows numbers but does not understand situations. Connecting only documents yields an agent that tells stories but has no stable reference to contract, status, and identity.
Data 360 as the Connecting Layer
Salesforce positions Data 360 precisely in this area. Data from various sources can be unified and made available for AI applications without every source having to be physically copied into Salesforce. Salesforce also points to partnerships and integrations with data platforms such as Databricks, through which existing data lakes and lakehouses can be connected.
For companies, this means an important change in how the topic is framed. Data integration is no longer just a reporting topic that ends in a dashboard. It becomes the foundation for agentic decisions. The question "Is our data clean enough for reporting?" turns into "Is our data clean enough for a system to be allowed to act on it?".
The Agent Should Not Access Data Blindly
Governance plays a central role here as well. An agent should not simply "see everything". Instead, the architecture should explicitly define:
- Which data is the agent allowed to see?
- Which fields are sensitive?
- Which data may be used for which task?
- Which actions is the agent allowed to trigger?
- Which data may leave the system?
This separation is particularly critical for customer data. A service agent checking order status does not need access to credit information. A marketing agent building segments should not read support escalations. These boundaries cannot be drawn afterwards via the prompt. They have to be anchored in permissions, data access, and tool approvals.
From Customer 360 to Agent 360
Customer 360 long had a clear goal: create a complete view of the customer. With AI agents, a new question emerges from this: can an agent use this complete view safely and meaningfully?
This is an important difference. A dashboard shows information to a person. The person evaluates it, adds context, and decides. An agent can act directly on the same information. Data quality thus becomes immediately operational.
When a dashboard shows a wrong value, it is annoying. When an agent executes an action based on a wrong value, it can turn into a business problem.
The difference lies in the consequence. A wrong value in reporting might cost a discussion in a meeting. A wrong value on which an agent sends a quote, renews a contract, or flags a customer as a churn risk costs trust.
What Companies Should Check Before an Agentforce Rollout
Before an agent works on customer data in production, seven questions should be answered:
| Area | Guiding question |
|---|---|
| Customer data | Are accounts and contacts unambiguous, or do duplicates exist? |
| Identities | Are there stable IDs across systems? |
| Data quality | What share of the data is outdated or incomplete? |
| Data lineage | Where does a piece of information come from, and which system is authoritative? |
| Permissions | Which data may the agent use for which task? |
| Freshness | How current must a piece of information be for the respective decision? |
| Actions | Which changes may the agent make, and where must a human be involved? |
These questions do not have to be answered for the entire data estate at once. It makes more sense to start with the specific use case: which entities does the agent actually touch, which fields does it use for decisions, and which actions may it trigger? For this subset, the answers should be in place before the rollout.
The Model Is Only Part of the Solution
The discussion around AI agents frequently centres on models. Which model is faster? Which is cheaper? Which reasons better? For enterprise applications these questions matter, but they describe only part of the solution.
A better representation would be:
Agent Quality = Model + Context + Data Quality + Tools + Governance
If one of these factors is missing, the reliability of the overall system drops. A strong model with contradictory context delivers confident but wrong answers. A clean data set without suitable tools remains knowledge without the ability to act. And an agent without governance can work correctly and still use data it should not be using.
This is why Salesforce makes it especially clear: a company's most important competitive advantage may not be the newest model. It is the quality of its customer context.
Conclusion
AI agents change the role of CRM data. It is no longer just information an employee looks at in the Salesforce interface. It becomes context on which a system prepares decisions and executes actions. This raises the importance of data quality, entity resolution, Customer 360, identity, and governance.
That is exactly why, before asking "Which AI agent do we want to deploy?", a company should first answer a different question: "Can our data even support the decisions this agent is supposed to make?"
Because an intelligent agent with bad data remains a bad agent. A well-integrated agent with reliable context, on the other hand, can actually become a productive part of the company. Salesforce is currently building its platform in exactly this direction, including through Data 360, Headless 360, and MCP-based access for authorised agents. Whether these building blocks hold up in your own company, however, is not decided in the platform. It is decided in the data.