---
title: "Identity resolution across sessions and channels"
description: "How identity resolution joins emails, phone numbers, user ids and anonymous sessions into one profile, so an AI assistant keeps cross-channel context."
canonical: https://past.dev/guides/identity-resolution
last-updated: 2026-09-02
---
# Identity resolution across sessions and channels

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

Identity resolution links the identifiers one user leaves across channels (an email address in support, a phone number in SMS, a user id in the product, an anonymous session before login) into a single profile. For an AI assistant it is the difference between greeting a returning user with their history and greeting them as a stranger. Deterministic keys such as a login id come first. Probabilistic signals fill gaps, at a cost that must be weighed against leaking one person's context to another.

## The user is the entity

[Entity resolution](/guides/entity-resolution) links records that describe the same subject of any kind: people, companies, projects. Identity resolution is the special case where the subject is a user or customer and the records are the traces one person leaves across channels. The traces rarely share an obvious key.

- In support: the email address `dana@northwind.com`
- In SMS: the phone number `+1 555 0100`
- In the product: the user id `u_4187`
- Before signup: an anonymous session id set by the website in October 2025

Each channel mints its own identifier. Identity resolution ties them into one profile so that facts learned in one channel become available, subject to access rules, in the others.

## Identifier graphs and session stitching

Customer data platforms formalized this problem as an identifier graph. Nodes are identifiers: emails, phone numbers, user ids, device ids, session ids. Edges are observed links between them, each recorded with its evidence and a timestamp. A profile is a connected component of that graph.

Session stitching is the retroactive part. A visitor browses anonymously in October 2025, returns in November and signs up. The login event creates a deterministic edge between the session id and the new user id, and the October activity joins the profile after the fact. Agent memory inherits the same vocabulary: questions a person asked a website assistant before signup become part of the same customer's history once the identifiers connect.

```anidentifiergraphasedges
u_4187             <-> dana@northwind.com    login email, verified 2025-11-02
u_4187             <-> s_9f3c                login event, 2025-11-02
dana@northwind.com <-> ticket:5520           reply address, 2026-02-03
+1 555 0100        <-> u_4187                phone verified by code, 2026-01-14
```

Every edge keeps the observation that created it. That record is what makes an edge auditable, and severable when it turns out to be wrong.

## What breaks without it

An assistant without identity resolution treats each channel as a different person. Three symptoms recur.

- **A returning user is greeted as a stranger.** The person who explained their setup by email in February gets asked the same discovery questions in chat in March.
- **Preferences learned in one channel are unavailable in the next.** On February 3, 2026 a customer tells the support assistant that invoices must be CSV. On February 17 the in-product assistant exports a PDF, because the preference is attached to an email address it has never seen.
- **Continuity breaks at signup.** Anonymous research from before the account existed never joins it, so the assistant repeats explanations the customer already read.

Cross-channel identity is the requirement underneath all three: the profile has to be the unit of memory rather than the channel.

## Deterministic keys first, probabilistic signals second

Identifier edges divide into two classes, and the classes justify different behavior.

| Signal | Class | Safe default |
| --- | --- | --- |
| Login id or OAuth subject | Deterministic | Join automatically |
| Email verified by the user | Deterministic | Join automatically |
| Phone verified by one-time code | Deterministic | Join automatically |
| Shared device or browser | Probabilistic | Hold as a candidate |
| Similar name plus employer | Probabilistic | Hold as a candidate |
| Email typed into a form, unverified | Probabilistic | Hold as a candidate |

In web analytics a wrong probabilistic join miscounts a funnel and the damage ends there. In an assistant the same mistake routes one person's remembered context into another person's conversation, which can mean showing customer A the contract terms of customer B. A threshold that is acceptable for analytics is too loose for memory. The working rule: recalled context crosses deterministic edges only, and a probabilistic candidate stays held until a deterministic event (a login, a verification code) confirms it. Joining and separating profiles has its own mechanics, covered in [merge duplicate profiles](/guides/merge-duplicate-profiles).

> **Boundary**
>
> A wrong analytics join miscounts a chart. A wrong memory join shows one customer another customer's history.

## Audience boundaries

A resolved profile concentrates personal data, so resolution and access control have to move together. The support assistant may see support history. A sales assistant may see a different slice. An internal analytics job may see aggregates only. Resolution decides which facts belong to one person; audience rules decide which caller may recall them.

past.dev applies this as a recall filter: what a caller can recall is scoped to what that audience may see, so joining identifiers never widens any caller's access. The [Memory API quickstart](/docs/memory-api/quickstart) shows how ingest and recall are scoped.

Deletion requests follow the same graph. Erasing a person means erasing by profile, across every identifier they ever used, which is covered in [GDPR memory deletion](/guides/gdpr-memory-deletion).

## The three-way test

One test verifies the whole pipeline. Ingest three sources in which the same person appears three ways. Ask one question that only the joined profile can answer.

1. An email from `dana@northwind.com`, dated March 12, 2026: the rollout budget is approved.
2. An SMS from `+1 555 0100`, dated March 19: the deadline moved to April 30.
3. A product note by `u_4187`, dated April 2: the pilot is limited to the Boston office.

Then ask the assistant what Dana has decided about the rollout since March. A passing answer cites all three facts with their dates. An answer with one or two facts locates the missing edge for you. A deeper protocol, including gold sets and hard negatives, is in [testing entity resolution](/guides/testing-entity-resolution), and the [benchmark methodology](/benchmarks/methodology) applies the same end-to-end idea at scale.

## Frequently asked questions

### What is identity resolution in customer data?

It is the process of linking the identifiers one person leaves across channels, such as emails, phone numbers, user ids and anonymous sessions, into a single profile. Customer data platforms popularized the term, and agent memory systems need the same capability.

### How can an AI assistant recognize a returning user across channels?

By resolving identifiers to one profile: a verified email, a login id and a verified phone number that belong to the same person point at the same memory. The assistant then recalls that person's history regardless of the channel the conversation arrives on.

### What is session stitching?

It is the retroactive joining of anonymous session activity to a known profile once a deterministic event, usually a login or signup, links the session to a user id.

### What happens if identity resolution merges two different people?

Context leaks: one person's remembered facts can surface in another person's conversation. Recovery requires severing the wrong edge and splitting the profile, which is only possible if each fact kept its source.

### Should probabilistic identity matches be used in an AI assistant?

They are useful as candidates but risky as automatic joins, because a wrong join can expose one customer's context to another. A common rule is to let recalled context cross only deterministic edges such as verified emails or logins.

## Related

- [Entity resolution for agent memory](https://past.dev/guides/entity-resolution)
- [How to merge duplicate profiles](https://past.dev/guides/merge-duplicate-profiles)
- [GDPR memory deletion](https://past.dev/guides/gdpr-memory-deletion)
- [Memory API quickstart](https://past.dev/docs/memory-api/quickstart)
- [Memory benchmarks](https://past.dev/benchmarks)