When an AI agent updates a customer, assigns an order, or prepares a decision, one question is critical: Does the agent really know which entity it's dealing with?
In many companies, the answer is: probably not. A customer exists in the CRM, the ERP, the support tool, and possibly a marketing platform as well. Names vary slightly, addresses are maintained differently, email addresses change, old accounts linger, and new records are created with every system migration. For humans, this mess is often manageable because they understand context and can ask when in doubt. An agent takes the record it finds — and acts on it.
That's exactly where the difference between data access and entity understanding lies. An agent can technically reach all relevant systems and still act on the wrong record. What was a master data problem becomes a wrong action: the wrong customer gets updated, an order is assigned to the wrong account, or a decision is based on an incomplete partial profile. And if the architecture doesn't allow for clarification or escalation, the agent simply executes the action.
Why master data becomes more critical with agents
Master data was important before AI agents too. Customers, products, suppliers, locations, and contracts always needed to be maintained properly. The difference lies in what an agent does with this data.
A reporting dashboard can surface a duplicate customer. A human might notice the anomaly and correct it. An agent, on the other hand, can trigger a follow-up action based on that duplicate. It generates a response, updates a field, starts a workflow, or forwards a request. If the underlying entity was resolved incorrectly, the error becomes operational.
Agents amplify this problem because they merge context from multiple systems. They read customer data from the CRM, payment information from the ERP, past tickets from the support system, and campaign data from the marketing tool. When these systems contain different versions of the same entity, it must be clear which view is authoritative for the agent.
This isn't primarily an integration problem. It's something more specific: the question of whether an agent recognizes the right entity before it acts.
Golden Record instead of random matches
A Golden Record is the consolidated, business-leading view of an entity. It doesn't simply describe the technically newest record — it represents the most trustworthy merge of relevant information. For a customer, this might mean: the customer number comes from the ERP, the preferred email address from the CRM, the current support status from the ticketing system, and the communication consent from the consent management platform.
For AI agents, this Golden Record is crucial because it prevents the agent from working with a random partial profile. When an agent processes a customer request, it shouldn't have to deduce which of three contradictory records is probably correct. It should access a resolved view that already establishes which entity is meant and which attributes are authoritative from which system.
This doesn't mean every organization needs to immediately launch a full master data management program for all data objects. For agents, a pragmatic start is often enough: Which entities are critical for the specific use case? For a service agent, that's usually customers, contracts, orders, and tickets. For a procurement agent, it's more likely suppliers, products, contracts, and locations.
What matters is that the agent doesn't work against raw, contradictory system data, but against a business-resolved view.
Entity Resolution: How systems recognize what belongs together
Entity Resolution describes the process of assigning records from different sources to the same real-world entity. In practice, this is rarely trivial. Two customers can share the same name. A company can use multiple locations. A person can have different email addresses. A supplier might be spelled differently in the ERP than in the CRM.
Matching can be deterministic or probabilistic. Deterministic matching works with clear rules: same customer number, same tax ID, same contract number. When the key is stable and unique, this method is strong. But in many grown system landscapes, such keys are missing or aren't used consistently everywhere.
Probabilistic matching evaluates similarities. Name, address, phone number, email, date of birth, or company identifier are combined to calculate the probability that two records belong together. This is more flexible but less definitive. That's why match scores and clear rules for what happens in case of uncertainty are essential.
For AI agents, this point is central. An agent shouldn't guess when the entity is uncertain. If the match score is low or multiple possible hits are similarly probable, the agent should stop, ask for clarification, or escalate to a human. Uncertainty about the entity must not lead to automated action.
Stable entity IDs as anchors
The most important technical anchor for agents is a stable entity ID. It connects the resolved entity across systems. Without such an ID, every system call remains vulnerable to ambiguity.
A stable customer ID doesn't necessarily mean all systems must use the same internal ID. In practice, there can be a central master ID that maps to local IDs in CRM, ERP, support, and marketing. What matters is that the agent works with this resolved master ID and doesn't have to decide anew each time which raw record is meant.
In practice, this point often determines whether an action is only technically successful or also business-correct. When an agent updates a customer status, it should be clear whether that update affects the Golden Record, a local CRM record, or an outdated duplicate. Without a stable ID, a technically successful action can be factually wrong.
For agentic systems, the rule should be: resolve the entity first, then act. The agent should bind its actions to a unique entity, not to the first record that appears in a search.
System of Record: Who owns which attribute?
A Golden Record isn't created by having one system that's always right by default. In many organizations, different systems are authoritative for different attributes. The ERP may govern invoice status and customer number, the CRM may own account ownership and relationship history, the consent system manages communication permissions, and the support tool tracks current escalations.
For agents, this ownership must be explicit. If an agent needs to decide whether a customer can be contacted, finding an email address in the CRM isn't enough. It needs to know whether the communication consent is current and which system it comes from. If an agent uses a shipping address, it must be clear whether that address is authoritative from the customer profile, the specific order, or a separate shipping process.
These rules are often called survivorship rules. They define which attribute from which source takes precedence when multiple systems deliver different values. Without such rules, an agent can either ignore contradictory data, combine it incorrectly, or rely on the wrong source.
For humans, these differences are often experiential knowledge. For agents, they must be mapped systematically.
Confidence scores and stopping at uncertainty
Entity Resolution shouldn't just deliver a match — it should also express how confident that match is. A match with 99 percent confidence is treated differently than one at 72 percent. For humans, a low confidence score might be a cue to look more carefully. For agents, it must translate into a clear action rule.
For critical actions, an agent should only work with resolved entities above a defined threshold. Below that threshold, it shouldn't automatically update, trigger, or decide. Instead, it can ask for clarification, generate a review, or hand the case off to a human.
This isn't a general human-in-the-loop topic — it's a specific rule for entity resolution. The agent doesn't stop because the entire process is uncertain, but because the entity assignment isn't reliable enough.
A simple pattern might look like this:
| Match Situation | Agent Behavior |
|---|---|
| Unique ID present | Action may proceed within defined scope |
| High match score | Action possible if no additional risk signals |
| Medium match score | Clarification or human review |
| Multiple similar matches | No automatic action |
| No reliable match | Create new case, but don't update any entity |
These thresholds must be defined per use case. A marketing segmentation can tolerate different boundaries than a payment approval or a contract change.
A DACH example: The triple customer
A typical DACH scenario: A B2B customer exists three times. In the CRM as Müller Maschinenbau GmbH, in the ERP as Mueller Maschinenbau GmbH & Co KG, in the support tool as Müller MB. The address differs slightly across two systems, the central email address was changed a year ago, and an old customer number still circulates through historical tickets.
An AI agent is supposed to summarize a support request and update the account status. It finds three matches. One has the current support tickets, another has the correct payment status, the third is linked to the right account manager in the CRM. Three partial profiles, three different truths. If the agent acts on any one of them, the action can be formally successful — and factually wrong.
The solution isn't to give the agent more system access. It needs a resolved entity. The Golden Record connects the three local records through a stable master ID, defines authoritative attributes, and flags uncertain or contradictory fields. The agent then works against this resolved view. If the assignment is uncertain, it doesn't update any record — it generates a review case.
This turns a diffuse master data problem into a controllable rule: no automatic action without reliable entity resolution.
A pragmatic starting point for organizations
Getting started doesn't require a comprehensive MDM program for all data objects. A use-case-oriented approach makes more sense. Companies should first identify the entities that an agent actually acts on. For a customer service agent, that's likely customer, contract, order, and ticket. For a finance agent, it might be supplier, invoice, cost center, and approval process.
Next, clarify which system is authoritative for which attributes. Not every field needs a perfect rule immediately. The critical ones are the attributes the agent uses for decisions or actions. That's exactly where you need source-of-truth rules, matching logic, confidence thresholds, and clear stops at uncertainty.
It's also important to establish stable IDs. If the agent uses an entity across multiple systems, that connection shouldn't be made via name, email address, or fuzzy search. A master ID or reliable mapping is significantly more robust.
The last step is connecting the agent to the resolved view. It should ideally not work directly against raw duplicates, but against a service, a view, or a data product that already includes entity resolution.
The real lesson for agents
AI agents need more than data access. They need entity clarity. An agent that picks the wrong customer, the wrong product, or the wrong supplier can act technically correct and still cause business damage.
That's why companies shouldn't dismiss master data, Golden Records, and Entity Resolution as legacy data management topics. For agentic systems, they become a safety and operations question. The more an agent is allowed to act, the more important the unambiguous answer to a simple question becomes: Who or what are we talking about right now?
For us, that's why Entity Resolution belongs early in the architecture work around AI agents. Tools, data access, and automation deliver little value if it's unclear which entity an action refers to. In Salesforce and enterprise environments, Data Cloud, MuleSoft, and existing MDM approaches can serve as building blocks. But the business rule remains decisive: the agent should only act when the entity is unambiguous enough.