# Ghost memory: why agents can't tell what's true now

> Source: <https://usewire.io/blog/ghost-memory-agents-cant-tell-whats-true-now/>
> Published: 2026-08-10 17:00:00+00:00

[ AI Agent Context Engineering ](/blog/anthropic-managed-agents-memory-context-engineering/)

### Anthropic's Managed Agents memory: what it changes

Key takeaway

Ghost memory is a state coordination failure in agent memory: old facts, current facts, and the records of what changed all coexist in the store, get retrieved together, and mislead the model. A July 2026 paper (arXiv 2607.01935) measured it by scoring temporal questions separately from aggregate accuracy, and found a widely used memory system answering them at 0.0295 F1 on LoCoMo. Neither deletion nor timestamps fix it: deletion destroys the transition record, and recency does not tell you which fact is live for a given query. The fix is to keep every record and label its state role so the agent can navigate to the superseded version deliberately.

Your agent tells you that the deal owner is Michelle. It is wrong, but not in the way models are usually wrong. Michelle owned that account in March. The handoff happened in June, it went into the memory store as a new entry, and the March entry never went anywhere. Both records are sitting in the bank right now. Semantic retrieval pulled them both, they both look like answers to “who owns this account,” and the model picked one. This is ghost memory.

Nothing in that chain is a hallucination. Every fact in the store is a fact that was true when it was written. The failure is that the store has no way to say which one is true *now*, and the retrieval step hands the model a pile in which the live fact and the dead fact are indistinguishable.

A July 2026 paper gives it that name and, more usefully, a way to measure it.

Ghost memory is a state coordination failure in which old, current, and transition facts coexist in the memory bank, remain mixed during retrieval, and mislead the answer model. The term comes from A-TMA ([arXiv 2607.01935](https://arxiv.org/abs/2607.01935), July 2026), which argues that the interesting problem in long-term agent memory is not storage or recall but state: knowing what is true now, what used to be true, and what changed in between.

The measurement is the part worth sitting with. On LoCoMo, a long-conversation benchmark of 10 conversation samples and 1,986 QA pairs, the authors scored the temporal questions on their own rather than folding them into the aggregate. Graphiti/Zep, a well-regarded graph-based memory system, scored **0.0295 F1** on that slice. Not sixty percent of the way there. Effectively zero.

That number does not appear in normal evaluations because normal evaluations report one accuracy figure across all question types. Most questions in a memory benchmark have no conflicting versions, so a system can look competent overall while being close to blind on the subset where a fact changed. The authors make this point directly: decoupled assessment of individual failure points reveals issues that aggregate QA accuracy hides.

That critique is not unique to this paper. [MemFail](https://arxiv.org/abs/2605.26667), a diagnostic benchmark out of Berkeley in May 2026, makes the same argument about memory evaluation generally: existing benchmarks treat memory systems as black boxes, so an incorrect answer cannot be attributed to a particular failure mode. Their decomposition is by operation, splitting memory into summarization, storage, and retrieval. A-TMA’s is by state. Both land on the point that one accuracy number is not a diagnosis.

This is [context drift](/glossary/context-drift/) with a specific mechanism attached. The agent has not lost the plot because its window filled up. It has lost the plot because its store is internally inconsistent and nothing in the retrieval path exposes that.

Deletion resolves the immediate conflict and creates three new ones. It is the obvious move, which is why it is the default in most memory implementations, and it is worth being explicit about what it costs.

You lose the transition. “Michelle owned this account until June” is a real answer to a real question, and once the March record is gone there is nothing left to derive it from. Long-running agents get asked about change constantly: what did we decide before, when did this move, why is the number different from last quarter. A store that only holds the present cannot answer any of it.

You lose the diagnosis. When the agent gives a wrong answer, the record that produced it is the first thing you want to look at. If updates delete their predecessors, the evidence for the wrong answer is destroyed by the same mechanism that was supposed to prevent it.

You make deletion a judgment call the system is not qualified to make. Deciding that a new fact supersedes an old one requires knowing that both describe the same slot in the world. “Michelle owns the account” and “Marcus owns the account” conflict only if the account is the same account and ownership is singular. A write-time heuristic that gets this wrong silently destroys a true record, and the same reasoning applies to memory consolidation passes that rewrite history in place, which [have their own set of failure conditions](/blog/when-agent-memory-needs-sleep/).

A timestamp records when an entry was written, which is a different question from which entry is live for the query in front of you. Recency is a decent tiebreaker and a bad answer.

Two things break it. First, a large share of questions asked of a long-lived agent are about past states, and for those the newest record is the wrong one. Second, write order and truth order come apart routinely: a backfilled document, a late-arriving sync, or a correction to an old entry all land with a fresh timestamp while describing an older state of the world.

The A-TMA results show the gap concretely. Temporal knowledge graph evidence in their evaluation reached 0.812 evidence support, meaning the retrieval step was finding the right records, while conflict accuracy sat at 0.425. The system was pulling the correct evidence and then answering wrong, because nothing in what it pulled said which record was live. Retrieval was not the bottleneck. Interpretation was.

A separate line of work reaches the same place from the other direction. [Reliable Post-Retrieval Assembly for Agent Memory](https://arxiv.org/abs/2606.01435) (COLM 2026 Lifelong Agent Workshop) argues that memory systems fail because semantic filtering and conflict resolution are entangled in a single step, and separating them lifts accuracy on MemoryAgentBench’s FactConsolidation split by 10.8 percentage points on average, and 21 points at 262K scale. The prior best across all 22 systems they compared was 54% single-hop and 7% multi-hop. Seven percent, on multi-hop questions about facts that changed.

The fix that measures well is to store every version and attach a state role to it, so the agent can see that a conflict exists and choose which side of it to read.

A-TMA implements this as three labels: **current** for live facts, **historical** for superseded records, and **transition** for the records that document how a state changed. Retrieval gathers semantic seeds, expands along state-related links, and filters against the state view the query is actually asking for, producing what the authors call an evidence packet: the retrieved records annotated with their state roles and temporal metadata. Nothing is deleted. The historical record stays reachable, labeled as historical.

Applied as an overlay to existing systems, this moved Graphiti/Zep from 0.480 to 0.720 conflict accuracy on their LTP probe set (10 profiles, 800 probes), and lifted A-Mem from 0.812 to 0.860. The LoCoMo temporal F1 went from 0.0295 to 0.1705. That last number is still low in absolute terms, which is the honest read: this is a first pass at a problem the field has mostly not been scoring, not a solved one.

Here is how the four common approaches compare on what they preserve and what they can answer.

| Approach | Old record kept | Answers “what changed?” | Conflict visible to agent | Cost |
|---|---|---|---|---|
| Delete on update | No | No | No conflict exists | Cheapest, loses history |
| Timestamp only | Yes | Partially | No, agent must infer from dates | Cheap, fails on past-state queries |
| Aggregate-scored memory system | Yes | Rarely tested | No | Failure hidden by the metric |
| Typed state labels on edges | Yes | Yes | Yes, labeled and navigable | Write-time classification per pair |

The last row has a real cost, and it is worth naming: something has to decide, for each new entry, how it relates to what is already stored. That is a classification job at write time, and it scales with the number of candidate entries a new write could conflict with.

The labels only help if they reach the agent, which makes this a [provenance](/glossary/epistemic-provenance/) problem as much as a storage one. A memory store can internally know that entry A supersedes entry B and still hand the agent a flat list of two results with similarity scores. The state role has to ride out with the retrieval result, and it has to be navigable, or the agent cannot act on it.

That is the argument in [provenance is a context engineering primitive](/blog/provenance-is-a-context-engineering-primitive/): typed edges are not an audit artifact for humans reading logs later, they are structural metadata the agent consumes at inference time to decide what to do next. A `supersedes`

edge tells the agent something a similarity score cannot: these two results are not two pieces of evidence, they are one fact at two points in time.

In Wire, the analysis pipeline classifies each new entry against one candidate at a time and labels the edge `corroborates`

, `elaborates`

, `supersedes`

, or `contradicts`

, then returns those edge counts on every search hit so the agent can see a conflict exists before deciding whether to walk to it. Superseded values are tombstoned with a pointer to the edge that replaced them rather than removed, and a pair that draws both `corroborates`

and `contradicts`

keeps both rows, because [disagreement between sources](/integrations/wire-memory/) is signal for the agent to resolve rather than noise for the store to suppress.

The design rule underneath that is worth stating on its own, independent of any implementation: label the relationship, do not adjudicate it. The store knows that two entries describe the same slot and that one arrived after the other. It does not know which one the user’s current question is about. Handing the agent a labeled conflict and letting it choose is strictly more information than handing it a resolved answer, and it costs one edge.

Four questions, in the order they usually fail.

**Does an update delete its predecessor?** If yes, you cannot answer change questions and you cannot diagnose wrong ones. This is the highest-cost default in the ecosystem and the easiest to fix, because keeping a row is cheaper than the machinery most systems build to compensate for having dropped it.

**Does anything mark the relationship between two versions?** A store can keep both records and still be in the ghost memory regime, because two unlabeled entries retrieved together are exactly the failure. The edge is what makes it navigable.

**Does the state role reach the agent?** Check what a retrieval result actually contains. If it is an id, a score, and a content blob, the agent is reconstructing state from prose and will get it wrong at the rate the benchmarks report.

**Are you scoring temporal questions separately?** If your eval reports one accuracy number, you do not currently know whether you have this problem. The 0.0295 F1 was invisible until someone split the metric out. Score conflicting-fact questions as their own category before you conclude your memory system is fine.

Ghost memory is a modeling failure, not a capacity failure, which is why more context window and better retrievers do not touch it. Both of those improve what the agent can see. Neither tells it which of the things it can see is currently true.

The pattern that comes out of this research is narrow and boring in a good way: keep every version, label how versions relate, expose the label at retrieval time, and let the agent resolve the conflict against a question the store never had access to. The measured gains are real and the absolute numbers are still bad, which mostly means this is early. The part that is not in dispute is that a memory system which quietly overwrites its own history cannot get here at all, and that most of them are doing exactly that.

Sources: [A-TMA: Decoupling State-Aware Memory Failures in Long-Term Agent Memory (arXiv 2607.01935)](https://arxiv.org/abs/2607.01935) · [Reliable Post-Retrieval Assembly for Agent Memory (arXiv 2606.01435)](https://arxiv.org/abs/2606.01435) · [MemFail: Stress-Testing Failure Modes of LLM Memory Systems (arXiv 2605.26667)](https://arxiv.org/abs/2605.26667) · [Evaluating Very Long-Term Conversational Memory of LLM Agents (LoCoMo, arXiv 2402.17753)](https://arxiv.org/abs/2402.17753) · [Evaluating Memory in LLM Agents via Incremental Multi-Turn Interactions (MemoryAgentBench, arXiv 2507.05257)](https://arxiv.org/abs/2507.05257)

Related

Wire transforms your documents into structured, AI-optimized context containers. Upload files, get MCP tools instantly.
