Handoffs that carry the account, not a summary of it
Coverage changes. The account does not. Whatever the last CSM knew has to be readable by whoever picks it up — and by every agent working the account beside them.
A health score is a number without a reason
Success work is almost entirely context, and the systems that support it are almost entirely fields.
The score moved and nobody can say why
It went from green to amber. Which conversation, which unanswered thread, which quiet month moved it is not recorded — so the response is a guess dressed as a workflow.
The renewal risk was said out loud, once
On a call, by someone who has since changed teams. It is in a recording that nobody is going to re-watch, and in no other place at all.
Support and success keep separate histories
The same customer is two different customers depending on which agent you ask. Neither is wrong; there is simply nowhere the two records meet.
Mostly shared memory. 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.
One memory, many agents
Every agent on the account reads and writes one scope. Not a copy per agent, not a summary passed at handoff — one store, with scopes deciding who may see what.
- No per-agent silos to reconcile.
- Scoped: shared is not the same as leaked.
- Handoffs carry context, not a summary of it.
What was tried on this account
The escalation, the QBR, the workaround — and how each one landed.
Who the sponsor is now
People change roles. An org chart from onboarding cannot answer a renewal question.
What they told you once
A constraint stated in month one is still in force in month twenty without anyone re-asking.
That is four of the five. The fifth — decision context, where selection weighs state and validity rather than similarity — leads for research and coding agents instead. Same engine, different mixture.
The account's history is already being recorded
Tickets, calls, threads and CRM activity. All of it exists; none of it is addressable as one account.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,salesforce]'02 One agent writes
The monitoring agent records something that explains a movement, against the account rather than against itself.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:success/acme",
"modality": "observation",
"content": {
"kind": "text",
"text": "Sponsor moved to a new team in July; the replacement has not attended a QBR. Two support escalations in the same period went unanswered by the customer."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "salesforce:acme:activity-7712"
}'03 A different agent reads
Same scope, different actor. The renewal agent never saw any of that happen and starts with all of it.
from cortexdb.v1 import V1Client
# a different agent on the same scope
client = V1Client(api_url="http://localhost:3141", actor="agent:success-renewal")
pack = client.recall(
scope="ws:success/acme",
query=renewal_brief,
view="holistic",
include=["episodes", "facts", "beliefs"],
budgets={"max_tokens": 1000},
)
reply = llm.respond(renewal_brief, context=pack["context_block"])pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
An account memory is candid about named people
Who is disengaged, who blocks decisions, which sponsor left and why. It is exactly the material that is useful internally and damaging if it leaves.
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.