Search

A memory is useful only if the right record comes out on top. post-cortex searches by meaning, by words and through the graph at once, then lets you choose how much work goes into the ranking: fast and free, more exact on your own CPU, or most exact with an outside model.

Search misses exactly what you need

An agent asks the memory in the words of the moment: “why did a stored session get wiped when it could not be loaded?” The record that answers it was written weeks earlier in other words: “a load error was read as ‘no such session’, and an empty session overwrote the stored one”.

Search by words (grep, BM25) does not find it: the two share almost no words. Search by meaning (vectors) finds it, but often below dozens of records that sound alike. And the agent reads only the first few results.

So post-cortex searches in several ways at once, and then orders the result.

How post-cortex searches

1. By meaning. Every record has a vector (Model2Vec: multilingual, milliseconds per text, no GPU). The query is compared with every record in scope.
2. By words. BM25 finds the exact words: function names, error codes, file paths, where vectors are weak.
3. Fusion. The two rankings are fused (Reciprocal Rank Fusion): a record high in both comes out on top.
4. The graph. Within one session, the best hits start a walk over the graph (Personalized PageRank) that adds records neither words nor meaning reach. See the memory graph.
5. Reranking. In the local and accurate modes the first 300 candidates are ordered again by a model that reads the query and each record together (a cross-encoder). This is the most expensive step and the most exact one.
6. Neighbours. Every hit comes with the records right before and after it in its session, because an answer is often split across two records in a row.

Three modes

The mode is chosen on every search; when a search names none, the server’s default is used.

Mode	Reranks with	Evidence in the top 50 (LoCoMo)	Multi-hop questions	Time (p50)	Where the data goes
fast	nothing	0.803	0.426	~40 ms	nowhere
local	a local cross-encoder (MiniLM-L4, int8, on the CPU)	0.879		~1 s	nowhere
accurate	Voyage rerank-3-lite	0.937	0.809	~0.4 s	to Voyage, only where the workspace allows it

The numbers come from the last full LoCoMo run (10 long conversations, 1,535 questions), in October 2026; local from the last run that measured it, two days earlier. “Evidence in the top 50” is the share of questions whose answering record is among the first 50 results, with their neighbours.

The gap is widest on multi-hop questions: from 0.426 with fast to 0.809 with accurate. That is where the answer sits in a record that does not look like the question.

Voyage is off by default. accurate sends the query and the candidates to Voyage only in a workspace that allows it, and a new workspace does not. Without that, accurate uses the local reranker of your own daemon. The hosted cloud runs no local reranker: there local, and accurate without Voyage, return the fused ranking, as fast does. Every answer says whether it was reranked, so a fast answer is never taken for an exact one.

What every result shows

Asked to, every result shows why it is there: its place by meaning, by words and in the graph, the fusion, and the reranker’s score. This is the first result for the question above, in fast mode, from our own memory, a design note about streaming transfers. It is not the right one:

Signal	Value
place by meaning	23rd (similarity 0.538)
place by words	15th
after fusion	1st (0.774)
final score	0.842

It is in the middle of both lists, and fusion puts a record that is fairly high in both above one that is very high in only one. The right record is 29th.

Every result also carries:

• its author: an agent, a person or a team member; search can filter by author or prefer your own records;
• whether it still holds: an ended record ranks lower and says why it ended (see facts change; history stays);
• its neighbours, each marked with the hit it belongs to.

Filters

Each is an option of the same search:

• scope: one session, a workspace (every session of the project) or everything;
• record type: decisions, fixes, requirements, …;
• author, or a preferred author, which only lifts its own records a little;
• period (from, to);
• newer first, by how much: at half strength a year-old record keeps about 61% of its score; good for recent bugs, not for documentation;
• source: the records, the raw conversations, or both;
• how much text: a passage around the query’s words, or the whole text.

Limits

• fast misses paraphrases. The question at the top of this page, asked of our own memory in fast mode, puts the right record 29th of 30. Reranking exists for exactly this, at a price: time (local, on your own daemon), or money and data leaving your servers (accurate).
• The numbers come from one benchmark. LoCoMo is conversations, not code; on your project they will differ. That is why every result can say what ranked it, and you can check.

What it solves

• It finds an answer written in other words. Meaning and reranking connect the question with the record without shared words.
• It finds the exact name. BM25 catches persist_and_wait, E0502 or crates/post-cortex-memory/src/persister.rs, where vectors drift.
• It does not serve old knowledge as new. Ended records stay, but rank lower and say why.
• You choose the cost. Fast and free, more exact on your own CPU, or most exact with an outside model, search by search.

For agents and scripts, every option of a search: the search tool and the REST API.