The bug you cannot see until it bites
You give your agent a fact on Monday: the customer is on the Pro plan. On
Thursday a webhook says the customer downgraded to Free. Your memory layer does
the sensible-looking thing. It updates the record. Pro becomes Free, and Monday
is gone.
Now ask the agent a question it should be able to answer: when did they
downgrade, and what did we believe before that? It cannot. Not because the data
was hard to find, but because your memory threw it away the moment it decided
the new fact won. The history that would let you audit the agent, reconstruct a
past decision, or notice that the two facts came from sources you trust
differently: none of it exists anymore.
This is the default in almost every agent memory system on the market. Store a
fact. Retrieve the nearest one. When two conflict, the last write wins and the
loser is deleted. It looks like memory. It behaves like a whiteboard.
The quiet assumption underneath
Overwriting on conflict encodes a belief most teams never chose on purpose:
that the memory layer is the right place to decide what is true.
It is not. Deciding truth is a judgment about which source is more reliable,
whether two claims actually contradict or just look similar, whether the old
fact still holds in some context the new one does not cover. That judgment
belongs to your application, your policy, or a human. A key-value store is not
equipped to make it, and when it makes it silently, you inherit three problems:
- You cannot audit what you cannot reconstruct. If a client asks why your agent told them they were on the Free plan, "the database only keeps the current value" is not an answer they will accept.
- You get confabulation, not memory. A system that resolves every conflict into one confident current value states that value with the same confidence whether it is well supported or a coin flip between two sources.
- The judgment is invisible and unversioned. The most consequential thing your memory does, picking a winner, leaves no trace. You cannot tune it, test it, or explain it, because it was never written down.
The alternative: memory that refuses
There is a different design, and it comes from an old idea in AI called belief
revision: keep the claims, track which one you currently believe, and never
throw away the losing side. Memory that refuses to decide truth does four
things a vector store does not:
- It keeps both sides of a contradiction. Pro and Free both stay on record. One is marked believed right now; the other is contradicted, not deleted.
- It tracks belief over time. You can ask what the agent believed last Tuesday and get last Tuesday's answer, not today's.
- It can tell you why. Ask why it believes the customer is on Free and you get the chain of evidence: which source, when, on what basis. Not a similarity score.
- It will not invent a disagreement. Declaring two claims opposed is a judgment, and the caller makes it explicitly. The memory never reads two sentences and decides they conflict, which is what keeps the same question returning the same answer a year from now.
The shift is small to describe and large in consequence. The memory stops being
an oracle that hands you one confident answer and becomes a ledger you can
question.
Is that not just more complexity?
Fair objection. Three honest answers.
You already have this complexity; it is just hidden. The conflict-resolution
logic exists in every system. The overwrite version simply runs it silently and
discards the evidence. Making it explicit is not adding complexity, it is
surfacing complexity you already shipped.
You still get one current answer. Keeping both sides does not mean your
agent has to reason about both. It asks what is believed now and gets a single
value, same as before. The history is there when you need it (an audit, a
rollback, a what changed since last session) and invisible when you do not.
Sometimes you do want a decision, and that is fine. The point is not that
truth is never resolved. It is that the resolution should happen where the
context lives, in your policy, your rules, or a human in the loop, and should
leave a record. Memory's job is to hold the claims and the provenance
faithfully, so the decision, wherever it is made, can be made well and
explained later.
Why this is becoming non-optional
For a weekend project, last-write-wins is fine. The stakes change the moment an
agent acts on behalf of someone else. When you ship an agent to a client, "why
did it do that" stops being a debugging convenience and becomes an
accountability requirement, sometimes a contractual or regulatory one. You
cannot answer it with a memory that overwrote the evidence.
The teams that will trust agents with real decisions are going to demand what
we demand of any system that acts with authority: show your work, keep the
record, let a human check it before it acts. Memory that refuses to decide
truth is the substrate that makes that possible.
Where this is built
This is what OMEM exists to do. Open source (MIT), self-hosted, no
dependencies, one pip install. The belief-revision engine keeps contradictions,
tracks belief over time, and answers why. It runs on your machine and phones
home to nobody. If you have ever watched your agent state something with total
confidence that you knew was a coin flip between two sources, that is the
problem it exists to fix.
pip install omem-infrastructure
omem-server
Top comments (0)