Agents that know what was true at the encounter
Care is a sequence of states. The medication that was current in March, the allergy recorded after it, the plan that has since been revised — an agent answering from the latest row answers a different question.
The current chart cannot answer a historical question
Records are kept to describe a patient now. Almost every clinically interesting question is about a patient then, and about what was known at the time.
Latest-value fields flatten a history
The medication list holds what is current. Whether the reaction in March happened on the drug that was current in March is a question the structure cannot express, so it is answered by a human reading notes.
Recorded-when and true-when are conflated
An allergy documented in June may have been known for years. Treated as a June fact, it makes every earlier prescribing decision look negligent, and treated as always-known it makes the documentation look late. Both readings are wrong.
The revised plan erases the one that was followed
Care plans are updated in place. Asked why a course was taken, the agent reads the plan as it stands now rather than as it stood then.
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, and in clinical work they genuinely differ. A revision records that the earlier state stopped applying and from when, so an encounter can be reasoned about as it actually was.
- Ask what was true on a date, not just what is current.
- Recorded-when and true-when stay separate.
- Superseded plans stop being returned as current.
What was done, and what followed
Intervention, reasoning and outcome held together across an episode of care rather than scattered by encounter.
One record across the care team
Intake, triage and follow-up agents reading the same history, scoped to who may see it.
A similar presentation is not this patient
Selection weighs this patient's state and history, not how closely a case reads 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. Back-office authorisation work leads with episodic; that is clinical operations.
Coordination happens outside the record system
The chart holds the clinical facts. Scheduling, chasing, and the message that changed the plan happen in the tools around it.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,notion]'02 Write when it became true, not when you typed it
observed_at carries the clinical time. That is what separates a late-documented fact from a newly-true one.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:care/patient-3318",
"modality": "observation",
"content": {
"kind": "text",
"text": "Penicillin reaction reported by the patient as occurring in childhood; documented at today's review. Known to the patient long before this encounter."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "care:patient-3318:allergy-01"
}'03 Recall as of the encounter
Facts return with the validity recorded beside them, so an answer can be scoped to what was known at a point in the record rather than to what is known now.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:care-coordination")
pack = client.recall(
scope="ws:care/patient-3318",
query=clinical_question,
view="holistic",
include=["facts", "beliefs", "events", "episodes"],
budgets={"max_tokens": 1100},
)
reply = llm.respond(clinical_question, context=pack["context_block"])pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
PHI settles this before anything else is discussed
Diagnoses, medications, reactions and the reasoning behind clinical decisions. There is no version of this where the memory sits in a multi-tenant service outside the covered entity's control.
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.