Fewer things in the window, and better ones
A research agent’s failure is rarely forgetting. It is retrieving twelve plausible sources when three were relevant, and spending the window on the other nine.
Twelve plausible things, three relevant ones
Every one of these is a selection failure, not a storage failure. The right material was in the index the whole time.
Similarity is not relevance
The nearest vector is a document that shares vocabulary with the question and answers a different one. It wins because vector distance is the only thing being scored, and nothing else about it is being weighed.
The window fills with near-duplicates
Five sources restating one finding crowd out the single source that contradicts it. Ranked by similarity they are five strong results; as evidence they are one, and the disagreement is what mattered.
Evidence gets separated from the claim
A conclusion survives into the next step; where it came from does not. Nothing downstream can check it, so an early error propagates with the same confidence as a verified one.
Mostly decision context. 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.
Selection weighs state, validity and relationships — not similarity alone
Retrieval is not a nearest-neighbour lookup with a bigger k. Candidates are weighed on whether they are still valid, how they relate to what is already in the pack, and what the decision in front of the agent actually needs.
- Fewer, better memories in the window.
- The closest match stops winning by default.
- Evidence travels with the memory.
What this line of enquiry already tried
Dead ends are recorded as dead ends, so the same search is not run a third time.
Superseded findings stay superseded
A retracted or revised source keeps its history and stops being returned as current.
What the other agents found
A parallel fleet contributes to one body of work instead of five overlapping ones.
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 corpus is usually already yours
Internal research is scattered across the places people wrote it down, and almost none of it is addressable as one body of evidence.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,notion]'
02 Write the finding with what it rests on
A claim stored without its evidence is a claim that cannot be checked later. The provenance is part of the memory, not metadata beside it.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:research/retrieval",
"modality": "observation",
"content": {
"kind": "text",
"text": "Hybrid BM25 + dense retrieval beat dense alone on the internal eval by 9pp. Measured on the 500-question set, not the public split — do not quote externally."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "notion:research:retrieval-eval:2026-08"
}'
03 Recall on a budget
The budget is the point. A pack that fits is a pack the model can actually use, and forcing selection to choose is what makes it choose well.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:research")
pack = client.recall(
scope="ws:research/retrieval",
query=research_question,
view="holistic",
include=["facts", "beliefs", "episodes", "events"],
budgets={"max_tokens": 1200},
)
reply = llm.respond(research_question, context=pack["context_block"])
pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
Unpublished research is the thing you least want in someone else’s index
Internal evals, negative results, and the reasoning behind decisions that were never announced. A research memory is a concentrated record of what an organisation knows and has not said.
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.