Characters that remember the player between sessions
Session state is designed to be thrown away. An agent-driven companion, quest-giver or support bot that is thrown away with it starts every session as a stranger.
Session state is built to be discarded
The infrastructure a game already has is exactly right for state and exactly wrong for memory — which is the difference between what a player has and what a player has done.
State says what the player has, not what happened
Inventory, position and progress restore perfectly. What the player chose, refused, and reacted to — the only material a character could actually remember — is not modelled at all.
Every character is written for a first meeting
Dialogue is authored against progress flags because that is what is durable. The result is a companion that acknowledges chapter three and nothing that happened inside it.
The support agent is a stranger too
A player writes in for the fourth time. The agent sees a ticket, not a two-year account with a history of the same crash.
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 character knows about a player is stored as durable and revisable, outside the session that produced it — so it survives a disconnect, a patch, and the gap between one play session and the next.
- Learned in session 1, still there in session 40.
- A later choice replaces the assumption it contradicts.
- The next character never re-asks.
What the player actually did
The choice, the context and the consequence held together, so a character can refer to it rather than to a flag.
A cast, not a set of bots
Several characters drawing on one memory of the player instead of each keeping its own.
Only what this scene needs
A long history is narrowed to the part that belongs in this moment.
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.
The community is part of the player record
Support threads, community channels and bug reports are where players say the things that never reach telemetry.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,jira]'02 Write the choice, not the flag
A boolean records that something happened. What a character needs is what it meant.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:player/7c93",
"modality": "observation",
"content": {
"kind": "text",
"text": "Spared the smuggler at the bridge despite the crew arguing for it, and has avoided lethal options in every branch since. Reads as a deliberate playstyle, not a one-off."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "player:7c93:choice-bridge"
}'03 Recall before speaking
A small assembled pack, so a character's line is informed by the player's history without a round trip the frame budget cannot afford.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:companion")
pack = client.recall(
scope="ws:player/7c93",
query=scene_context,
view="holistic",
include=["facts", "beliefs", "episodes"],
budgets={"max_tokens": 450},
)
reply = llm.respond(scene_context, context=pack["context_block"])pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
Player records are personal data with a young user base
Play history, chat, purchases and social graph — frequently belonging to minors, which raises the standard rather than lowering it. Where this memory lives is a compliance question before it is an architecture one.
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.