---
title: "Entity resolution for AI agent memory"
description: "What entity resolution is, how deterministic and probabilistic entity matching work, and why agent memory must resolve entities at ingestion."
canonical: https://past.dev/guides/entity-resolution
last-updated: 2026-09-02
---
# Entity resolution for AI agent memory

Source: https://past.dev/guides/entity-resolution

Entity resolution is the process of deciding which records refer to the same real-world subject and linking them under one identity. An AI agent's memory stores facts about entities, so resolution determines whether Bob Smith, bob@acme.com and @bsmith share one timeline or three. It runs at ingestion, before facts are stored. Under-merging splits one person's history into fragments. Over-merging combines two people into a subject that never existed. Both corrupt every answer built on the affected entity.

## One subject, many spellings

Most datasets refer to the same real-world subject in several ways. A CRM row names **Bob Smith** at Acme. A support thread arrives from `bob@acme.com`. A Slack message is signed `@bsmith`. Each record is internally consistent. None of them states that all three describe one person.

```onepersonthreerecords
CRM row:        name = Bob Smith, company = Acme
Support email:  from = bob@acme.com
Slack message:  author = @bsmith
```

Entity resolution is the process of linking such records under one identity. The database literature calls the same problem record linkage. Entity matching is the pairwise step: given two records, decide whether they refer to the same subject. Resolution is the dataset-level outcome: every record assigned to exactly one entity. The subject can be a person, a company or a project; the mechanics are the same.

## Why agent memory raises the stakes

A conventional database stores records. An agent memory stores facts, and every fact attaches to an entity. Resolution errors therefore corrupt the unit the memory reasons with.

- **A split entity splits the timeline.** If **Bob Smith** and `bob@acme.com` remain two entities, a question about Bob's billing history retrieves half of it. The agent then asks for information Bob already provided.
- **A wrong merge invents a person who does not exist.** If two customers named Chris Lee become one entity, refund history from one appears in conversations with the other. The stored timeline shows decisions no single person made.
- **Errors compound.** Agent memory ingests continuously. Every new record attaches to whichever entity the resolver chose, so an early mistake accumulates months of misattached facts.

A concrete case. On March 3, 2026 Bob asked by email for invoices in CSV. On April 9 he reported a billing bug in a support ticket. On May 20 he confirmed the fix in Slack. Resolved correctly, the memory holds one billing timeline with three dated facts. Unresolved, it holds three unrelated entities with one fact each, and a question about Bob's billing history reads only the first.

## Matching concepts: deterministic, probabilistic, blocking, closure

Four concepts cover most production resolvers.

| Concept | Definition | Example |
| --- | --- | --- |
| Deterministic matching | Link records that share an exact, unique key | Two records carry the verified email `bob@acme.com` |
| Probabilistic matching | Score field similarity and link above a chosen threshold | Name edit distance plus a shared company and city |
| Blocking | Restrict comparisons to small candidate groups instead of every possible pair | Compare only records that share a company domain |
| Transitive closure | If A matches B and B matches C, all three records join one entity | An email links a display name to a chat handle |

Deterministic links are safe to apply automatically. Probabilistic links carry a false-match risk that grows as the threshold loosens, so production systems treat them as candidates for review rather than automatic joins. Blocking decides how much of the data each record is compared against. Transitive closure decides how far a single link propagates: one wrong probabilistic edge can pull a whole cluster together, which is why closure over unreviewed edges is dangerous.

> **Default**
>
> Automate deterministic joins. Queue probabilistic ones for review. Let transitive closure follow reviewed edges only.

## The two failure modes

Every resolver fails in one of two directions. The symptoms differ, and so does the repair cost.

|  | Under-merge (split identity) | Over-merge (false merge) |
| --- | --- | --- |
| What happened | One subject is stored as several entities | Two subjects share one entity |
| Typical symptom | Answers cover half the history; the agent re-asks known facts; entity counts inflate | Facts cross-contaminate; one customer's history appears in another's conversation |
| Detection | Visible when a user misses context they already gave | Often silent until a contradiction or a complaint |
| Repair | Add a link between the fragments | Split the entity, which requires per-source attribution |

Over-merge is the costlier failure for an agent. A split identity degrades answers. A false merge fabricates them, and it can move one person's private context into another person's session. Repairing it requires knowing which source contributed each fact, which is the argument for keeping provenance from the start. The mechanics of joining and splitting are covered in [how to merge duplicate profiles](/guides/merge-duplicate-profiles).

## Where resolution runs in the pipeline

Resolution can run when records arrive or when questions are asked. Running it at ingestion is the standard choice for memory systems.

1. **At ingestion**: each incoming record is resolved against known entities before its facts are stored. Storage holds resolved entity ids, so recall is a plain read across one timeline and joins across sources need no query-time work.
2. **At query time**: records are stored raw and joined when a question arrives. Every query repeats the matching work, latency grows with the corpus, and two queries can disagree if thresholds or models changed between them.

Ingestion-time resolution also keeps decisions inspectable: each link was made once, at a known time, from a known record. Query-time resolution remakes the decision on every question, so the same corpus can answer differently on different days.

Three adjacent problems have their own guides. Cross-channel user identity, including anonymous sessions and login stitching, is covered in [identity resolution](/guides/identity-resolution). What a merge does to stored facts, and how to undo one, is covered in [merge duplicate profiles](/guides/merge-duplicate-profiles). How to evaluate a resolver before production is covered in [testing entity resolution](/guides/testing-entity-resolution).

## Entity resolution in past.dev

past.dev runs entity resolution at ingestion. It links references to the same person or subject across email, transcripts, tickets and chat, so recall returns one dated timeline per entity with the evidence behind each fact. The [Memory API quickstart](/docs/memory-api/quickstart) shows the ingest and recall calls.

## Frequently asked questions

### What is entity resolution in simple terms?

It is the process of working out which records refer to the same real-world person or thing and linking them under one identity. Two records that say Bob Smith and bob@acme.com become one entity when the evidence says they are the same person.

### What is the difference between entity resolution and entity matching?

Entity matching is the pairwise decision about whether two records refer to the same subject. Entity resolution is the dataset-level outcome, where every record is assigned to exactly one entity by combining many match decisions.

### Why do AI agents need entity resolution?

An agent's memory attaches facts to entities, so unresolved records split one person's history across several identities. The agent then answers with partial history or asks for information it already has.

### Is entity resolution the same as deduplication?

Deduplication removes near-identical copies of the same record. Entity resolution links records that look different but refer to the same subject, which is a harder and more consequential decision.

### Does past.dev do entity resolution automatically?

Yes. When text is ingested, past.dev links references to the same person or subject across sources such as email, transcripts, tickets and chat, and recall returns one dated timeline per entity.

## Related

- [Identity resolution across channels](https://past.dev/guides/identity-resolution)
- [How to merge duplicate profiles](https://past.dev/guides/merge-duplicate-profiles)
- [Testing entity resolution](https://past.dev/guides/testing-entity-resolution)
- [Memory API quickstart](https://past.dev/docs/memory-api/quickstart)
- [Benchmark methodology](https://past.dev/benchmarks/methodology)