One round trip, and it has to be the right one
A voice agent cannot afford a second lookup, a re-rank, or a pack full of near-misses. Whatever comes back the first time is what it answers from.
A speech budget is a selection problem
Every other application can paper over bad retrieval with another query. Voice cannot, which is why voice exposes retrieval quality that text agents hide.
There is no second query
A text agent that retrieves badly can search again and nobody notices. A voice agent that retrieves badly either answers from the wrong context or goes quiet — and a pause reads as a fault to the person on the line.
A bigger pack is not a better one
Retrieving more to be safe costs generation time on material the model has to read past. The pack has to be small, which means selection has to be right, not generous.
The caller is the same person as last week
Voice sessions are treated as isolated calls. The person on the line has phoned before, and everything learned that time sits in a transcript store nothing consults during a live call.
Mostly decision context. Then three others.
Every application built on CortexDB is a different mixture of the same five memory jobs. That mixture is what makes this a different piece of software from the one next to it, even though the infrastructure underneath is identical.
Selection weighs state, validity and relationships — not similarity alone
When the budget is fixed, what matters is which memories make it in. Selection weighs whether a memory is still valid and how it relates to what is already in the pack — so a small pack is a sufficient one.
- Fewer, better memories in the window.
- The closest match stops winning by default.
- One assembled pack, not a retrieval stack.
The caller across calls
What was learned on the last call is there on this one, without being re-asked at the top.
What happened last time they rang
The issue, what was done, and how it ended — attached to each other.
The same person on chat and email
One customer memory rather than one per channel.
That is four of the five. The fifth — valid time, two clocks on every memory — leads for employee support, legal and financial operations instead. Same engine, different mixture.
A call is not the only thing you know about the caller
The account, the last ticket, the message thread. A voice agent that only knows the call is starting from the least informative source you have.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,salesforce]'02 Write after the call, not during it
Enrichment does not belong on the speech path. The call ends, the outcome is written, and the next call starts with it.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:voice/caller-8812",
"modality": "observation",
"content": {
"kind": "text",
"text": "Caller asked about the porting delay for the third time. Root cause is the donor carrier, not us — explained and they accepted it. Do not re-explain the process from scratch."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "voice:caller-8812:call-0417"
}'03 Recall once, on a tight budget
The pack is assembled server-side and returned as one context block. There is no second call to make and no re-ranking stage to wait on.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:voice")
pack = client.recall(
scope="ws:voice/caller-8812",
query=caller_utterance,
view="holistic",
include=["facts", "beliefs"],
budgets={"max_tokens": 420},
)
reply = llm.respond(caller_utterance, context=pack["context_block"])pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
Call recordings are the most sensitive channel you operate
Voice carries identity, account details and, frequently, whatever the caller reads out loud to verify themselves. It is the channel where a third-party memory service is hardest to justify to a security review.
CortexDB is a single container. It runs on your own hardware, inside your VPC, or air-gapped — with the embedding and generation calls pointed at a local model if nothing may leave at all.
docker run -d --name cortexdb -p 3141:3141 -v cortexdb-data:/data cortexdb/cortexdb:latestDeployment options, model routing and the enterprise notes are on the download page.
The same infrastructure, a different mixture
Each of these leads with a different memory job, pulls from a different set of sources, and needs a different call. All of them, by job.
Bring the workflow that gets it wrong.
Not the demo. The one that answered from the wrong version, or asked a question it had already been told the answer to.