The Silent-Data-Loss Taxonomy: Four Ways Your Agent's Write Disappears — agent-coherence blog

Contact us

← Blog<br>agent memory<br>July 5, 2026<br>7 min read

The Silent-Data-Loss Taxonomy: Four Ways Your Agent's Write Disappears

by Vladyslav Parakhin

You want a self-learning agent. It reads the shared plan, distills a lesson from what just happened, and writes the lesson back so the next run starts smarter. That loop is the whole promise of agent memory: the system that runs today should be a little better tomorrow because it wrote down what it learned.

The hard part showed up last time. In the previous post I walked through a single learning that vanished from exactly that loop. Two sessions shared one memory. Both read the plan, both distilled, both wrote back, and the store logged two clean successful writes. One learning was still gone. The agent had “forgotten” something it demonstrably wrote down, and the store had no error to show for it.

That post fixed one bug. This post is about the fact that the same symptom has four different causes, and they are not the same bug. “The write succeeded but the data is gone” is not a diagnosis. It is a category. If you cannot name which member of the category you hit, you cannot know whether it is prevented today or whether you are one compaction pass away from losing it again.

The line that organizes this

Here is the split. Sometimes the write hit the wrong target, or something dropped it after the fact. The coordinator never sees those. The bytes went somewhere, or a later step ate them, and no coherence protocol was ever in a position to object. You find these by looking at a trace. They are the application’s job.

Other times the write hit the right target and a coherence race corrupted the outcome anyway. Two actors on one key, or one actor writing from a view that went stale underneath it. These the coordinator can see, because they turn on version and ownership of a specific key. You stop these at write time.

Detect-side versus prevent-side. That is the spine. Two members you detect after the fact and fix in your own code. Two members you prevent at the moment of the write. Every “vanished learning” lands in one of the four, and knowing which one tells you where to look and whether the fix already exists.

The four members

Member<br>What you see<br>Cause<br>Prevented or detected

Key mismatch<br>Clean write to X, reader queries Y, fact never appears<br>App routing: writer and reader disagree on key/namespace<br>Detected (read/write trace: “wrote X, never read X”)

Compaction drop<br>Fact goes in, then disappears at a summarization boundary<br>Lossy consolidation step overwrites or drops it<br>Detected (trace shows loss at the compaction tick)

Concurrent lost-update<br>Two writers, same key, same base version, one silently overwrites the other<br>Read-modify-write race on shared state<br>Prevented on one host by version-CAS (write_cas)

Stale-read then write<br>Peer commits a newer version, agent writes from its old view<br>Sequential: agent’s view went stale before its write<br>Prevented on one host by MESI invalidation-deny plus reacquire

Now walk the self-learning loop through each one.

Key mismatch. Your distiller writes the lesson under memory/session-42/lessons. Your reader, three commits of refactoring later, loads memory/lessons/session-42. The write is real. The store logged it. The bytes are sitting at the key you wrote. The reader is standing at a different key asking why the shelf is empty. No race happened here. The coordinator was never involved, because nothing about versions or ownership was violated. What catches this is a trace that carries both the write key and every read key: you see “wrote memory/session-42/lessons, never read memory/session-42/lessons” and the mismatch is right there. The fix is key discipline in your own code. The coordinator does not fix this and does not pretend to.

Compaction drop. The lesson lands correctly. Then a memory-consolidation pass runs. It compresses older entries to keep the context window affordable, and while summarizing it drops the line your lesson lived on, or folds it into a summary that no longer contains the fact. The write succeeded. The consolidation lost it. Again there is no race and no coherence violation on any key. A trace shows the fact present after the write and absent after the compaction boundary, which points you straight at the consolidation logic. That is where the bug lives and that is where you fix it. The coordinator never sees a compaction step eat a fact.

Concurrent lost-update. This is last time’s bug. Two sessions, one memory key, both read version 7, both distill, both write. The store applies them in some order and the second overwrites the first. Both writes return success. One lesson is gone, and nothing errored. Here the coordinator is in the loop, because the collision is on a real key with a real version. On a single host, version-CAS prevents it: each writer submits the base version it read, write_cas...