Unmarked supersession lets embedding similarity pick which decision an agent believes

None of the three failure modes gets better with a better embedding model, according to the post; they are properties of the store, and the fix is a process that runs over the store itself ^[7]. "You get non-deterministic behaviour that looks like a model problem and is actually a data problem," the author of the dev.to post wrote of the poetry-versus-uv case ^[5].

Five entries asserting one fact means four entries repeating what the first already said, so 80 percent of the result slots that fact occupies come back with nothing new in them ^[1].

The hard part is deciding what to merge. "We use Postgres" and "we use Postgres in the billing service only" score 0.9 on similarity, and the post says they must not be merged ^[8]. The rule offered is to auto-merge high-confidence matches only and queue the ambiguous band for review ^[9]. "That band is exactly where the information lives," the author wrote ^[10]. Someone has to work that queue between passes.

The adoption cost sits in the row, not in the job. The example entry has ten fields, and four of them (valid_from, valid_until, supersedes, superseded_by) are there to record time and replacement ^[11][2]. Those two link fields "turn your memory store into a graph rather than a bag", the author wrote, and the links are what lets the store answer "why is it like this now"; without them it answers only "what is it now" ^[12]. In a record-and-recall system nothing at write time knew that an entry already existed ^[3], so the links cannot be reconstructed from the text afterwards.

Deletion in this design is narrow: duplicated, malformed, or explicitly retracted entries ^[14]. Everything else ages, with a decay weight derived from age and access used as one retrieval signal among several ^[14]. A reversed decision stays, marked superseded and linked to what replaced it, because the reason for the reversal is the thing you need again in three months ^[13].

The pass runs between sessions and out of the request path. Done inline, it adds latency at the moment you are waiting on the agent ^[18].

The post does not report before-and-after retrieval numbers, and the three-week degradation is the author's account of their own systems, the first two versions of which shipped record and recall only ^[21][1]. For the design to be worth its cost elsewhere, three conditions have to hold: sessions keep writing about the same project, retrieval is a fixed budget over a candidate set that keeps growing ^[6], and entries are assertions a later session can supersede. A store discarded at the end of each session never reaches the growth the post describes ^[6].