Agents that can show what was known at the time
Every question a reviewer asks about a decision is a question about the past: what the desk knew, what the policy was, and who was permitted to act — at the moment it happened, not now.
Reconstruction after the fact is not evidence
The systems hold the current state extremely well. The question is almost never about the current state.
Current state cannot answer a historical question
The limit was raised in June. Asked whether a March position breached it, the system compares against today's limit and returns a confident, wrong answer — because the earlier value was replaced rather than superseded.
The rationale lived in a conversation
Why the position was taken was argued in a thread and summarised in nobody's system of record. The trade is fully documented; the reasoning that produced it is not.
Permissions moved and the record did not
Who was authorised to approve at a given size, on a given desk, on a given date, is recoverable only by asking someone who was there.
Mostly valid time. 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.
Every memory carries when it was true and when you learned it
Two clocks. A limit change, a mandate revision or a permission move is recorded as a change with an effective date — so “as of 14 March” stops being a reconstruction exercise and becomes a query.
- Ask what governed on a date, not just what governs.
- Revisions keep their provenance instead of replacing it.
- Withdrawn mandates stop being returned as current.
The decision and what followed it
What was done, on what reasoning, and how it turned out — one memory rather than three systems.
Research, execution and compliance
Three functions reading the same record instead of reconciling three.
A similar instrument is not this one
Selection weighs mandate, desk and date, not how closely two descriptions read alike.
That is four of the five. The fifth — persistent memory, where an individual's preferences and corrections survive — leads for assistant and commerce agents instead. Same engine, different mixture.
The record is spread across conversation and system
The order is in one place. The mandate that permitted it, the thread where it was debated, and the approval are in four others.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,notion]'
02 Write the change with the date it took force
observed_at is when the thing became true, not when it was indexed. That single distinction is what makes the record answerable later.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:desk/rates",
"modality": "observation",
"content": {
"kind": "text",
"text": "Single-name concentration limit for the rates book raised from 3% to 5% of NAV, effective from the June mandate review. Supersedes the 3% limit in the prior mandate."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "mandate:rates:2026-06:rev-4"
}'
03 Recall what governed
Facts return carrying the validity recorded beside them, so an answer can name the instrument it relied on rather than assert a number.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:desk-research")
pack = client.recall(
scope="ws:desk/rates",
query=review_question,
view="holistic",
include=["facts", "beliefs", "events"],
budgets={"max_tokens": 1100},
)
reply = llm.respond(review_question, context=pack["context_block"])
pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
Positions and rationale are the two things that never leave
A desk memory holds strategy, limits, and the reasoning behind trades that have not closed. There is no framing in which that is acceptable in a shared multi-tenant service.
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:latest
Deployment 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.