Person memory
Contact memory is what Connect knows about one person: preferences, constraints, the things somebody would want a colleague to remember before picking up the phone. It is the narrowest tier, so it outranks the other three, and it belongs to the person rather than to an address — which is why it applies on a call to somebody you have only ever emailed.
It attaches to a person, not an address#
A Person is a human in the workspace's relationships; an Identity is one address on one channel that resolves to that person. Contact memory hangs off the person. The practical effect is that a note written while working an email thread is in front of Connect on a WhatsApp reply and on a phone call, without anything being copied between channels.
The condition is identity resolution. A caller whose number has never been linked to anybody has no contact tier — not an empty one by mistake, but genuinely none, because there is no person yet to hold it. On the phone this is the ordinary case for a first-time caller, and it is why the first thing a call does is try to identify who is speaking. A number that resolves to two rows is resolved to the oldest, so a duplicate does not silently create a second, emptier person.
What belongs on a person#
- Preferences
- The channel they prefer, the language they are comfortable in, whether they want detail or a summary.
- Constraints
- Hours they may not be contacted, an accessibility need, a request to route everything through a colleague.
- Relationship facts
- Their role, what they are responsible for, which of your products they actually run.
- Standing instructions about them
- "Always copy their operations manager", "never discuss the renewal with this contact".
- A block
- Not a sentence but a tag — see block and guidance directives. A prohibition written as prose is a note; written as a tag it is enforced.
What does not belong is the conversation itself. Threads, messages and call transcripts are already stored and already readable from Customer 360. Restating them as memory makes the tier long without making it more useful, and length is the one thing the call path cannot absorb.
The budget on a live call#
On the realtime voice path, voice_engine.brief() renders the persona, the line's purpose, the contact's facts and standing instructions, the knowledge and the hard rules once per call. Three of those carry explicit character budgets, and the contact block is the tightest one that concerns a person.
| Part of the brief | Budget | Why it is capped there |
|---|---|---|
| Knowledge | 4 facts / 2,000 characters | Retrieved material is the largest and most variable part of an instruction |
| Memory | 700 characters | Carried on every call whether or not it is used |
| Contact block | 600 characters | Read on every turn as part of the whole context |
| A human voice profile | about 2,500 characters | A persona is 86 parameters rendered as prose; past this the first token slips |
A Live session is re-billed for its entire context on every turn, and production calls are 92% carried context by input token. So the contact block is not only a latency decision, it is a cost decision repeated once per reply. Six hundred characters is roughly a short paragraph — enough for who this person is and what matters about them, not enough for their history.
Names are guarded on the way in and the way out#
A person's name is the one field that damages a relationship when it is wrong, and voice is where it is most easily corrupted: a transcript hears a form of address as a name, or a summariser reports "the caller" as though it were one. identity.PROTECTED_MARKERS, together with name_rejected, clean_name and scrub_names, guards every door a name passes through — summariser output, lead capture, person upsert and connect_memory.remember — and every door it is read back through.
fact_rejected refuses a name-keyed fact whose subject is a suffix, a pronoun or "the caller". The visible result is that Connect would rather hold no name for a person than hold a wrong one, and will ask again on the next contact rather than address somebody by a word it misheard.
Questions#
Does contact memory follow somebody who emails from a new address?
It follows the person, so it holds as soon as the new address is resolved to them. Until that happens the new address is an unrecognised identity with no contact tier behind it. Linking the identity — or merging a duplicate person record — restores the memory immediately, on every channel.
Why was a long note about a customer not used on a call?
Most likely the 700-character memory budget or the 600-character contact block. Both are hard caps on the realtime path, chosen because instruction size is measurably a latency decision. Shorten the note to the part that changes what Connect would say, and move the background to Knowledge or leave it in the conversation history where it already lives.
Can a customer ask what Connect knows about them?
Everything at the contact tier is readable in the viewer and in the memory sheet of the Data grid, and any of it can be forgotten. Answering such a request is a matter of reading one person's tier and acting on it — reviewing everything Connect knows about a person walks through it.