# Relationship memory

Relationship memory attaches what is known to a person, not to a thread. The practical consequence is that a customer who emailed in March, rang in June and messaged on WhatsApp in September is one continuous relationship rather than three strangers — and the agent answering the September message can see what was promised in March.

- **Status:** Reference
- **Audience:** both
- **In the app:** #/relationships, #/timeline
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/relationship-memory/

## Why the key matters more than the contents

Most conversational systems key memory to a session. It is the obvious choice and it fails in a specific way: every new channel, every new thread, every reinstalled app starts from nothing. The customer experiences this as being asked, again, something they have already explained — and does not care that the previous explanation is technically retrievable in another thread.

Keying to the person inverts that. The conversation becomes a view of the relationship rather than the container for it, and the interesting questions become answerable: what did this person ask for last time, what were they promised, what stage are they at, what has gone wrong for them before.

| Situation | Keyed to the conversation | Keyed to the person |
|---|---|---|
| Same customer, new channel | Starts empty | Carries everything known |
| A promise made in another thread | Invisible | Visible with its follow-up |
| A block set on email | Applies to that thread | Holds wherever that person appears |
| Answering 'who is this' | Requires searching | Is the record you are already on |

## Does Connect use relationship memory?

**Used.** A Person is a record in the workspace's relationships; an Identity is one address on one channel that resolves to that Person; a Company is the organisation they belong to. `identity.py` and `crm.py` do the resolution, `people.py` and `companies.py` hold the records, and `relationship_console.py` answers one relationship for either audience over a single implementation.

**Customer 360** is that view: one person's whole history, every channel, in one place. Alongside it sit the lifecycle stage from `journey.py`, the cross-channel timeline from `timeline.py`, open opportunities, support cases and follow-ups. Duplicate people can be merged from the relationship console — which matters, because identity resolution that never makes a mistake does not exist, and the recovery path is part of the design rather than an admission that it is not.

The memory tiers described under [structured memory](/docs/technology/structured-memory/) bottom out at the **contact** tier, which is where relationship memory lives. A row set there wins over the same fact set at the endpoint, channel or workspace tier, so 'for this person specifically' is expressible without a special case.

## Resolving one person across channels

1. Match on the identity that arrived — the address, the number, the account handle.
   - Result: An exact identity match is the only resolution that is safe without further evidence.
2. Where no identity matches, create rather than guess.
   - Result: A new Person with one identity is correct and recoverable. A wrong merge shows one customer another customer's history, which is not.
3. Merge deliberately, from the console, when the evidence is there.
   - Result: The identities collapse onto one Person and the history joins up. See [telling a new prospect from an existing customer](/research/prospect-identity-resolution/).

> **Note** Under-merging and over-merging are not symmetrical errors. Under-merging costs a duplicate row and a moment's confusion; over-merging is a data breach between two customers who happen to share a name. The default has to be caution, and the correction has to be easy.

## Limits

- **A shared mailbox is not a person.** `accounts@` resolves to an organisation's channel, and treating whoever wrote from it as one individual produces a person made of several.
- **Identity changes.** People change employer, number and address. The relationship survives only if the new identity is attached to the existing Person rather than starting a new one.
- **More history is not more relevance.** Everything known cannot go into every prompt; the same budgets apply, so the tier resolution decides what is worth the space.
- **Memory of a person is personal data.** It has to be readable, correctable and deletable by request, which is why every tier is visible in the memory viewer and every row can be forgotten.

## Questions

### How is this different from a CRM's contact record?

A CRM record is a place a human files information. Relationship memory is read at the moment an answer is composed and constrains what that answer may say. Connect holds both on the same records, so a note that changes what the agent does is the same object as the note a person reads.

### What happens when two people share an email address?

They resolve to one Person, because one identity resolves to one Person by definition. Separating them means giving each their own identity — a distinct address or number — and splitting the record from the relationship console.

### Does a phone call add to the same relationship as an email?

Yes, when the number resolves to a known identity. That is the point of keying to the person: the call, its transcript and its summary land on the same timeline as the mail, and the next reply on any channel can see them.

## Related

- [Relationships in Connect](https://connectbyjbrh.com/docs/relationships/)
- [Relationship memory versus chat history](https://connectbyjbrh.com/research/relationship-memory/)
- [Why the machine proposes a merge and a person disposes](https://connectbyjbrh.com/research/one-person-many-channels/)
- [Structured memory](https://connectbyjbrh.com/docs/technology/structured-memory/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)

## What this page is based on

- Connect architecture source pack — docs-source/sources/GENERAL.md §4 and §6, relationship modules and memory tiers
- Connect capability registry (docs-source/facts.py) — cross_channel_identity, customer_360, duplicate_merge, timeline
- `backend/app/identity.py`, `relationship_console.py`, `journey.py`