Every agent action, with the reasoning still attached
When an examiner asks why an agent did something, the answer has to be a record rather than a reconstruction. That means the reasoning has to have been stored at the time, alongside the action.
A log is not evidence
Most systems record that something happened. Supervision asks why, on what basis, and whether anything was overwritten afterwards.
The action survives and the reasoning does not
The decision is logged with inputs and an outcome. What the agent had in context — and therefore why it concluded what it did — is not retained, so the account of the decision is written afterwards from inference.
Corrections overwrite the thing being examined
A record is amended in place. The version that was acted on no longer exists, which is precisely the version the review is about.
Retention is a policy, not a property
Records are kept because a job runs. Nothing in the storage layer makes deletion or amendment structurally visible, so the absence of tampering can be asserted and not shown.
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
Every write is an immutable event carrying what was observed and when. Nothing is overwritten — a correction is a further event that supersedes, so the state that was acted on remains recoverable.
- The why is retrievable with the what.
- A correction adds a record; it does not remove one.
- What the agent had in context is part of the record.
What the rule was then
Policy and permission changes carry effective dates, so a past action is judged against what governed it.
Supervision reads the same record
The reviewing agent and the acting agent work from one history rather than two accounts of it.
Selection is part of the audit
Which memories entered the pack is itself recorded, so the basis of a decision is inspectable.
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 basis of a decision is spread across systems
The instruction, the approval, the policy it was checked against and the conversation that raised it.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,notion]'02 Write the action and its basis together
One immutable event holding what was done and what it was done on. A later correction supersedes it without erasing it.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:fs/advice",
"modality": "observation",
"content": {
"kind": "text",
"text": "Recommended the balanced portfolio over the growth option because the client's stated horizon was under three years and the suitability policy in force capped equity exposure at 40%."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "advice:client-2214:rec-0091"
}'03 Recall the basis, not a summary
Events, facts and beliefs come back together with their provenance, so an answer to a supervisory question cites rather than reconstructs.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:advice-desk")
pack = client.recall(
scope="ws:fs/advice",
query=supervisory_question,
view="holistic",
include=["events", "facts", "beliefs", "episodes"],
budgets={"max_tokens": 1200},
)
reply = llm.respond(supervisory_question, context=pack["context_block"])pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
Client records and advice are examinable material
Holdings, suitability assessments, and the reasoning behind recommendations. It is the corpus an examiner has a statutory right to inspect, which makes its location and retention a matter of record rather than preference.
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.