# Relationship memory versus chat history

A conversation history records what was said. A relationship memory records what is true. The difference appears the first time somebody needs an answer the conversation never phrased — who signs off, which site deliveries go to, why this account is handled carefully. A history can only be re-read at length, every time; a memory row is resolved to the work in hand, budgeted, and can be corrected or forgotten.

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

## The questions a history cannot answer

Everything a customer ever wrote is available, and it still does not tell you that this account pays late, that the person who replies is not the person who decides, or that the last complaint was handled badly and the tone should reflect it. Those facts were never stated in one message; they are conclusions drawn across many, or things a colleague knows and never wrote down.

The failure mode of history-as-memory is specific and recognisable: an agent with the full thread in front of it still writes as though this were a first contact, because nothing in the thread says how to handle the person. More history does not fix it. The information is not in there.

## What a tiered store holds instead

`connect_memory` keeps four tiers, resolved narrowest-first — **workspace → channel → endpoint → contact** — which is deliberately the same hierarchy autonomy uses, so a person reasoning about one is already reasoning about the other. `tiers()` returns everything that applies to one piece of work, split by the tier that owns it.

An empty tier is **returned rather than dropped**. That sounds like a detail and is closer to the centre of the design: *nothing is set at this level* is an answer somebody can act on, whereas an absent tier is indistinguishable from a tier that was never consulted. A person opening the memory viewer sees where a direction came from and where one could be added.

> **Note** `directives()` reads only the tag list, never the body. That is why a block is `block:<channel>` in `tags` — a direction written as prose in the body is stored, displayed, and never acted on.

## What each one costs

|  | Conversation history | Relationship memory |
|---|---|---|
| Size over time | Grows without bound | Bounded — 700 characters into a call brief |
| Cost to read | Re-read in full each time it is used; on a live call the context is re-billed every turn | Resolved to the work in hand, at the tiers that apply |
| Correctable | No — it is a record of what happened | Yes, at any tier, including forgetting |
| Scoped | To a thread or a call | To a workspace, a channel, an endpoint or one contact |
| Answers | What was said, and when | What is true, and how to act |

The live-call figures make the difference concrete rather than philosophical. Production calls measured here are **92% carried context by input token**, and instructions of 7,500 characters gave a first token of 1.2–1.8 s against 2.3–3.4 s at 9,600. Pushing history into a call is paid for in silence in front of every reply; a 700-character memory block is not.

## Reading it, and forgetting it

A person can read what Connect knows at every tier and remove any of it. The viewer is mounted from the mailbox row, the channel screen and the contact panel, so the question *why did it say that* is answered where it is asked rather than in a settings area nobody visits.

Names get particular care on the way in and out. The written relationship summary is produced with names scrubbed, and `identity.PROTECTED_MARKERS` with `name_rejected`, `clean_name` and `scrub_names` guard every door a name passes through — summariser output, lead capture, person upsert and memory itself. A form of address is never stored as a name.

## What structured memory does not solve

- It only holds what somebody or something wrote down. A fact never captured is not recalled, and the history sitting beside it will not supply it.
- A wrong memory is worse than none, because it is read with confidence and repeated. That is the argument for making every tier readable and every row removable rather than for making memory clever.
- Memory is not evidence. Knowledge is what an answer must be grounded in; memory is how a person is handled. Storing a commercial fact as a memory rather than as knowledge is a common and expensive confusion.
- Scope errors are quiet: a fact true of one contact, stored at workspace tier, becomes advice about everybody. The tier split makes that visible, but only to somebody who looks.

## Questions

### Why not summarise the conversation history into memory automatically?

Some of that happens — a call produces a summary and a relationship story. What does not follow automatically is a *directive*: a summary is a description, and turning descriptions into standing behaviour without a person is how an agent acquires rules nobody agreed to. The viewer exists so the step is deliberate.

### Does forgetting a memory row remove it from past conversations?

No, and it should not. What was said stays in the record; what Connect believes is what changes. Those are different stores answering different questions, which is the whole point of keeping them apart.

### How is memory different from knowledge?

Knowledge is what a workspace supplies for answers to be grounded in — documents, facts, the things a customer asks about. Memory is what is true about a business and its people, and it shapes handling rather than content. A price belongs in knowledge; *this customer always asks for a call rather than an email* belongs in memory.

## Related

- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [Structured business memory instead of a longer prompt](https://connectbyjbrh.com/research/structured-business-memory/)
- [Why the machine proposes a merge and a person disposes](https://connectbyjbrh.com/research/one-person-many-channels/)
- [Making a correction actually change behaviour](https://connectbyjbrh.com/research/memory-correction-that-sticks/)
- [Knowledge in Connect](https://connectbyjbrh.com/docs/knowledge/)

## What this page is based on

- `docs-source/sources/GENERAL.md` §6 — the four memory tiers and `directives()`
- `docs-source/sources/CHANNELS.md` §5 — the relationship story and name scrubbing
- `docs-source/sources/PHONE.md` §4 and §7 — carried context and the block budgets
- Connect capability registry (`docs-source/facts.py`) — `MEASURED`