How we spent three hours chasing a bug through five layers of Node.js to teach Vektor Memory that time moves forward. 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 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 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 The Real Problem Become a Medium member 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 We fixed the syntax error. Restarted. Stored a memory. Checked the log. DEDUP BLOCK REACHED 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 [8119...] -> 8128.0... at 2026-05-08T01:53:30.000Z What This Means for VEKTOR 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 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.