TL;DR: Stop AI agents confusing two customers by fixing the context layer before the model reasons. Customer records should be resolved into persistent entity IDs at ingestion, ambiguous matches should be routed by confidence and evidence, and the agent should retrieve one already-resolved Customer 360 context at query time. A better prompt cannot reliably repair a retrieval layer that hands the model duplicate people, stale CRM records and two plausible customers with the same name.
Why do AI agents confuse customers with similar names?
An LLM does not have a durable customer identity graph. It predicts from the context it receives. If the context window contains two John Smith records, an old email, a ticket from a spouse and a billing record from another account, the model may produce a fluent answer that blends facts across people.
The common failure is not that the model lacks a better instruction. The failure is that the retrieval system has asked the model to do identity resolution implicitly. The model sees a pile of plausible records and chooses what looks coherent. In customer workflows, coherent is not enough.
For builders, the useful lesson is not that every agent needs the same vendor. It is that agents need a resolved identity layer before they receive customer context.
| Context failure | What the agent sees | What can go wrong | Safer pattern |
|---|---|---|---|
| Similar names | Two people named Daniel Meyer in CRM and support | The answer mixes tickets, orders or entitlements | Resolve to a persistent entity ID before retrieval |
| Duplicate records | One person has old and new CRM contacts | The agent treats a stale record as current | Link records at ingestion and retrieve one entity |
| Fragmented systems | Billing, support and CRM disagree | The model picks a field without evidence | Return source IDs, scores, edges and allowed fields |
| Weak match | Search finds several plausible entities | The model answers confidently from the wrong record | Route to review or ask a disambiguating question |
| Over-merge | Shared household or business address links two people | Private data can leak across customers | Require strong identifiers and split-review paths |
- How should the customer identity layer work?
- What do score and hitScore mean for agent decisions?
- How does the resolved-entity workflow stop confusion?
- What does a CRM example look like end to end?
- Which failure modes should the workflow handle?
- What pitfalls still break agent identity?
- FAQ
How should the customer identity layer work?
Put the identity-resolution layer before the agent retrieval layer. New records from CRM, support, billing, product analytics and marketing should be submitted to the resolution layer as they arrive. The resolution layer links the record to an existing entity or creates a new entity. The agent later queries the resolved entity, not the raw source tables.
The sequence is deliberately boring:
- Submit customer records at ingestion.
- Resolve records into persistent entity IDs.
- Preserve match evidence and confidence signals.
- Define automatic-use and review thresholds.
- Retrieve resolved context at query time.
- Monitor wrong-customer and review outcomes.
The order matters. If identity assembly happens after retrieval, the model has already seen the messy state. If resolution happens at ingestion, the retrieval request can be narrow: find the resolved entity for this email, phone, account ID or claimed identifier, then return only the approved fields.
That boundary is the handoff from architecture to implementation. In Tilores, identities are resolved during ingestion using configured rules and probabilistic matching. Query time is for retrieving and using the already-resolved customer or entity context. The agent should not assemble a customer identity when it asks a question.
The concrete API shape follows from that handoff. The Tilores entity resolution software page explains the real-time identity layer this pattern depends on, and the Tilores API documentation shows GraphQL search, submit and entity operations. In search and entity examples, Tilores exposes records, edges, duplicates, hits, score and hitScore. These are exactly the kinds of artifacts that let an engineering team explain why a customer context was returned to an agent.
What do score and hitScore mean for agent decisions?
Match-confidence fields turn identity resolution into an operational decision, not just a search result. One signal should tell the workflow whether the returned entity is well assembled; another can tell whether this specific search request found a close result for the identifiers supplied.
In the Tilores API documentation, score reflects the overall quality of matches within an entity, while hitScore indicates how closely the returned entity aligns with the search parameters. Both are on a 0.0 to 1.0 scale, documented as float values in the range (0.0, 1.0], where higher means better matching quality. The same API reference shows GraphQL search, submit and entity operations, and the examples expose records, edges, duplicates, hits, score and hitScore.
Do not turn those fields into universal thresholds without testing. A production threshold depends on data quality, identifier strength, source trust, workflow risk and the cost of false positives versus false negatives.
A practical policy might look like this, but the numbers are illustrative and must be calibrated:
| Decision band | Illustrative signal | Agent behavior |
|---|---|---|
| Automatic use | One candidate entity, strong identifiers, high hitScore, high entity score, no conflicting source evidence | Retrieve the resolved context and answer within the allowed workflow scope |
| Limited answer | One likely entity, but a stale source field or weak secondary identifier | Answer only low-risk questions or ask for one more identifier |
| Human review | Multiple candidates, medium hitScore, conflicting records or shared address/device evidence | Create a review task and tell the user the account needs verification |
| No match | No candidate clears the workflow threshold | Do not infer identity; ask for additional identifiers or create a new onboarding path |
The threshold for a support FAQ bot can be different from the threshold for a refund agent, a KYC workflow or a fraud model. A low-risk agent that explains shipping status can tolerate a different review rate than an agent that changes billing, discloses private data or approves credit.
How does the resolved-entity workflow stop confusion?
The resolved-entity workflow gives the agent a single controlled tool. The tool accepts identifiers, calls the identity layer and returns a scoped Customer 360 object. The agent does not search every CRM note, support ticket and invoice on its own.
A useful response shape includes the resolved entity ID, candidate count, allowed profile fields, linked source records, evidence, confidence signals and escalation state. It should also include source-system IDs so a human can trace the answer later.
For example, the tool can return these conceptual fields:
| Field | Purpose |
|---|---|
| entityId | Stable handle the agent and downstream workflow can reference |
| candidateCount | Whether there was one clear entity or multiple plausible entities |
| context | Approved customer facts for the agent role, such as account status or open tickets |
| records | Source-system IDs from CRM, support, billing and product systems |
| edges | Why records are connected in the resolved entity graph |
| score | Overall quality signal for the resolved entity |
| hitScore | Search relevance signal for the submitted identifiers |
| actionPolicy | Whether the agent may answer, ask for more verification or route to review |
This makes identity a system behavior rather than a prompt behavior. The model can still write a helpful response, but it is grounded in a controlled payload.
What does a CRM example look like end to end?
Imagine a customer writes: "I am Maya Carter from Northline. Why was my renewal charged twice?" The CRM has Maya Carter at Northline Ltd with email maya.carter@northline.example. HubSpot has M. Carter from Northline with a personal email. The support desk has a ticket from Maya's assistant. Billing has two customer IDs because a previous migration created a duplicate account.
A naive agent searches by name and company. It retrieves the CRM contact, the assistant's support ticket and both billing customer records. The model sees enough evidence to answer, but it may attach the assistant's ticket to Maya or treat the duplicate billing record as a separate customer.
A resolved workflow handles it differently:
- The CRM, HubSpot, support and billing records were submitted to the identity layer when they arrived.
- The identity layer linked the CRM and HubSpot records to one entity and kept the assistant as a related contact, not the same person.
- The two billing IDs were linked as source records under the same customer entity, with evidence retained.
- The agent receives the message and calls the resolved customer tool with name, company and email if available.
- The tool returns one entity ID, the linked billing source IDs, score, hitScore, edges and a policy that permits billing-status explanation but requires human approval for refund execution.
- The agent explains that two billing records exist, opens a review ticket, and does not expose data from the assistant's separate identity.
The key improvement is not that the model became smarter. The context became narrower and more truthful.
Which failure modes should the workflow handle?
The workflow should handle over-merges, under-links, stale records, shared identifiers and source conflicts.
An over-merge happens when two real people become one entity. This is the highest-risk support failure because the agent may reveal private data. Shared households, family plans, company domains, call-center numbers and business addresses should not automatically collapse identities.
An under-link happens when one real person remains split across records. The agent may deny entitlement, miss a previous ticket, duplicate work or give contradictory answers. Changed names, changed emails, transliterations and source-system migrations are common causes.
A stale-record failure happens when an old address, old email or closed account outranks the current source. The fix is not only matching. The Customer 360 payload needs source freshness, survivorship rules and source priority.
A source-conflict failure happens when CRM says the account is active, billing says payment failed and support says the account was cancelled. The identity layer can tell the agent which records belong together. The workflow still needs policy for which fields the agent may trust for each action.
What pitfalls still break agent identity?
The first pitfall is asking vector search to solve identity. Vector search can retrieve similar policies, documents and tickets. It does not prove that two records are the same customer. Use vectors for semantic retrieval and identity resolution for customer identity.
The second pitfall is hiding evidence from the agent workflow. If the tool returns only a flattened profile, the agent cannot distinguish a clean match from a barely acceptable one. Return evidence to the workflow, even if the model sees only a subset.
The third pitfall is using one global threshold. Fraud, support, KYC, billing and marketing have different tolerance for false positives and false negatives. The identity layer should support workflow-specific thresholds and review paths.
The fourth pitfall is using the LLM as the production matcher. For the production-matcher question, the Tilores LLM entity-resolution article is clear that LLMs can help with extraction, small-data exploration or human-in-the-loop support, but they are weak as the sole auditable production matcher because consistency, explainability, threshold tuning, persistence, cost and latency matter.
The fifth pitfall is forgetting correction. Bad merges and missed links happen. A production design needs split, merge, delete and reprocess behavior, plus downstream notification for systems that cached the entity.
The support-agent version of this pattern is the same core idea as entity-resolution-based RAG: the model should receive the right customer context after identity has been resolved, not a pile of semantically plausible records. The Tilores EntityRAG article, Tilores Customer 360, Tilores rules documentation and Tilores IdentityRAG page are useful when turning that pattern into a production data flow.
The sixth pitfall is letting the agent hide uncertainty in polished language. A well-written response can make a weak match feel settled. The tool response should therefore carry the candidate count, evidence state and allowed action tier in fields the workflow can enforce. The assistant can explain uncertainty to the customer, but it should not downgrade a review case to an answer because the conversation would flow better.
How should thresholds be calibrated in practice?
Thresholds should be calibrated from labelled customer data, not copied from a vendor demo. Start with a test set that includes known same-customer records, known different-customer records and intentionally ambiguous cases. Include the messy examples that actually hurt agents: reused business addresses, shared family phones, common names, transliterations, recently changed emails, merged companies, duplicate billing IDs and stale support requesters.
For each workflow, score the cost of the two mistakes separately. A false positive means two different people or companies were treated as one entity. In an AI support flow, that can leak account information. In KYC or credit, it can contaminate a decision. A false negative means one real customer remains split across records. That can make an agent deny entitlement, miss an open ticket or create duplicate accounts.
Use threshold bands rather than one number. A high-confidence band can feed the agent automatically when the result is a single entity and the evidence contains strong identifiers. A review band should catch plausible but risky matches, especially when the fields agree only on weak evidence such as name and company domain. A no-action band should force the assistant to request more identifiers or create a new intake path.
Calibrate by workflow. A low-risk help-center assistant may answer general product questions with only weak identity, because it is not disclosing private account data. A refund assistant, billing assistant or KYC workflow should require stronger evidence. Fraud teams may accept more review volume to improve recall, while privacy-sensitive support workflows often require higher precision.
Keep the threshold decision outside the language model. The model can explain the state to the customer, but the workflow should decide whether the identity evidence permits action. That is the difference between an auditable control and a convincing guess.
What logging and evaluation should run after launch?
Post-launch monitoring should track identity outcomes, not only chatbot satisfaction. Every customer-aware answer should be traceable to the entity ID, tool request, returned candidate count, source records, score, hitScore, action policy and whether the assistant answered, asked for verification or escalated.
Sample resolved and escalated conversations each week. Look for over-merge events, under-linked accounts, source-system conflicts, stale data and cases where the assistant had the right entity but used the wrong allowed field. These categories point to different fixes. A matching error belongs in the identity layer. A policy error belongs in the action layer. A response error belongs in the prompt or model layer.
Create a correction loop. When a support agent identifies a bad merge or missed link, the resolution layer should receive that feedback and downstream systems should stop relying on the old entity state. Without a correction loop, the same wrong customer context can keep appearing in agent conversations.
Measure review load as a first-class metric. If the threshold is too strict, the assistant becomes useless because every case escalates. If the threshold is too loose, wrong-customer risk rises. The right setting is the point where review volume is operationally manageable and high-risk actions remain protected.
Track false positives and false negatives separately. False positives are the privacy and compliance problem: two different customers become one context. False negatives are the service problem: one real customer stays split across accounts and the agent misses history. A single accuracy number can hide which failure mode is getting worse.
Finally, maintain an adversarial test pack. Add every production incident or near miss to a regression set: same-name customers, shared households, duplicate source IDs, changed email, migrated billing account and business alias cases. Run that pack before model changes, retrieval changes and identity-rule changes.
FAQ
How can I prevent LLM agents from confusing two customers with similar names?
Resolve customer data before the agent receives context. The agent should query a stable entity ID and a resolved Customer 360 object, with confidence evidence, instead of choosing between raw CRM, support and billing fragments.
Should an LLM decide whether two customer records are the same person?
Not as the production system of record. LLMs can help extract identifiers, summarize evidence or support low-volume review, but production identity matching should be scored, repeatable, auditable and governed outside the language model.
What is the difference between score and hitScore in Tilores search results?
The difference is entity quality versus search-parameter alignment. Tilores documentation describes score as the overall match quality within an entity and hitScore as how closely a search result aligns with the search parameters. Teams should calibrate both on their own data before using thresholds for automatic action.
What confidence threshold should auto-merge customer records?
There is no universal threshold. A safe pattern is to auto-use only a single high-confidence entity with strong identifiers and clean evidence, route medium-confidence or conflicting evidence to review, and avoid action when no candidate clears the workflow threshold.
Does vector search solve customer identity confusion?
No. Vector search can retrieve semantically similar documents or tickets, but it does not prove which customer, account or company the data belongs to. Use vector search for knowledge retrieval and identity resolution for customer context.
Where should human review fit?
Review belongs where the evidence is ambiguous, where two entities could plausibly match, where source systems conflict, or where the agent action could disclose data, change account state, approve credit, issue refunds or affect compliance.
How do I test whether agents are still mixing customers?
Build test cases with similar names, shared domains, changed emails, shared addresses, duplicate contacts, family members, businesses with aliases and known non-matches. Measure wrong-customer retrieval, over-merge, under-link, review volume and resolution latency.
Does Tilores resolve identity at query time?
No. Tilores resolves identities at ingestion. At query time, the agent retrieves and uses the already-resolved customer or entity context through APIs.
