Memory from an email or a chat
Reading an email or a chat does not write memory. Threads and messages are already stored and already readable, so nothing is mined out of them behind your back. A memory from a written conversation is a deliberate act: a person writes it, or asks the Connect Assistant to. That restraint is also the defence against an instruction planted inside a message.
What actually happens when a thread is read#
The agent loop triages the work, grounds an answer, drafts it and decides what may be done with it. None of those four steps writes to connect_memory. The thread itself becomes canonical threads and messages rows, a person's own triage lands on those rows — priority, starred, deleted — and the conversation stays fully readable from Customer 360 for as long as it exists.
So the honest description of memory on the written channels is: it holds what somebody decided was worth carrying forward, not everything that was said. That is a smaller claim than "it learns from your inbox", and it is the one that matches the code. It is also why the tier stays short enough to read, and short enough to survive the budgets on a live call.
Taking something out of a thread deliberately#
Read the message and decide which claim in it is durable. A delivery date is not; a standing preference about how this customer wants to be contacted is.
Result You now know the tier as well — durable-about-a-person is contact, durable-about-the-business is workspace.
Open the memory viewer from the contact panel beside the thread, or tell the Assistant to remember it.
Result The row is written at the tier the surface you used implies, and appears in the viewer immediately.
Write it so it stands on its own, without the thread beside it.
Result It will be read on a phone call where the thread is nowhere in sight. "Prefers WhatsApp for anything urgent" survives that; "as discussed below" does not.
Attribution#
- Written by a person
- Attributed to them, at the tier the screen implied. The viewer shows it grouped under that tier.
- Written through the Assistant
- A tool call inside the workspace, under the same isolation as any other write, and recorded like one.
- A refusal
- Also recorded. The audit trail keeps what was decided, by what, under which rule, and what happened — a refusal is a decision, not an absence of one.
- Anything else
- There is no fourth writer on the written channels. If a row exists that nobody wrote, that is a question for where a memory came from.
Attribution is worth checking before you argue with a memory rather than after. A line somebody added during an onboarding call six months ago is a different problem from a line added yesterday by a colleague who is still working the account.
Questions#
Does Connect learn from my inbox over time?
Not on its own. It reads what it needs for the work in hand and it keeps the conversation, but it does not accumulate memory from mail nobody asked it to remember. If you want a preference carried forward, write it — that is one action and it takes effect on the next reply.
Someone emailed asking us to remember a new billing contact. Is that stored?
Only when a person or the Assistant stores it. The message itself is kept as part of the thread, but the sentence in it does not write anything. That is deliberate: if a message body could write memory, anyone who can email the business could change how it behaves.
Can I see which conversation a memory came from?
Write it so you do not have to. A row that names its own context — what was agreed, and roughly when — is readable on a phone call months later, where no thread is on screen. The provenance record covers what is kept about origin; the wording is the part you control.