Memory and context window
The context window is the model's working set for a single call: everything assembled for that one request, gone when it returns. Memory is stored, tiered and editable, and it is what makes the next call know anything. Memory is *selected into* the context window each time, under a budget — which is why remembering more does not mean sending more.
Two different objects#
| Context window | Memory | |
|---|---|---|
| Lives | For one model call | Until somebody deletes it |
| Owned by | The model provider's request | The workspace, in connect_memory |
| Shape | A flat sequence of tokens | Four tiers — workspace, channel, endpoint, contact — resolved narrowest-first |
| Editable | Only by changing what you send next time | Directly, by a person, at any tier |
| Costs | Tokens and first-token latency, every call | Storage, and a share of the budget when it is selected in |
| Fails by | Truncating, or burying the important line among unimportant ones | Being wrong, stale, or never written down |
Both are needed and they are not substitutes. A large context window with nothing stored behind it produces a worker with excellent short-term recall and total amnesia between conversations.
Why 'just send everything' fails#
It fails on latency before it fails on quality, and the effect is measurable. On the voice path, instructions of about 7,500 characters produced a first token in 1.2–1.8 seconds; at about 9,600 characters the same measurement was 2.3–3.4 seconds. That is two thousand characters of prompt costing more than a second of silence while a human being waits on a telephone.
So what reaches the model is budgeted rather than dumped. Knowledge is held to roughly 2,000 characters and four facts; memory to about 700 characters; the contact block to about 600; a human voice profile to about 2,500. Those are not arbitrary caps — they are the point at which another paragraph costs more in delay than it adds in accuracy.
What goes wrong when they are confused#
- "Use a bigger model so it remembers"
- Context length is not persistence. A larger window changes how much can be considered in one call; it changes nothing about the next call, which starts empty.
- Correcting the model in the conversation
- A correction typed into a chat governs that conversation. To change behaviour it has to be written to memory — that is what makes it apply to the next call, on any channel.
- Expecting a forget to be immediate everywhere
- Deleting a memory stops it being selected from then on. It does not reach into a call already in flight, or unsay something already sent.
- Pasting a policy into every message
- This is paying the latency cost on every call for something that belongs in Knowledge once.
- Assuming long chat history is memory
- History is a record for people. What the engine carries forward is memory, and the two are maintained separately on purpose.
How Connect keeps them apart#
tiers()returns everything applying to a 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.directives()reads only the tag list, which is why a block lives intagsasblock:<channel>rather than in the body of a note.- A person can read every tier and delete anything, from the mailbox row, the channel screen or the contact panel.
- Selection into the prompt is budgeted per component, so one long memory cannot crowd out Knowledge.
For the engineering behind the budgets, see what every character of a prompt costs on a live call and structured business memory.
Questions#
If memory is budgeted, how do I make sure something important is used?
Write it at the narrowest tier where it is true. A direction that only applies to one customer belongs on that contact, not at workspace level: narrowest-first resolution means it is both more likely to be selected for that person's work and unable to distort everyone else's.
Is the conversation history sent to the model every time?
What is assembled for a call is bounded, not unlimited. The relevant messages, the grounded facts, the applicable memory and the contact block each have their own share, and the shares exist because latency is paid per character on every call.
Does Connect train a model on what it remembers?
No. Memory is workspace data, read at call time and selected into a prompt. There is no training on customer data, and nothing about a memory changes any model's weights.