The supersede thread under this article got me checking my own setup, and my version fails at a different step: not recall, but the write. A correction written from a different angle does not just fail to link to the old entry, it can paraphrase the mistake into a new entry that reads as fresh insight. Supersede semantics cannot catch that, because the new entry never claims to replace anything. What I started doing in my agent memory protocol work: at write time, retrieve top matches for the new note, and if a stored entry contradicts it, force an explicit choice, update, supersede, or reject the write. The cost is one extra retrieval per write. The gap it leaves: contradictions phrased so differently that embeddings do not see them as related, which no amount of read time filtering will fix either.
Building persistent memory for AI agents at Mnemoverse.
I write about the unglamorous half: forgetting, contradiction, and the moment an agent confidently repeats a fact you retracted.
The write-time check is the right place for it, and the gap you name at the end is the one I would worry about first, for a slightly awkward reason. A correction often sits closer to the mistake than an honest paraphrase does, because it reuses the same words and flips one of them. So a similarity check at write time is most likely to read the most exact corrections as near-duplicates of the thing they correct, and the reject branch is where they would quietly disappear. Before rejecting, it is worth asking the writer which of the three it meant.
For contradictions that embeddings do not see as related, more similarity will not help. What helps is a second key written with the note: the thing it is about, such as the file, the config key or the API name. Two notes about the same config key are candidates for a conflict whatever words they use, and that lookup does not depend on the embedding at all.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The supersede thread under this article got me checking my own setup, and my version fails at a different step: not recall, but the write. A correction written from a different angle does not just fail to link to the old entry, it can paraphrase the mistake into a new entry that reads as fresh insight. Supersede semantics cannot catch that, because the new entry never claims to replace anything. What I started doing in my agent memory protocol work: at write time, retrieve top matches for the new note, and if a stored entry contradicts it, force an explicit choice, update, supersede, or reject the write. The cost is one extra retrieval per write. The gap it leaves: contradictions phrased so differently that embeddings do not see them as related, which no amount of read time filtering will fix either.
The write-time check is the right place for it, and the gap you name at the end is the one I would worry about first, for a slightly awkward reason. A correction often sits closer to the mistake than an honest paraphrase does, because it reuses the same words and flips one of them. So a similarity check at write time is most likely to read the most exact corrections as near-duplicates of the thing they correct, and the reject branch is where they would quietly disappear. Before rejecting, it is worth asking the writer which of the three it meant.
For contradictions that embeddings do not see as related, more similarity will not help. What helps is a second key written with the note: the thing it is about, such as the file, the config key or the API name. Two notes about the same config key are candidates for a conflict whatever words they use, and that lookup does not depend on the embedding at all.