# What Connect remembers about a person

What Connect knows about one human lives at the narrowest of four memory tiers — workspace, channel, endpoint, contact — and the narrowest that applies wins. A fact gets there because somebody told Connect, or because a conversation produced one; it is read into every answer for that person; and anyone with access can read the tier and forget any line in it.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/inbox, #/calls
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/relationships/person-memory/

## Four tiers, narrowest first

```text
workspace  →  channel  →  endpoint  →  contact
```

This is the same hierarchy autonomy uses, which is not a coincidence: what Connect knows and what Connect may do are both questions that get more specific as you get closer to one human. `tiers()` returns everything that applies to one piece of work, split by the tier that owns it — and an empty tier is returned rather than dropped, so *nothing is set here* is a visible answer instead of an absence you have to infer.

A line about one human belongs at the last of those. A line about how this business talks to everybody belongs at the first. Putting a general policy on one person is the common mistake — it works for that person and quietly fails for the next.

## How something gets remembered

| Route | Who does it | Notes |
|---|---|---|
| The memory viewer on the contact panel | A person | Mounted from the contact panel, the channel screen and the mailbox row |
| The Assistant's `remember` tool | Connect, when asked | The Assistant's rights stay narrower than a person's |
| A conversation that produced a durable fact | Connect | Written with the name guard applied to the title and the body |
| A standing instruction for this person | A person | Read back as a directive rather than as prose |

Everything written here passes the name guard, so a stored line cannot end up addressing somebody by an honorific it mistook for a name — the same rewrite described on [the relationship summary](/docs/relationships/relationship-story/).

## Tags are the machinery, not decoration

> **Careful** `directives()` reads only the tag list. A block on a channel is a memory row against that human tagged `block:<channel>` in `tags` — never a sentence in the body. *Do not contact this person by WhatsApp* written as prose reads perfectly to a human and stops nothing.

That design is what makes a block hold across channels and across future conversations: it is not a flag on a thread, and it is not a column on the person that a merge or an import could quietly drop. It is a row, at the narrowest tier, read every time an answer is prepared.

It also means a merge is a moment to check. [What a merge preserves](/docs/relationships/merge-safety/) lists what carries across, and memory is worth reading on the surviving record before Connect answers on that channel again.

## Reading and forgetting

1. Open the memory viewer from the contact panel.
   - Result: You see every tier that applies to this human, each labelled with the tier that owns it — not a merged blob you have to unpick.
2. Read the lines at the narrowest tier.
   - Result: These are the ones specific to this person, and the ones most likely to be shaping an answer you did not expect.
3. Forget a line.
   - Result: It stops being read into answers. Removing a line is a person's action; the Assistant can be asked to forget one, and it cannot clear a do-not-contact entry.
4. Check what an answer will actually carry.
   - Result: Only a budgeted extract reaches a live answer — around 700 characters of memory, and up to three standing instructions in [the contact brief](/docs/relationships/contact-brief/).

The budget is the reason a tidy tier beats a full one. Fifty lines at the narrowest tier do not all reach an answer; a handful of specific, current ones do, and they are the ones you want competing for that space.

## Questions

### Is memory the same as the notes on a person?

No. Notes are text on the record; memory is a set of rows with tiers and tags that Connect resolves before answering. A directive — a block, a standing instruction — only works as memory with the right tag, because that is what `directives()` reads.

### Does a customer's memory ever reach another workspace?

No. Memory rows carry a workspace like nearly everything else, and isolation is enforced three times over — the customer allowlist, the ORM kernel, and row-level security in the database.

### If I forget something, is it gone from past answers?

Forgetting changes what future answers read. What was already said stays on the record, because the [timeline](/docs/relationships/timeline/) reports what happened rather than what Connect currently believes.

## Related

- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [The contact brief](https://connectbyjbrh.com/docs/relationships/contact-brief/)
- [The relationship summary](https://connectbyjbrh.com/docs/relationships/relationship-story/)
- [What a merge preserves](https://connectbyjbrh.com/docs/relationships/merge-safety/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [The customer timeline](https://connectbyjbrh.com/docs/relationships/timeline/)

## What this page is based on

- `docs-source/sources/GENERAL.md` §6 — memory tiers, `tiers()` and `directives()`
- `docs-source/sources/GENERAL.md` §3 — blocking as a tagged memory row
- `backend/app/connect_memory.py` — the name guard applied on write
- `docs-source/facts.py` `MEASURED` — the memory budget