Most agent memory systems answer a retrieval question by calling a model. A query rewriter, an LLM reranker, sometimes a summarizer over the candidates.
That's several round trips before the agent has read anything, and the cost grows with how much you have stored.
Decispher Memory is the preference plane we attach to a person, a project, or a company: use pnpm, staging is 5433, don't touch the retry wrapper.
It is not the team's decision record. It is the things you already say out loud, once, so the next session on Claude Code, Cursor, Codex, or Grok doesn't start cold.
The read path that injects those memories has no generative call in it.
When a coding agent starts a prompt, the hook embeds the prompt once, then runs four retrieval signals in parallel:
- dense — semantic similarity against memories and their triggers
- lexical — text matches against memories and triggers
- tag — structured metadata overlap
- symbol — overlap with symbols in the files currently open
The signals are fused on rank position rather than score magnitude. The underlying scores aren't directly comparable.
Ranking, time gating, and selection are deterministic after that. The result is bounded, and the keystroke path cannot make another model call.
Richer surfaces that already sit inside a tool call — a briefing, an explicit MCP query — can optionally rerank.
The practical consequence is the part we care about:
The amount of context and model work per prompt stays bounded as the corpus grows.
Ten years of Slack threads and PR arguments shouldn't mean ten years of context for every prompt. The model only ever sees the fixed top slice.
What we measured
We measured the retrieval plane on LongMemEval-s because it is the public benchmark people quote, not because it looks like an engineering team.
500 questions, roughly 124k words of haystack per question, small reader model (gpt-4.1-mini), LLM judge:
- Context reduction: 38× median (p10 31×, p90 53×, min 25×). Mean 3,181 tokens served against a 123,973 token haystack. Every question above 10×.
- Accuracy on knowledge-update questions, where a fact changed and the current value must win: 90%
- Accuracy overall: 84%
That last number is not a win and we are not going to dress it up.
On a separate oracle split, we fed the same reader and judge the raw gold transcript instead of our payload. Accuracy was at parity with 36% of the tokens.
So what we've measured is a token-efficiency result, not a retrieval-quality result.
Off-the-shelf dense RAG is a hard baseline to beat on this benchmark.
A long chat-history benchmark is also not the shape of Memory in production. Production memories are short, scoped, and conflict-resolved in code.
We publish the changed-fact number because that is the case a memory system exists for.
On the site we also report a 2.7× cut against handing the model the raw history under a different packing. That is not the same measurement as the 38× haystack-to-payload ratio above.
We also measured the benchmark's own test-retest noise by accident. Two copies of the harness scored 215 questions twice at temperature 0: 12 verdict flips, 5.6%.
On 500 questions, nothing under about 2 points is readable. Most published deltas in this category are smaller than that.
Where it is actually good
The changed-fact case (90%) is the strongest result.
The symbol signal is also interesting because it requires the system to index your code.
A file that declares StripeClient can pull the note about why you mock it.
A memory store that only sees chat cannot compute that.
Where it is weak
Single-session preference is still weak. That's the subtype the extractor exists for, and it is different from single-session recall, which is high.
Aggregation questions — count, sum, duration — were bad enough that deleting that path was worth 4 points, so we deleted it.
Those go through a model on purpose.
Looking for design partners
Decispher Memory is in early access, and we're working with a small number of engineering teams.
We're looking for teams already using coding agents heavily who are running into the same problem: the agent knows how to write the code, but keeps needing the same project and engineering context explained again.
We're particularly interested in people who will tell us when a served memory is wrong, stale, or simply none of the agent's business.
That's more useful to us right now than another signup.
If this sounds like your team: https://decispher.com/memory
Happy to answer anything about the retrieval design, the benchmark harness, or the things that didn't work.
Top comments (0)