Architecture · Conflicts
How Do Agents Handle Conflicting Memories?
Conflicts are resolved by an explicit rule rather than by the model’s judgement: rank the sources, compare the timestamps, mark the loser superseded instead of deleting it, and keep the history queryable. A store that leaves two contradicting facts in place with equal confidence has handed the decision to whichever one happens to rank higher, which is the most common cause of an agent that contradicts itself.
The resolution order
The problem
Why do agent memories conflict?
Because the world changes, people restate things differently, and agents write down inferences alongside observations without distinguishing them. Conflict is the normal condition of a memory store that has been running for a while, not an exceptional case to handle defensively.
Four sources produce nearly all of it. Facts expire. A user moves, changes jobs, upgrades a plan or changes their mind, and the store now holds two statements that cannot both be current. This is the largest category and the most predictable.
Paraphrase creates false conflict. “Prefers short answers” and “does not like long explanations” are the same preference recorded twice. They do not contradict, but a store that cannot tell duplication from disagreement will treat them as two facts and spend two retrieval slots on one preference.
Inference gets stored as observation. An agent concludes something plausible, writes it, and later hears the user state something different. The stored inference was never authoritative, but nothing in the record says so, so it competes on equal terms with what the user actually said.
Multiple writers disagree. In a multi-agent system two agents can reach different conclusions from different evidence, and both write. That case is covered on shared memory in multi-agent systems.
The failure is quiet in every case. Nothing errors, retrieval returns candidates as usual, and the agent answers confidently using whichever memory scored higher on this particular query. The same question asked twice can get two answers, which users experience as unreliability rather than as a data problem.
The distinction that makes all of this tractable is one most stores never record: where a memory came from.
Provenance
Why does a memory need to record where it came from?
Because conflict resolution needs to know which of two statements is more authoritative, and nothing in the text of a memory says how the system learned it. Provenance is one small field per record, and it is the difference between a rule that resolves conflicts and a coin flip.
Three fields do the work. The source distinguishes a direct user statement from an agent inference, a system record from a conversational mention, and a human correction from everything else. The timestamp records when the memory was written and, separately, when the fact it describes became true, which are not the same thing when a user says “I moved last March”. The confidence records how sure the extraction was, which matters because a fact extracted from an ambiguous sentence should not outrank a clearly stated one.
The payoff shows up in cases that are otherwise unresolvable. When an inference and a statement disagree, the statement wins without anyone having to reason about the content. When two statements disagree, the later one wins. When a correction disagrees with anything, it wins. None of those rules require understanding the subject matter, which is what makes them safe to apply automatically.
Provenance also makes damage repairable. If an extraction bug wrote a class of wrong memories, a store that recorded which process wrote each one can remove exactly those. A store that did not has no way to distinguish them from everything else, and the choice becomes keeping known-bad data or discarding good data with it.
With provenance in place, the resolution rule itself is short: how a conflict gets resolved.
The procedure
How should an agent resolve conflicting memories?
With an explicit hierarchy applied at write time: detect the contradiction as the new memory arrives, rank the two sources, use recency to break ties between equal sources, and record the outcome rather than leaving the decision to retrieval.
Detect on write. When a new memory arrives, search for existing memories about the same subject and attribute before storing it. This is the same lookup deduplication needs, so systems that already deduplicate get conflict detection almost free. Systems that do not will discover conflicts only when a user notices.
Rank the sources. Not all memories are equally authoritative, and a fixed order settles most cases without judgement. A direct statement from the user outranks an agent’s inference. A verified system record, such as a CRM field, outranks a conversational mention. A human correction outranks everything, because it exists precisely to overrule what the system believed.
Use time to break ties. Where two memories come from the same class of source, the later one wins. Recency is a weak signal on its own and a good tiebreaker, which is why it sits third rather than first: a stale human correction should still outrank a fresh inference.
Record the resolution. The losing memory is marked superseded, with a pointer to what replaced it and the date it stopped being current. This is the step that makes the whole procedure auditable, and it is where most implementations stop short by deleting instead.
That last decision deserves its own argument, because deletion is the intuitive choice and the wrong one: why superseding beats deleting.
The design decision
Why supersede a memory instead of deleting it?
Because questions about the past are legitimate, corrections are sometimes wrong, and an audit trail is worth more than the storage it costs. Deleting the old value optimises for a clean store and gives up three capabilities in exchange.
The past stays answerable. “Where did I live before Berlin?” and “what plan were we on last year?” are ordinary questions. A store that overwrote the previous value cannot answer them, and the agent has to say it does not know something it was explicitly told.
Corrections can be reversed. If a fact was superseded because of a misheard statement or a bad inference, invalidation is undoable and deletion is not. Given that extraction is imperfect, designing for reversibility is prudent rather than precious.
Change becomes visible. A record of what changed and when is useful in its own right: a support agent seeing that a customer’s plan changed twice this quarter has information that no single current value carries.
The cost is real and manageable. The store grows, and every retrieval must filter out invalidated memories, which means the validity flag has to be part of the search rather than applied afterwards. Filtering after retrieval wastes candidate slots on facts that were already known to be dead.
This is exactly the capability a temporal knowledge graph provides natively, since edges carry validity intervals rather than a single current state. The implementation is described on knowledge graphs for AI memory, and Zep’s version of it reports a LongMemEval accuracy improvement of up to 18.5% over a full-context baseline with latency cut by around 90% (Rasmussen et al., 2025). A plain vector store can achieve the same thing with a validity field and disciplined filtering; it just has to be built rather than inherited.
Resolution and supersession both assume the conflict was noticed. The remaining question is what to do when it was not: how to detect conflicts you are already storing.
Detection
How do you find conflicts already in the store?
By running the same comparison consolidation runs, in batch, over memories that share a subject and an attribute. Any store that has been live for a while without conflict handling has accumulated contradictions, and they will not surface on their own.
The practical approach is to group memories by what they are about, then compare within each group. Grouping by embedding similarity finds most of it, since two statements about the same attribute of the same entity are usually close in vector space. Within a group, a model call can classify each pair as duplicate, compatible or contradictory, which is slow enough to be a background job and cheap enough to run over a store once.
Three outcomes need different handling. Duplicates merge into the more complete version. Compatible memories, such as two preferences that happen to be about the same topic, stay as they are. Contradictions go through the resolution procedure above, and where the ranking cannot separate them, the honest option is to keep both and surface the disagreement to the user rather than pick silently.
That last case is worth designing for explicitly. An agent that says “you told me Berlin in March and Munich last week, which is current?” is behaving better than one that guesses, and users generally find it reassuring rather than annoying. Products that hide the ambiguity are choosing a confident wrong answer over an accurate uncertain one.
Detection belongs to the same background pass as the rest of store maintenance, described on memory consolidation and forgetting and eviction.
One last question decides how visible any of this should be: whether to ask the user.
The interface
Should the agent ask the user to resolve a conflict?
Ask when the conflict is about something consequential and the ranking cannot separate the two versions. Resolve silently when the rule is clear. Asking about everything is as bad a failure as guessing about everything, in the opposite direction.
The rule of thumb is consequence weighted by confidence. A changed dietary preference resolves silently by recency, since the cost of getting it wrong is one awkward suggestion. A changed billing address, delivery instruction or access permission is worth one clarifying question, because acting on the wrong version is expensive and the user will not thank you for the guess.
How you ask matters as much as whether. “You mentioned Berlin in March and Munich last week, which should I use?” is specific, shows the evidence, and takes one moment to answer. “I have conflicting information about your location” tells the user there is a problem and gives them nothing to act on.
There is also a transparency argument that sits above the individual decision. Products that let a user see and edit what the assistant remembers convert this whole class of problem from a hidden data-quality issue into something the user can fix themselves, and users are markedly more forgiving of a system whose memory they can inspect than of one that is confidently wrong about them.
The access-control side of the same data, meaning who may read a memory at all, is covered on AI memory security.
A last practical note on tone. An agent that says “I had Berlin from March, you have just said Munich, I have updated it” is doing something users read as competence rather than confusion, because it shows the system is tracking change rather than merely holding a value. Silently overwriting produces the same data and none of that reassurance.
The write-time half of all this is on how agents write and store memories.
FAQ
Frequently asked questions
The questions that follow: whether to ask the user, and how to handle conflicts between agents.
How do agents handle contradictory memories?
Invalidate or supersede old facts on update — last-write-wins for simple prefs, temporal validity for CRM/policy domains. Zep Graphiti does bi-temporal invalidation natively.
How does Zep handle memory conflicts?
Graphiti invalidates superseded facts with bi-temporal edges — tracks when facts were valid. LongMemEval +18.5% vs baseline (Rasmussen et al., 2025). See Zep alternatives.
How does Mem0 update conflicting memories?
Engram and Mem0 both merge or replace memories on write when new info arrives. For temporal validity windows, compare Zep.
What if a user corrects the agent?
Treat correction as high-priority write — immediately supersede the contradicted memory. Expose forget/update tools in memory-as-tool patterns.
What is temporal validity in memory?
Facts have valid_from/valid_to windows — "refund policy was 30 days until Q3 2026." Graph edges model this; vectors need explicit metadata.
Multi-agent memory conflicts?
Scope writes by agent_id, use confidence scores or central conflict resolver. See shared memory and multi-agent memory.
Context poisoning and stale memories?
Stale or adversarial memories injected into retrieval poison agent responses. Mitigate with TTL, source provenance, user_id filters and periodic revalidation.
CRM data updates vs agent memory?
Sync CRM as source of truth; agent memory holds conversation-derived facts. On CRM update, invalidate related agent memories or re-fetch from CRM at retrieve time.