Giulio D'Erme's count (0 of 152 memos declaring a validity window) is the most damning detail here. The write path is where this usually dies: the model writing a memory at time T has no way to know it will be superseded later, so nothing populates the edge. The only fix I've seen hold up is moving supersession to write time. When the agent records a new fact, it first looks up what it might be replacing and has to either link it or explicitly declare nothing found. That lookup can't fail silently either, or you're back to the PostgreSQL/MongoDB case. Have you found a way to keep that write-time lookup cheap, or does it just add a retrieval call to every write?
Developer educator and advocate who still ships code. 15 years teaching developers at MongoDB, Heroku, Cisco, and Treehouse. Now writing about AI-assisted development, agent memory, and provenance.
I think you're putting this at the right boundary, and this is actually where my thinking has moved since writing the piece. A proposed durable write shouldn't necessarily be treated as an isolated insert. Part of admission should be asking what existing knowledge this write might supersede, correct, contradict, or invalidate.
I wouldn't make that an unconditional full retrieval call for every write, though. I'd treat it as part of Write-Side Custody and let the proposed claim determine the lookup scope. If the write has a stable subject, claim type, authority domain, or other addressable identity, the custody layer should be able to narrow the candidate set considerably before doing semantic comparison.
The explicit nothing found is important too, with one qualification: I'd want to preserve what was actually searched. Otherwise "no predecessor found" can mean either "there wasn't one" or "we looked in the wrong place." That's the negative-space problem that has come up in another thread.
So I think the invariant is stronger than "look before every write": a consequential durable write should establish its relationship to the relevant existing knowledge before admission, or explicitly record that the relationship could not be established.
And yes, there is a cost. But I'd rather pay some of that cost once at the admission boundary than repeatedly ask every future retrieval to rediscover relationships the system could have established when the new knowledge arrived.
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.
Giulio D'Erme's count (0 of 152 memos declaring a validity window) is the most damning detail here. The write path is where this usually dies: the model writing a memory at time T has no way to know it will be superseded later, so nothing populates the edge. The only fix I've seen hold up is moving supersession to write time. When the agent records a new fact, it first looks up what it might be replacing and has to either link it or explicitly declare nothing found. That lookup can't fail silently either, or you're back to the PostgreSQL/MongoDB case. Have you found a way to keep that write-time lookup cheap, or does it just add a retrieval call to every write?
I think you're putting this at the right boundary, and this is actually where my thinking has moved since writing the piece. A proposed durable write shouldn't necessarily be treated as an isolated insert. Part of admission should be asking what existing knowledge this write might supersede, correct, contradict, or invalidate.
I wouldn't make that an unconditional full retrieval call for every write, though. I'd treat it as part of Write-Side Custody and let the proposed claim determine the lookup scope. If the write has a stable subject, claim type, authority domain, or other addressable identity, the custody layer should be able to narrow the candidate set considerably before doing semantic comparison.
The explicit
nothing foundis important too, with one qualification: I'd want to preserve what was actually searched. Otherwise "no predecessor found" can mean either "there wasn't one" or "we looked in the wrong place." That's the negative-space problem that has come up in another thread.So I think the invariant is stronger than "look before every write": a consequential durable write should establish its relationship to the relevant existing knowledge before admission, or explicitly record that the relationship could not be established.
And yes, there is a cost. But I'd rather pay some of that cost once at the admission boundary than repeatedly ask every future retrieval to rediscover relationships the system could have established when the new knowledge arrived.