Agents that pick up where they left off
Session forty should not ask what session one was told. Preferences and corrections have to outlive the context window, the process, and the handoff to the next agent.
The context window is not storage
Everything an assistant appears to know about you is re-sent every turn and then discarded. Making the window bigger makes that more expensive, not more durable.
Nothing survives the process
Close the session and the accumulated understanding goes with it. What is left is a transcript — recoverable in principle, unusable in practice, because nothing in it is marked as a thing worth keeping.
A correction does not replace anything
You correct the agent. Now both the wrong version and the correction exist as text in the history, adjacent and equally retrievable. Nothing records that one supersedes the other, so the wrong one can come back.
The next agent re-asks
Hand the task to another agent and it starts from the transcript. Every preference that was learned is in there somewhere, unlabelled, competing with everything else that was ever said.
Mostly persistent. 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.
Preferences and corrections survive the session and the handoff
A preference is not a message. It is stored as something durable and revisable, so it can be recalled in month twelve, corrected in month thirteen, and still carry the record of both.
- Learned in session 1, still there in session 40.
- A correction replaces what it corrected.
- The next agent never re-asks.
What is still true about you
A preference stated last year is marked as stated last year, so a stale one can be told apart from a current one.
What it did for you before
The task, the approach and how it landed stay attached — so “do that again” has a referent.
Only what this turn needs
The whole picture of a person is not useful context. Selection narrows it to the part the request is about.
That is four of the five. The fifth — shared memory, one store many agents read and write — leads for sales and customer success instead. Same engine, different mixture.
The things an assistant is expected to already know
Most of it is not in the conversation. It is in the calendar, the inbox, the notes app and the threads the person is already living in.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,notion]'02 Write the preference, not the sentence
What is stored is the durable thing that was learned. The turn it came from is an event; this is what outlives it.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:user/8f21",
"modality": "observation",
"content": {
"kind": "text",
"text": "Prefers morning flights and will pay up to 20% more to avoid a connection. Corrected an earlier note that said price was the priority."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "assistant:8f21:pref-travel-004"
}'03 Recall what is still in force
The pack comes back already assembled — the current preference, not the whole history of stating it.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:assistant")
pack = client.recall(
scope="ws:user/8f21",
query=user_request,
view="holistic",
include=["facts", "beliefs", "episodes"],
budgets={"max_tokens": 700},
)
reply = llm.respond(user_request, context=pack["context_block"])pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
This is the most personal corpus on the list
An assistant memory is a longitudinal record of one person’s habits, relationships, health, money and movements. It is the corpus where “where does this run” stops being a procurement question and becomes the product question.
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.