People-aware memory begins with an unglamorous question: are these two records the same person?
If the answer is wrong, every downstream capability becomes unreliable. A customer briefing may mix two stakeholders. A founder may receive a reminder based on someone else’s promise. A preference inferred from one contact can be applied to another. These failures are especially dangerous because the resulting profile often looks coherent.
Canonical identity is therefore not data cleanup around the edges of an agent system. It is the foundation that determines whether relationship memory has a stable subject.
Why source IDs are not enough
Every source has its own identifiers. A CRM knows a contact ID. Email knows an address. Calendar knows an attendee string. Support software knows a user ID. Documents may mention only a name and company.
Using source IDs alone produces fragmentation. The same executive becomes four people, each with an incomplete history. Agents then miss cross-source changes: the meeting commitment is not connected to the support escalation, and the CRM role change is not connected to the calendar attendee.
The canonical entity sits above source records. It provides a durable internal ID and links source-specific identities as evidence. The links can change without changing the subject’s canonical ID.
Why names are not enough
The opposite shortcut—merge by normalized name—creates false identity. Names are shared, abbreviated, transliterated and changed. A company can have two Alex Lees. A person can move organizations while keeping an email forwarding address. An assistant may schedule a meeting on behalf of an executive.
Name similarity is a candidate-generation signal, not decisive evidence. It is useful for asking, “Could these records match?” It should rarely answer, “These records definitely match.”
A high-quality resolver combines independent signals:
- verified email or phone ownership;
- organization and role overlap;
- explicit source links;
- co-occurring relationships;
- consistent geography or domain;
- user confirmation;
- negative evidence such as simultaneous conflicting roles.
The exact weighting depends on the domain, but the system should be able to explain the basis of a merge.
Precision matters more than recall
In many machine-learning tasks, teams optimize a balanced score between precision and recall. Identity for memory usually deserves an asymmetric objective: false merges cost more than missed merges.
A missed merge creates fragmentation. It can be detected when a user notices two profiles and can often be repaired by joining them. A false merge contaminates the combined history. It may create derived summaries, relationship edges and inferred preferences that continue to circulate after the original merge is corrected.
This argues for conservative automatic merging and a visible unresolved state. The system should be comfortable saying:
- likely same person, not yet merged;
- ambiguous between two candidates;
- previously merged, now under review;
- explicitly confirmed as distinct.
Uncertainty is not failure. Hidden uncertainty is.
Model identity as a graph of evidence
A useful representation separates the canonical entity from its identifiers and assertions.
The canonical person might contain:
- stable internal ID;
- current display name;
- known aliases;
- current and historical organization relationships;
- linked source identities;
- merge and split history;
- status and review flags.
Each source link should retain its origin, first and last observed time, verification status and confidence. This allows an agent to say, for example, that a calendar attendee and CRM contact are linked because of a verified corporate email, while a document mention remains only a candidate association.
The graph representation also supports non-person entities. Organizations, products and projects can have canonical identity, and relationships between them can carry their own effective time and provenance.
Treat organization membership as temporal
A common identity bug is using company membership as if it were permanent. People change jobs. Consultants work across clients. Board members have multiple affiliations. A founder can use personal and company addresses interchangeably.
Organization relationships should have effective time and role, rather than being embedded as a static field on the person. This helps resolve new events correctly. A message from an old company domain after a job change may be forwarded history, not evidence that the person still works there.
Temporal membership also improves retrieval. When preparing for a current customer meeting, the agent can prioritize the person’s present role while preserving historical relationships that explain earlier commitments.
Make merge and split reversible
No resolver is perfect. The data model should assume that merges will sometimes be reversed.
A reversible merge needs more than changing a foreign key. The system should track:
- which source identities were joined;
- what evidence supported the merge;
- which memories and relationships were derived after the merge;
- whether those derived objects depend on evidence from one or both original subjects;
- how to redistribute or invalidate them during a split.
This is where provenance becomes operational. If a claim can point back to the source records that support it, a split can re-evaluate the claim. Without that lineage, correction becomes manual archaeology.
The memory-quality model is relevant here: correctability requires enough provenance to understand downstream effects.
Use human confirmation where it has leverage
Human review is expensive if every match requires it. It is valuable when concentrated on ambiguous, high-impact cases.
Good review candidates include:
- two active people with the same name in one organization;
- a proposed merge that would connect separate authority scopes;
- an identity associated with consequential commitments;
- a match based only on model inference;
- a merge that would combine conflicting verified attributes.
The review interface should present the evidence for and against the merge, not merely a confidence score. Reviewers should be able to confirm, reject, defer or mark two identities as definitely distinct.
Explicit user corrections should outrank probabilistic matching. If a user says two records are different, the system should create a durable non-match constraint so it does not propose the same merge again next week.
Avoid identity leakage across scopes
Canonical identity does not imply globally shared memory. The same real-world person may appear in personal and organizational contexts, but those contexts can have different owners and authorization boundaries.
One approach is to maintain a stable subject identity while attaching memories and relationships to explicit scopes. Another is to use scoped entity views connected by carefully governed links. The right choice depends on the product boundary, but the principle is consistent: recognizing that two records refer to the same human should not automatically grant every agent access to every associated fact.
The security boundary should therefore be designed alongside identity resolution, not added after entity graphs are populated.
Evaluate with adversarial identity cases
A random sample of easy matches will make almost any resolver look good. Evaluation should emphasize cases that produce realistic damage:
- same name, same organization, different people;
- one person, multiple emails and changing organizations;
- assistant and executive sharing scheduling context;
- copied email threads containing old participants;
- forwarded messages from a previous employer;
- aliases and transliterations;
- parent and subsidiary domains;
- deliberate user corrections after an incorrect merge.
Measure automatic merge precision, unresolved-case rate, split success and downstream contamination. A resolver that achieves a high match rate by merging aggressively may perform worse for agent memory than a conservative resolver with more unresolved candidates.
A practical resolution pipeline
A dependable pipeline often looks like this:
- Normalize source identifiers without discarding original values.
- Generate candidate matches using strong identifiers first and fuzzy signals second.
- Apply deterministic non-match rules for known conflicts.
- Score or classify candidates using multiple independent signals.
- Auto-merge only above a high precision threshold.
- Queue ambiguous, high-impact cases for review.
- Preserve merge evidence and version history.
- Re-evaluate affected memories after merge, split or corrected affiliation.
Do not let a language model directly rewrite canonical identity without controls. Models are useful for extracting names, roles and contextual evidence, but identity mutations should pass through typed operations, constraints and audit logs.
Identity is a continuing process
Canonical identity is not a one-time deduplication job. New evidence arrives continuously. Roles change, addresses expire, organizations rename and users correct the system.
That means identity maintenance belongs in the memory loop:
- ingest new evidence;
- compare it with current entity state;
- update or challenge links;
- preserve the prior version;
- propagate the change into retrieval.
When built this way, identity becomes a durable substrate for many agent experiences. GTM agents can follow stakeholders across handoffs. A personal AI Chief of Staff designed on the same foundation would connect calendar, conversation and document context—wherever those sources are authorized for a given deployment—without confusing people. Developers can retrieve by a stable subject rather than by brittle source keys.
Explore those operating contexts on the GTM and founder solution pages. In both cases, the lesson is the same: an agent cannot reliably remember a relationship until the system can reliably say who the relationship belongs to.