How we spent three hours chasing a bug through five layers of Node.js to teach Vektor Memory that time moves forward.
Ask your AI assistant what kind of coffee you like. It probably knows. Now tell it you switched to tea three months ago. Come back next week and ask again.
It will ask you about coffee.
This is not a memory problem in the way people usually mean it. The agent is not forgetting. It is remembering too much, too indiscriminately, with no ability to tell the difference between what you believed then and what is true now. Both facts sit in the database with equal weight. Both get recalled. The agent hedges, or guesses wrong, or surfaces context that was accurate in February and is actively misleading in May.
Every agent memory system that has existed for longer than a few months hits this wall. The database grows. Old preferences, abandoned projects, reversed decisions, corrected assumptions, all of them accumulate alongside everything current. The signal-to-noise ratio degrades slowly enough that you might not notice it happening, but it is happening. Your agent is getting dumber as its memory gets bigger, because no one taught it that time moves forward.
The technical term for what is missing is supersession. The idea that when new information replaces old information, the old version should be marked as replaced rather than left sitting there competing for attention. It is how version control works. It is how medical records work. It is how human memory is supposed to work, even if it often does not. And until this week, it was the one thing VEKTOR did not do.
There is a specific kind of frustration that comes from debugging a system that is working perfectly and also completely failing to do the one thing it was built to do.
VEKTOR has stored over eight thousand memories. It recalls across sessions, compresses during REM cycles, links facts through a knowledge graph, and surfaces the right context at the right time. It has been doing all of this reliably for months. But until this week, it had a quiet, embarrassing problem buried inside all of that machinery: it kept accumulating contradictions.
Store “User prefers dark mode” in January. Store “User switched to light mode” in March. Both memories sit in the database, equally valid, equally retrievable. The agent has no way of knowing that the second one cancels the first. Every recall surfaces both. The agent hedges. It asks clarifying questions it should not need to ask. It makes decisions based on information that is no longer true.
This is the problem supersession chains were designed to solve. And this week, after implementing the feature and watching it do absolutely nothing for two full sessions, we finally got it working.
The Feature
Supersession is conceptually simple. When a new memory arrives that is semantically similar to an existing one, instead of keeping both, VEKTOR marks the old one as superseded by pointing it at the new one. The old memory gets a superseded_by column filled in and a timestamp. Active recall filters it out with WHERE superseded_by IS NULL. The chain is preserved for provenance. You can always walk backwards through what an agent believed at any point in time.
The implementation lives in vektor-dedup.js, a module that wraps the memory object in a Proxy, intercepts every remember() call, runs a recall against existing memories to find near-duplicates, and marks the closest match as superseded before writing the new one.
The code was correct. The schema migrations were idempotent. The thresholds were configured. The module exported exactly what it was supposed to export.
It just never ran.
The Debug
The first thing we did was add a diagnostic log inside wrapMemory. A single line writing to stderr whenever the dedup logic touched a memory store call. Then we started the MCP server and stored a test memory.
Nothing.
Not a crash. Not an error. Not a silent failure that left a trace somewhere. Just nothing.
The handover document from the previous session had predicted exactly two possible failure modes: either db was null at runtime, or recall was returning an empty candidates array. We had added a log that would distinguish between them. The log never fired.
This is where the debugging got interesting.
The MCP server starts with vektor mcp in a terminal. That command boots a process, loads the intelligence layer modules, wraps the memory object in a chain of proxies, and starts listening for JSON-RPC calls from Claude Desktop. Somewhere in that chain, the dedup wrap was supposed to intercept memory writes. It was not.
We added logs higher and higher up the call stack. We checked that the file existed. We checked that the module exported correctly. We confirmed that wrapMemory was being called at the right point in the boot sequence.
Then we looked more carefully at the boot output.
[vektor-dxt] Found vektor-slipstream at: C:\nvm4w\nodejs2\nodejs\node_modules\vektor-slipstream
That path was not the path we had been patching.
The Real Problem
VEKTOR’s MCP server does not load through vektor.mjs when running under Claude Desktop. It boots through vektor-slipstream-dxt/server/index.js, a separate DXT entry point with its own intelligence layer boot sequence. The wrap chain we had been editing in vektor.mjs was completely irrelevant. Claude Desktop never touched it.
Become a Medium member
The DXT server had its own wrap chain. It loaded BM25 recall, recall tuning, and a few other modules. Dedup was not in the list. It had never been in the list. The feature had been implemented correctly in the wrong file.
We added the dedup wrap to the DXT boot sequence. Restarted. Stored a memory.
Still nothing.
This time the catch block was eating the error. The DXT server wraps every intelligence module load in a try/catch with an empty catch body, which is a reasonable defensive pattern for optional modules except that it makes debugging feel like shouting into a room and hearing no echo at all.
We switched the catch to write errors to a log file instead of stderr, because Claude Desktop’s MCP process runs in a subprocess and its stderr goes nowhere visible from a PowerShell window. This revealed the actual error:
SyntaxError: Invalid or unexpected token
An earlier SSH patch to add the diagnostic log had written escaped quotes inside a template literal. The string \"ok\" is valid in JSON but not in a JavaScript template literal. The file had a syntax error. Node refused to load it. The catch swallowed the failure. The module was silently missing from the wrap chain on every boot.
We fixed the syntax error. Restarted. Stored a memory. Checked the log.
DEDUP BLOCK REACHED
Progress. But the supersession still was not firing. The candidates array had five entries with similarity scores around 0.10 to 0.12. The threshold was set to 0.95. The filter rejected all five.
The 0.95 threshold had been calibrated for cosine similarity between embeddings, where similar memories score between 0.85 and 1.0. But the dedup module calls recall on the wrapped memory object, and by the time dedup runs, the memory object has already been wrapped by the BM25 layer. BM25 returns keyword overlap scores, not cosine similarity. The score range is completely different. A threshold designed for embeddings will never fire against BM25 output.
We dropped the threshold to 0.09. Restarted. Stored “User prefers Node.js for coding,” a memory similar to an existing “User likes Node.js to code.”
[vektor-dedup] db=ok candidates=5
Then:
[8119...] -> 8128.0... at 2026-05-08T01:53:30.000Z
"User prefers Node.js for coding."
It worked.
What This Means for VEKTOR
Supersession chains close a gap that has existed in every memory system we have built. Without them, memory is append-only. The database grows. Contradictions accumulate. The agent retrieves both sides of a preference change and cannot know which one is current without asking.
With supersession chains active, VEKTOR’s memory behaves more like a person’s memory is supposed to behave. Old beliefs get replaced by new ones. The replacement is recorded, not deleted. You can trace what the agent knew at any point in time, but active recall only surfaces what is currently true.
For agents running long sessions, this matters more than almost any other memory feature. A VEKTOR instance that has been running for six months has seen preferences change, projects complete, decisions reverse. Without supersession, every one of those changes sits in the database alongside the thing it replaced. With supersession, the database reflects current state. Old context is archived, not surfaced.
The practical effect is fewer clarifying questions, better decision quality on preference-sensitive tasks, and a memory store that stays usable at scale rather than becoming increasingly noisy as it grows.
What Shipped in v1.5.4
This release completes four new recall and memory features we started in v1.5.3:
Query prefixing enriches embeddings at recall time by prepending structured context to the query before vectorizing, which meaningfully improves semantic retrieval for short or ambiguous inputs.
Parallel detail pass runs a secondary recall sweep after the initial results are scored, fetching full memory content for the top candidates rather than relying on indexed summaries. Slower but more accurate for complex queries.
HyDE recall channel generates a hypothetical answer to the query and uses that as an additional recall vector, which helps surface memories that are semantically related but do not share surface-level vocabulary with the original query.
Supersession chains replace accumulated contradictions with a forward-pointer structure. Old memories are marked superseded rather than deleted. Active recall filters them out. The chain is preserved for inspection.
The first three shipped and worked immediately. The fourth took three sessions and five layers of debugging to get right. That is sometimes how code debugging goes via live iterations from the floor. Irritating and confusing, but in the end resolved.
The full changelog and install instructions are at vektormemory.com.
VEKTOR is a local-first AI agent memory system. One-time purchase, no subscriptions, your data stays on your machine. If your agents keep forgetting things they should already know, that is the problem VEKTOR was built to solve.
Top comments (0)