Writing a memory, end to end

The chain, stage by stage#

1. Trigger — a person writes a memory from the viewer, or asks the Assistant to remember something, or accepts a durable point Connect drew out of a conversation or a call.
2. User event — the wording is a person's. Connect proposes; it does not quietly promote an offhand sentence in an email into a standing direction.
3. Authentication and workspace resolution — memory belongs to a workspace before it belongs to a tier, and the write happens inside the resolved workspace or not at all.
4. Request — the write names its tier: workspace, channel, endpoint (one mailbox or one number), or contact. Anything ambiguous is stored at the narrowest scope the evidence supports.
5. Canonical record — a connect_memory row, carrying its text, its tags and its provenance: who said it, where it came from, and when.
6. Reasoning — none is required to store one. This is a deliberate write, which is why it can be read back word for word rather than paraphrased.
7. Knowledge, memory and rules — a directive is expressed as a tag, not as prose. directives() reads only the tag list, which is why a block lives in tags as block:<channel> and never in the body.
8. Autonomy and approval — writing a memory changes what Connect knows, not what it may do. Autonomy modes are untouched by it, and a memory cannot grant an action a mode forbids.
9. Action — no provider is called. A memory is internal by definition; nothing about writing one reaches a customer.
10. Result — the row appears in the memory viewer under its tier, with its provenance, mounted from the mailbox row, the channel screen and the contact panel.
11. Relationship, timeline and memory — a contact-tier memory attaches to the person, beside their timeline rather than inside it: what Connect knows is not something that happened.
12. Audit, usage and Needs You — the write is recorded with its author. Nothing is queued, because a memory needs no approval to exist.

Choosing the tier is the whole decision#

The four tiers are workspace, channel, endpoint and contact, and they resolve narrowest-first: the most specific one that applies wins. Autonomy uses the same hierarchy, which is worth knowing because it means one mental model covers both what Connect knows and what it may do.

A memory written too broadly is the common mistake, and it is quiet: one customer's preference stored at workspace tier changes every reply the business sends, and nobody connects the two afterwards. Storing at the narrowest scope the evidence supports costs nothing and is trivially widened later.

What the row carries, and why provenance matters#

Every memory keeps where it came from. Months later the useful question is rarely "what does Connect think" but "who told it that, and were they in a position to know" — a direction from the business owner and a sentence a customer wrote in passing are both true records and are not equally binding.

Directives are the exception to prose. A block on a contact is a tag, block:<channel>, in the tag list — never a sentence in the body saying not to write to them. The reason is mechanical: the code that enforces directives reads only tags. A perfectly clear instruction written as prose is a note, and a note stops nothing.

The first reply that changes#

A memory takes effect on the next piece of work in its scope, not retroactively. A draft already written is not rewritten, a message already sent is history, and an approval sitting in Needs You still holds the words it was created with — regenerating it is what pulls in the newer context.

On the phone the constraint is sharper, because everything the model carries must fit inside a live conversation. The context budgets are small and deliberate: about 700 characters of memory, around 600 for the block describing who is calling. A short, specific memory survives that; a paragraph of background may not.

1. Write it, then trigger the smallest piece of real work in that scope — one reply on that channel, or one conversation with that contact.

   Result You see the memory applied to a real draft rather than trusting that it will be.

2. If nothing changed, check the tier before rewording anything.

   Result A memory at contact tier does not affect another contact, and a narrower memory elsewhere may be outranking the one you wrote.

3. If it is a directive, check it is a tag.

   Result Blocking, in particular, only works as block:<channel> in the tag list. Prose describing the same intention is read by nobody.

Questions#

Related#

• The four memory tiers
• How a memory is created
• Where a memory came from
• Block and guidance directives
• Superseding a memory, end to end
• Seeing what Connect knows
• Knowledge and memory
• How memory reaches a reply