# The write-side half of agent memory

> Thirty agent-memory products describe how agents remember. Not one describes what happens when two writers hit the same key. The lost update is the half that breaks production.

Published: 2026-07-04 · Author: Vladyslav Parakhin · Canonical: https://agent-coherence.dev/blog/write-side-half/

---
Agent memory had a good year. Retrieval accuracy is a benchmark race now. Session persistence is table stakes. Your agents can recall a decision from three weeks ago, across tools, across machines, with citations. The recall half of memory is getting built, and built well.

Then two of your agents touch the same record in the same minute, and one update is gone. No exception. No conflict warning. Two successful writes in the log, and one of them erased the other.

Here is the shape of it. An enrichment agent reads an account record: plan, usage, owner. A triage agent processes the morning inbox, finds a cancellation email, and writes "churned" to the same record. The enrichment agent finishes its pass and writes back the full record it derived from the version it read ten minutes ago. The churn update is gone. Both agents did their jobs. Both writes returned success. The record is wrong, and nothing in the stack knows.

## The half that got built

This week I went through the public positioning of roughly thirty shared-context and agent-memory products collected on a single Product Hunt alternatives page. Knowledge graphs served over MCP. File-based memory with version history. Context that follows you across tools and sessions. Retrieval accuracy up in the nineties. It is a genuinely strong category, and every product on that page sells the same half of the problem: how agents remember.

Roughly thirty shared-context and agent-memory products on one Product Hunt page describe how agents remember. Not one describes what happens when two writers hit the same key at the same moment.

That is not an accusation. It is a scoping choice, and some of the best teams in the space state it plainly. Mem0's own writing asks what happens when two agents disagree about a fact, and answers that this is a design problem developers must solve, not something the memory layer guarantees. Nous Research scopes Hermes Kanban as a task queue, not a collaborative data system: it coordinates when work runs, not how workers share mutable state. Cognition wrote that in most multi-agent setups writes stay single-threaded, because decision-making fragments when multiple agents take write actions. The write side is not hidden. It is named, and then left to you.

## Why nothing errors

The default write path in almost every shared store is last-writer-wins. The store accepts whatever arrives last, timestamps it, and moves on. That is the right default for a single writer. With concurrent writers it has a precise failure mode.

Go back to the two agents. The triage agent's write was correct for the version it read. The enrichment agent's write was also correct for the version it read. Every write in a lost update succeeds. The failure lives in the interleaving, and no single call can see the interleaving.

This is why the bug gets misfiled as a model problem. The record looks complete and well formed. Review of the output finds nothing wrong, because the output is internally consistent. Provenance tells you who wrote it and when. It does not tell you which version the writer read when it derived the change. So the incident report says the agent ignored the cancellation email, someone tightens a prompt, and the same interleaving fires again a week later on a different record.

Sequential versions of the same failure need no concurrency at all. One agent reads a record, a human or a sync updates the source mid-task, and the agent writes back a figure derived from the old version. One actor, no race, wrong data, no error.

## What the write side takes

Three guarantees close this class. All three are mechanical. None of them are model work.

First, a write derived from a stale read gets denied, and the writer re-reads before it can commit. Deny plus reacquire. Enforcement works by invalidation at the moment of access, not by holding locks across LLM latency.

Second, two writers on the same key resolve to exactly one winner. The loser gets a typed, retryable conflict instead of silent success. Compare-and-swap on the version the writer read, so the losing agent re-derives from current state and both updates land.

Third, a writer that crashed, got reclaimed, and comes back late cannot land its commit as if nothing happened. Fencing by read generation, so a matching version number alone is not enough to sneak a stale write in.

I build [agent-coherence](https://github.com/hipvlady/agent-coherence), an open-source layer that ships these three guarantees, checked as TLA+ invariants rather than promised in prose. The honest scope line: enforcement is single-host today. Cross-host enforcement exists as a working demo and a design conversation, not a shipped guarantee, and if your writers span machines that is a co-design conversation I will say out loud rather than round up.

## One question for your stack

When a write lands in your memory layer, does anything check which version the writer read?

If the answer is no, your stack is last-writer-wins, and somewhere an enrichment agent is quietly erasing a triage agent. The recall half of memory tells your agents what was true. The write side decides whose update survives. Teams are shipping fleets on stacks that answered only the first question, and the failures land in the gap between the two, looking exactly like a model that ignored an instruction.

The library is a pip install, and the demo takes two minutes offline. If you run the diagnostic against your own stack and the answer surprises you, [I want to hear what you found](/contact/).

```
pip install agent-coherence
```

[Repository](https://github.com/hipvlady/agent-coherence) · [Two-minute offline demo](https://gist.github.com/hipvlady/30ba7b1b38126ff98fb3caa52d8ab03e) · [Raw markdown of this post](/blog/write-side-half.md)