Support agents that remember the last time
A senior rep carries three years of an account in their head. An agent fleet starts every conversation at zero — unless what happened last time was written somewhere it can read.
Every ticket is the first ticket
Not “customers repeat themselves.” Three specific mechanisms, each of which leaves a trace you can go and look at in your own helpdesk this afternoon.
The fix is in the transcript, not in memory
The same customer hit this six weeks ago and it was solved. The thread is still in the helpdesk, so it can be searched — but what was tried, what failed, and what finally worked was never stored as an outcome. It cannot be retrieved as experience, so the agent begins the diagnosis again from the top.
Two agents, two truths
The customer tells the chat agent they moved to the legacy plan. An hour later the email agent answers from a billing record that has not synced. Neither agent is wrong about its own source. Nothing in the stack holds the reconciliation, so the contradiction reaches the customer instead.
Forty tickets, one regression
Each ticket is scored against a knowledge base and never against the thirty-nine others open beside it. The pattern is plainly present in the data and structurally invisible to the system — there is no place where one conversation can be evidence about another.
Mostly episodic. 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.
Action, reasoning and outcome stay attached to each other
An episode is not a transcript. It is what was attempted, what it was attempted for, and what happened next — stored together, so the resolution comes back with the problem that produced it.
- The why is retrievable with the what.
- Outcomes return as experience, not as chat history.
- Repeat work is recognised as repeat work.
One memory, many agents
What the chat agent learns, the email agent already knows. Scoped, so shared is not the same as leaked.
Which plan they were on then
Every memory carries when it was true and when you learned it. Expired policy never reaches the agent.
The nearest match stops winning
Selection weighs state, validity and relationships — not similarity alone. A lookalike ticket is not the relevant one.
That is four of the five. The fifth — persistent memory, where preferences and corrections survive the session and the handoff — is what carries assistant and commerce agents instead. Same engine, different mixture.
The sources a support desk already has
Connectors pull; you do not write the sync. Each one lands as an event with a time it was observed and an idempotency key, so a replayed webhook does not become a second memory.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,jira]'02 Write the outcome, not the transcript
The transcript is already in the helpdesk. What is missing is the resolution, stored as something retrievable later.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:support/acme",
"modality": "observation",
"content": {
"kind": "text",
"text": "Renewal card declines were the 3DS step timing out on their gateway. Retry window raised to 40s. Resolved."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "zendesk:acme:44812"
}'03 Recall before replying
Recall returns a pack, not a list of chunks — events, episodes, facts and beliefs assembled into one context block in a single round trip.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:support-chat")
pack = client.recall(
scope="ws:support/acme",
query=inbound_message,
view="holistic",
include=["episodes", "facts", "beliefs"],
budgets={"max_tokens": 900},
)
reply = llm.respond(inbound_message, context=pack["context_block"])pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
Support transcripts are the customer’s data, not yours
A support memory is the highest-PII corpus most companies own: names, order histories, card failures, complaints, and whatever the customer typed in frustration at 2am. That constrains where it may be stored long before it constrains what you can build with it.
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.