---
title: "How to merge duplicate profiles in AI memory"
description: "How to merge duplicate profiles without losing history: merge vs link, survivorship rules, provenance for undo, and monitoring after the merge."
canonical: https://past.dev/guides/merge-duplicate-profiles
last-updated: 2026-09-02
---
# How to merge duplicate profiles in AI memory

Source: https://past.dev/guides/merge-duplicate-profiles

To merge duplicate profiles is to join two stored records of the same subject into one entity with one timeline. A safe merge keeps provenance: every fact remains attributed to the source record that supplied it, so a wrong merge can be split apart later. Survivorship rules decide which value wins when fields conflict, and when to keep both values as an open conflict instead. Detection finds candidates; review, attribution and monitoring make the merge reversible and observable.

## What a merge does to stored facts

A merge joins two profiles that describe the same subject into one entity. Three things happen to the stored data.

1. **Timelines interleave.** Facts from both profiles sort into one history by event time. A role change recorded by the CRM in January 2026 and a preference recorded by support in March 2026 become one dated sequence.
2. **Identifiers union.** The merged entity answers to every identifier either profile carried, and future records matching any of them resolve to it.
3. **Provenance must survive the operation.** Each fact keeps the source record that supplied it. This is what later makes the merge auditable and reversible.

CRM teams describe the same operation as merging duplicate customer records. A memory system adds one difference: an agent answers questions from the merged timeline, so a wrong merge reaches users in generated answers instead of staying unread in a table.

## Merge or link

There are two ways to record that two profiles are the same subject, and they differ in reversibility.

|  | Merge | Link |
| --- | --- | --- |
| Operation | Rewrite: both profiles become one entity | Associate: both profiles remain, marked as one subject |
| Reversibility | Undo requires per-source attribution kept at merge time | Undo is removing the association |
| Read path | Reads see one profile directly | Reads follow the association at query time |
| Suited to | High-confidence matches: a shared verified key, or a reviewed candidate | Uncertain matches, and records in systems you cannot rewrite |

A safe default: link on suspicion, merge on confirmation. A link created in March can become a merge in April once a verified key confirms it. A merge executed in March on a bad guess is a data-repair project.

## Survivorship rules

After a merge, single-valued fields can hold two candidate values. Survivorship rules decide the outcome. Apply them in order.

1. **Latest event time wins** for facts that change legitimately. A title of Head of Operations recorded in May 2025 loses to COO recorded on February 10, 2026, because the newer fact supersedes the older one. Use the source's own timestamp rather than import time; the difference is covered in [event time vs ingestion time](/guides/event-time-vs-ingestion-time).
2. **The authoritative source wins** where one system owns the field. The billing system outranks a form fill for the billing address.
3. **Keep both as a conflict** when credible sources disagree about the same period and neither supersedes the other. Two current phone numbers can both be true. Two current legal names for one person usually cannot, and that disagreement should surface as a conflict instead of being resolved arbitrarily. See [contradictory facts](/guides/contradictory-facts).

Losing values should remain on the timeline as superseded facts with their dates ([fact supersession](/glossary/fact-supersession)). Survivorship chooses what to present as current. It should never delete history.

## The undo problem

Some merges are wrong, and the wrongness can take months to surface. On June 5, 2026 two profiles named A. Rivera are merged. In August a contradiction appears: the entity holds two employers, two cities and two conflicting sets of preferences for the same weeks. The repair is a split: reassign every fact to the source record that contributed it and rebuild two entities.

The split is only possible if attribution was kept. If the merge overwrote both profiles into one record with no per-source history, the information needed to separate them is gone, and the remaining options are guessing or deleting. This is the strongest argument for provenance in memory systems: it turns a wrong merge from permanent damage into a reversible operation. See [data provenance](/guides/data-provenance).

> **Prerequisite**
>
> A merge is reversible only if per-source attribution was recorded when it ran. Attribution cannot be reconstructed later.

## Detecting duplicates

Merges begin with detection. The productive signals, roughly in order of reliability:

- **A shared deterministic key.** Two profiles carry the same verified email or the same phone number verified by code.
- **A cross-source reference.** One document pairs two identifiers as one person, for example an email signature that joins a full name to a chat handle.
- **Normalized field equality.** The same normalized name plus the same employer or email domain.
- **Near-duplicate values.** Small edit distance between names or addresses, such as `dana.reyes@` and `danareyes@` on the same domain.
- **Behavioral overlap.** Two profiles that never appear in the same conversation and alternate in a pattern consistent with one person switching devices.

Detection produces candidates. Candidates then enter a review process.

## An operating procedure

1. **Detect** on a schedule. Queue candidate pairs together with the signal that produced each one.
2. **Review** by class. Deterministic matches can merge automatically. Probabilistic candidates above your review threshold go to a human, shown both timelines side by side.
3. **Merge with attribution.** Keep per-source attribution on every fact, record the merge itself as a dated event with an operator, and retire the duplicate id as an alias rather than deleting it.
4. **Monitor after the merge.** Watch merged entities for contradiction spikes. New conflicts concentrated on recently merged profiles are the standard early sign of a wrong merge, and the sooner a split runs, the fewer misattached facts it has to move.

## Merging in past.dev

past.dev keeps the prerequisites of a safe merge by default: entity resolution runs at ingestion, every fact stays attributed to its source, and replaced values keep supersession links with their dates, so a joined subject holds one timeline in which every fact still names its original source. Deleting a source with `DELETE /api/v1/ingest/{ingestionId}` erases what only that source supported. The [Memory API quickstart](/docs/memory-api/quickstart) covers ingest, recall and deletion.

## Frequently asked questions

### Should I merge duplicate profiles or just link them?

Link when the match is uncertain, because an association can be removed without loss. Merge when a deterministic key or a human review confirms the match, and keep per-source attribution so the merge can still be undone.

### How do I undo a merge of two customer profiles?

Reassign every fact to the source record that originally supplied it and rebuild the two entities. This only works if attribution was kept at merge time; without it the profiles cannot be cleanly separated.

### What are survivorship rules in data management?

They decide which value a merged profile keeps when fields conflict, for example the latest value by event time or the value from the most authoritative system. Good practice keeps the losing value on the timeline as history.

### What causes duplicate customer records?

Every channel that can create a profile does so independently: signup forms, imports, support tickets and manual CRM entry. Without resolution at the point of entry, each channel mints a new identity for the same person.

### How do I detect duplicate profiles automatically?

Look for shared deterministic keys, normalized name and employer equality, near-duplicate emails, and cross-source references that pair two identifiers as one person. Treat the results as candidates for review rather than automatic merges.

## Related

- [Entity resolution for agent memory](https://past.dev/guides/entity-resolution)
- [Data provenance](https://past.dev/guides/data-provenance)
- [Handling contradictory facts](https://past.dev/guides/contradictory-facts)
- [Memory API quickstart](https://past.dev/docs/memory-api/quickstart)
- [Benchmark methodology](https://past.dev/benchmarks/methodology)