At entity resolution. A name is a useful search clue, not a durable identity key. The writer or retrieval layer treated two mentions with the same string as one subject. Conversational entity-linking research, such as CREL, treats linking mentions to entities as a separate problem. A provenance-aware memory design also keeps origin and evidence for each item, as in this agent memory work. Neither paper guarantees a particular production identity policy for this example.

I would trace the exact identity joins. Which authenticated customer ID belonged to each conversation? Was the address fact extracted from an agent note or from the customer's own statement? Did a batch consolidation job group facts by display name, email fragment or embedding similarity? Did retrieval filter by account ID before semantic matching? Once a fact is linked to the wrong profile, later summaries can repeat it with apparently high confidence. More retrieval or a bigger context window makes the contaminated fact easier to encounter, not safer.

The durable memory key should be the canonical subject ID in its tenant and account scope, with provenance back to the original utterance and any verified system-of-record change. A mention such as “Arun” can remain unresolved until the active session or a trusted lookup disambiguates it. If the source is about a third party, do not attach it to the speaker by default. When multiple identities remain possible, ask or abstain from using the fact for a consequential action. Retrieval authorization and entity correctness both matter. A fact can be from the right tenant and still be about the wrong person.

If the interviewer asks whether to merge two customer records that share a phone number, I would still require a defined identity-resolution process. Shared contact details can be family, employer or stale data. Keep candidate links separate, record why a merge happened, support reversal and rebuild dependent summaries when a merge is undone. Test same-name users within one tenant, renamed accounts, shared contacts and a false merge corrected later. A user switches accounts. Why does the agent remember the previous customer's preference? covers memory following a user across account switches. Here the user has not switched accounts. The system joined two distinct subjects because their names looked alike.