Agents that remember what the customer actually responds to
Every campaign starts over. The channel that worked last time, the offer they ignored twice, the constraint they stated in March — all of it is in the logs and none of it is in the agent.
Every campaign is a cold start
The evidence exists. It was aggregated into a dashboard, and the individual-level learning that produced it was discarded on the way.
The profile is fields, not learning
A CRM row holds attributes — plan, city, lifetime value. What it does not hold is that this person has left six emails unopened this quarter and replies on WhatsApp within the hour. That is the only fact that would change what the agent does next.
Last cycle's evidence became a report
Channel and timing performance were rolled up, charted, and acted on at the segment level. At the level the agent actually operates — this contact, this message — the fleet re-derives everything from scratch each cycle.
A stated constraint expires silently
“Don’t contact me before 11” is honoured inside the session it was said in. There is no mechanism that carries it into the next campaign, so it is re-violated and re-stated until the customer stops replying.
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
What a customer responds to is learned slowly, across months and channels. It has to be stored as something durable and revisable, not re-inferred from a rolling window of recent activity.
- Learned in campaign 1, still there in campaign 40.
- A correction replaces what it corrected.
- The next agent never re-asks.
What was sent, and what happened
The offer, the channel, the hour, and whether it landed — attached to each other rather than counted separately.
The offer they declined is not the offer now
Pricing and eligibility move. A refusal recorded against last quarter's terms should not suppress this quarter's message.
Not everything known belongs in this message
Selection narrows a long history to the part this send is actually about.
That is four of the five. The fifth — shared memory, one store that a whole fleet reads and writes — leads for sales and customer success instead. Same engine, different mixture.
The response evidence is already being collected
Every send, open, reply and silence is logged somewhere. None of it is currently addressable as one memory of a person.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,salesforce]'02 Write the preference the evidence supports
Not the event. The durable conclusion the events add up to — which is the thing the next campaign needs to read.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:customer/9f14",
"modality": "observation",
"content": {
"kind": "text",
"text": "Replies on WhatsApp within the hour; six promotional emails unopened this quarter. Stop sending promotions by email to this contact."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "whatsapp:9f14:msg-88213"
}'03 Recall before composing
The pack comes back as the current picture of this customer, not the full history of arriving at it.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:lifecycle")
pack = client.recall(
scope="ws:customer/9f14",
query=campaign_brief,
view="holistic",
include=["facts", "beliefs", "episodes"],
budgets={"max_tokens": 700},
)
reply = llm.respond(campaign_brief, context=pack["context_block"])pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
Contact preferences and purchase history are personal data
A commerce memory is a per-person record of what someone bought, when they were contacted, and how they reacted. In most jurisdictions that is regulated data with a retention clock and a deletion obligation attached.
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.