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.
Four tiers, narrowest first#
workspace → channel → endpoint → contactThis 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.
Reading and forgetting#
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.
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.
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.
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.
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 reports what happened rather than what Connect currently believes.