A returning caller
On a second call the number resolves to a person, and their facts, standing instructions and a slice of memory are rendered into the brief before anyone speaks. Far less reaches the model than the workspace holds: 600 characters of contact facts, 700 of memory, four knowledge facts. That cap is a latency decision, and it is also what stops a call opening with a recital of somebody's file.
What is already there when the phone rings#
Nothing is looked up mid-conversation. voice_engine.brief() runs once, before the call, and puts the persona, the line's purpose, the person's facts and standing instructions, knowledge, the hard rules and any supervisor guidance in front of the model in one go. The worker itself holds no business logic at all — it carries audio and posts events.
So a returning caller is not recognised *during* the call; they were recognised before it started, by number. Everything downstream depends on that having worked, which is why identifying the caller matters more than it looks — a missing normalised key turns a regular customer into a stranger with no error anywhere.
Two of the facts that travel this way are about *how* to talk rather than what to say. Where an earlier call was allowed to use memory, Connect saved preferred_language once the caller had settled into one, and speaking_style — which languages they mix, and how much — if they mix. On this call the remembered language is what Connect replies in from its first reply, not something it waits for proof of, and only a whole sentence in another language moves it. Both are latest-wins facts: the most recent call's value replaces the older one, where most facts keep the first value they were given.
The budget, and what it protects#
A workspace may know a great deal about somebody. Very little of it belongs in a live conversation, and the limits are enforced rather than suggested:
| Block | Cap | Why it is capped there |
|---|---|---|
| Contact facts | 600 characters | Enough for who they are and what is outstanding |
| Memory | 700 characters | Durable things about the relationship, not a history |
| Knowledge | 4 facts / 2,000 characters | Grounding for answers, not the whole source |
| A human voice profile | under ~2,500 characters | The person the voice is, which competes for the same budget |
The measured reason is blunt: 7,500 characters of instructions gave a 1.2–1.8 s first token and 9,600 gave 2.3–3.4 s. Every extra fact about a returning caller is paid for by that caller, in silence, on every reply. The second reason is conversational — a voice that opens by reciting what it knows about somebody is unsettling, and it is also the fastest way to say something that was true last month.
Continuity without a performance#
The 2026-09-06 gap audit is the clearest evidence of what good continuity sounds like. Across production calls the instructions were changed so that the opening is treated as already said and each reply carries one thought and one question under 25 words. Re-introductions went from one to four per call down to none, the median words per reply moved from 23–40 to 19, stacked questions went to zero, and the reply median sat at 2.9 s with no latency regression.
Long calls get a small structural help: an anchor note every 12 turns, delivered as a chat-context turn rather than a prompt resend. It exists because a long conversation drifts from what it was originally about, not because the model forgets the caller.
The cost of remembering, literally#
A live session is re-billed for its entire context on every turn, and production calls run at about 92% carried context by input token. History in a phone call is not a one-off charge; it is a subscription paid per reply, on audio tokens that cost roughly four times the text rate on input.
Context compression exists (brief.COMPRESSION_TRIGGER_TOKENS and _TARGET_TOKENS) and is *sized* rather than defaulted — the default trigger is the model's whole context window, which means it does not fire on its own. What a call costs sets out the metering, and session limits and long calls covers what happens when a conversation runs long.
What is verified today#
This was reconciled on 2026-09-10 against backend/app/voice_region.plan at f5ea518. Matching is unchanged: the number resolves to the oldest record sharing it. What is settled now is the language side — remembered, spoken from the first reply, overridden only by a whole sentence, and saved latest-wins on any call that may use memory. A returning caller with nothing remembered but a city or state on file is a different case again: that language is likely, not assumed, and two or three words in it are enough. The budgets and the measured cost of exceeding them were never part of that work.
Questions#
Will Connect mention our last conversation?
Only if something from it is in the facts or memory that fit the budget, and only where it is relevant to what is being discussed. There is no instruction to demonstrate recall, and there is a hard instruction not to re-introduce — a call that opens by proving it remembers you is the failure mode the gap audit removed.
Can I control what Connect brings into a call about one customer?
Yes — the contact's facts and standing instructions are the lever, and they are ordinary editable records. A standing instruction is the right place for "always ask about the outstanding invoice"; a fact is the right place for something durable and short.
Does a long relationship make calls slower?
It would, which is exactly why the caps exist. What reaches the brief is bounded regardless of how much is on file, so a ten-year customer and a new one start a call with instruction sets of a similar size.