Remembering a caller's language
When a person has been spoken to before, what they speak is kept with their other facts and carried into the next call's brief. Connect speaks it from its first reply rather than waiting for proof, and a whole sentence from the caller in another language is what overrides it. The fact competes for space in a contact block capped at 600 characters.
A remembered preference is a fact about a person#
It travels the way every other durable thing Connect knows about somebody travels: with the person's record, resolved from the number that rang, rendered into the call brief before the call starts. voice_engine.brief() puts the contact's facts and standing instructions in front of the model once per call, and this is one of those facts.
Two consequences follow immediately. It is visible and editable wherever the person's facts are, rather than hidden in call machinery. And it is subject to the same identity resolution as everything else — if the number resolves to the wrong person, it brings the wrong preference with it. Identifying the caller covers that resolution and its edge cases.
What remembering actually does#
This is the rule worth carrying away: a remembered preference is what Connect replies in from its first reply, and a whole sentence in another language is what moves the call off it. Knowing something about a person is not permission to hold them to it. The person who rang last month in Telugu may be ringing from a colleague's phone, may be with a customer, may simply want English this time — and one whole sentence of English is all it takes to be answered in English for the rest of the call.
- On the record
- The preference is in the brief from the first second of the call.
- In the conversation
- It is what the replies are in, starting with the first. A whole sentence from the caller in another language overrides it, and the call then stays in theirs.
- Never
- It is not switched mid-sentence, scripts are not mixed unless the caller mixes them, and it does not override a pinned code, which is an engine setting no evidence steers.
The cost of getting this wrong is asymmetric, which is why the override needs a sentence rather than a word. A borrowed greeting or agreement word — *haan*, *okay* — proves nothing about the rest of what somebody wants to say, while a whole sentence is unambiguous. Note that this bar belongs to the remembered tier alone: where the language is only *likely*, inferred from the contact's city or state, two or three words move the call instead.
It costs characters, and characters cost seconds#
Everything in the brief is paid for in first-token time. The measured difference between a 7,500-character instruction set and a 9,600-one was 1.2–1.8 s against 2.3–3.4 s to first token — so the brief is built to budgets rather than assembled from everything available.
| Block | Budget |
|---|---|
| Contact facts | 600 characters |
| Memory | 700 characters |
| Knowledge | 4 facts, 2,000 characters |
| A human voice profile | under about 2,500 characters |
A preference is a short fact and fits easily. The point of showing the budget is the opposite case: a contact whose facts have grown into paragraphs will crowd out the useful line, and nothing warns you — the call simply starts a little slower and knows a little less. The call brief is where that assembly is described.
Correcting one#
Find the person's record rather than the call.
Result The fact lives with them, so correcting it on one call would not travel; correcting it on the person does.
Edit or remove the fact.
Result The next call's brief is rendered from the corrected record.
If the line should never move at all, pin the code in the Voice Lab instead.
Result A pinned call is never steered, so no remembered fact and no evidence changes it.
Questions#
Does Connect learn what somebody speaks automatically?
Yes, on any call that may use memory. Once the caller has settled into a language it is saved once as preferred_language, along with speaking_style if they mix languages. These two are latest-wins facts: a later call replaces the earlier value rather than keeping the first, which is the opposite of how most facts merge.
Will a returning caller be greeted in their preference?
The greeting is pre-synthesised audio chosen before the call connects, so it follows the line's own configuration rather than the person. A remembered fact shapes the conversation after the greeting, not the greeting itself.
Can a customer workspace use this, or is it operator-only?
Both audiences run the same implementation here — the phone brief, the contact block and its budgets are one body of code with two doors. Nothing about this behaviour is reserved for the operator's own workspace.