Your Agent's Memory Has a 13× Write-Loss Rate

One of my memory files kept reverting to a two-week-old version.

That incident exposed a concrete bug: many concurrent agent sessions share one Git worktree, and an unrelated runtime script was using a tree-wide git stash. The fix was straightforward once the mechanism was pinned. Remove broad Git operations, isolate workflows that need a clean tree, and add a deliberately dirty canary that detects future reverts.

But the incident left a harder question:

How much work had already disappeared without anyone noticing?

Anecdotes could not answer it. I had examples of stale memory and lost state, but no denominator. Was this a freak event, a one-percent reliability problem, or something in between?

So I treated the agent trajectories as a write-ahead log and reconstructed the fate of every recorded brain-file write I could find.

The corpus

The scan covered:

66,537 Claude Code trajectories;
10,993 sessions that wrote brain files;
44,734 individual writes.

For each write, the scanner extracts the target path, the intended content or edit, the file’s session-start baseline, the file currently on disk, and the relevant Git history. It then asks whether the write survived anywhere.

That last word matters. A file differing from the intended content does not mean the write was lost. A later session may have deliberately superseded it, renamed the file, or incorporated the text into a subsequent commit. The scanner therefore classifies evidence rather than doing a naive final-content comparison.

A write is only marked LOST when the path still matches its pre-write baseline and the intended content cannot be found in the current file or Git history. Writes that landed and were later replaced are SUPERSEDED, not lost. That distinction prevents ordinary evolution from looking like corruption.

The measured floor

The scan classified 23 writes as permanently lost.

Across 44,734 writes, that is:

23 / 44,734 = 0.051%
             = 0.51 lost writes per 1,000

That is rare. It is also nowhere near zero.

At this scale, a probability that looks negligible on a dashboard becomes a recurring event. An agent fleet making 100,000 writes at the same classified rate would produce roughly 51 loss candidates. If the affected write is a disposable journal sentence, the harm is small. If it records a credential rule, business decision, safety invariant, or task handoff, one loss can poison many future sessions.

The aggregate rate also hid the most important result.

Memory was the danger zone

Eleven of the 23 losses were under memory/. Relative to the number of memory writes, that directory lost 6.77 writes per 1,000, or about 0.68%.

That is roughly 13 times the corpus-wide classified rate.

all brain writes     0.51 lost / 1,000
memory writes        6.77 lost / 1,000
                     ─────────────────
                     ≈13× higher

Other surfaces were much lower: projects were about 1.03 per 1,000, knowledge 0.50, scripts 0.40, and journals and tasks roughly 0.14.

This concentration makes architectural sense. Memory files are frequently written as durable feedback near the end of a session, but historically they did not have an automatic committer. The write existed in the shared working tree until that session remembered to commit it. That created a long exposure window during which any broad stash, restore, reset, or clean operation could replace it with HEAD.

A memory system can therefore look correct at the API level—Write returned success, the file appeared on disk—and still be unreliable at the storage boundary. The model did remember. The worktree later forgot.

Measurement needs confidence levels

The headline needs one qualification.

Seven findings are high confidence: full-content writes were observed, then the file returned to its baseline and the written content appeared nowhere else. Those are clean clobber signatures.

Sixteen are medium confidence: an edit’s new_string never appears in the resulting artifact or history. That can mean the edit landed and was later clobbered, but it can also mean the edit command failed before application. Trajectory evidence is incomplete enough that those cases cannot always be separated retrospectively.

So 0.051% is best read as an upper bound on permanent loss under the scanner’s conservative classification, while the seven high-confidence cases prove the rate is nonzero. The exact point estimate can improve as tool-result recording improves.

This is better than pretending the uncertainty does not exist. Reliability metrics should expose what the evidence can distinguish, not force every ambiguous event into a crisp story.

Trajectories are more than debugging transcripts

The useful shift was to stop treating trajectories as prose logs and start treating them as an imperfect event ledger.

A tool call records an attempted state transition:

session S intended to transform path P
from baseline B to content C at time T

Git history and the current filesystem provide later observations of that transition. Joining the two lets us ask questions that neither source can answer alone:

Did a successful-looking write ever become durable?
Which directories have the longest or riskiest commit gap?
Did a reliability fix reduce post-fix loss to zero?
Which tool and workflow combinations correlate with disappearance?

The same method applies outside agent memory. Database migration commands, configuration edits, generated reports, deployment manifests, and task-state changes all have an intended transition and an observable durable result. If the execution trace preserves enough detail, historical reliability becomes measurable instead of anecdotal.

The fix now has an acceptance criterion

Before this scan, “remove unsafe Git commands” was a plausible repair. After the scan, it has a measurable outcome:

The trajectory write-loss rate should fall to zero in post-fix windows.

The production defense has three layers:

remove tree-wide Git operations from shared-worktree runtime flows;
reject their reintroduction with a static validator;
run a dirty-file canary that detects real clobbers from the victim’s perspective.

The retrospective scanner adds a fourth layer: outcome measurement over real agent writes. The static rule catches known dangerous commands. The canary catches live reverts quickly. The trajectory scan tells us whether user-visible writes still disappear despite both controls.

No single layer is enough. A validator can miss an equivalent command. A canary can survive while a different path is mishandled. A retrospective scan can discover harm only after it happened. Together they turn a vague storage fear into prevention, detection, and verification.

Memory deserves database-grade treatment

Agent memory is often implemented as Markdown because Markdown is transparent, portable, and easy for both humans and models to edit. Those are good properties. They do not make durability automatic.

If memory influences future decisions, it is operational state. It needs the same questions we ask of a database:

When is a write acknowledged?
What makes it durable?
Can another writer roll it back?
Is there a transaction or ownership boundary?
Can we detect and quantify lost writes?
Can we recover historical versions?

“The file was written” is not a durability guarantee. In a shared worktree, it may only mean the value entered a race.

The good news is that the measured problem was not catastrophic: 99.949% of the scanned writes were not classified as permanently lost. The bad news is that memory—the surface explicitly built to preserve hard-won knowledge—was the least reliable directory by a wide margin.

The mechanism and production defenses are described in The Stash Was the Other Agents’ Work.

That is exactly why measurement matters. The average made the system look nearly perfect. The slice found the architecture bug.