Agent Memory Drift: Why Reconciliation Is the Loop You're Missing

The most dangerous thing your long-running agent does is also the thing it does most confidently: answer from memory. The customer's address changed last Tuesday. The ticket the agent thinks is "open" was closed yesterday by a human. The product feature the agent has tidy explanatory notes about shipped in a different shape than the spec the agent read three weeks ago. None of this is hallucination in the textbook sense — the model is recalling exactly what it stored. The world simply moved while the agent was looking elsewhere.

Most teams treat memory like a write problem: what should the agent remember, how do we summarize, what's the embedding strategy, how do we keep the store from blowing up. That framing produces architectures that grow more confident as they grow more wrong. The harder problem — the one that determines whether your agent stays useful past week three — is reconciliation: the explicit, ongoing loop that compares what the agent thinks is true against what the underlying systems say is true right now.

If you have ever shipped a database-backed cache, you already know the pattern. Caches without invalidation are landmines. Memory without reconciliation is the same landmine, except your agent narrates over the explosion in fluent prose.

The drift you can't prevent, only detect

Drift is not a bug. It is a thermodynamic property of any agent that operates over a window longer than the mean time to change of the entities it knows about. The moment an agent writes a fact down — "user prefers async standups," "this account is on the Pro plan," "the deploy pipeline runs tests before merge" — that fact is correct. From that moment forward, every minute that passes without re-checking it is a minute of probability accumulating that it has become wrong.

This is why "make the agent remember more" is rarely the right next investment for a long-horizon system. More memory means more surface area for drift. A Tuesday Towards Data Science survey of practitioners building production memory systems found the recurring lesson is that memory useful today is stale tomorrow, and the only durable strategy is to design for re-validation rather than retention.

The right mental model is not the human memory metaphor that pervades agent literature. It is a database replica that has fallen behind its primary. Replicas don't lie about what they store; they tell you exactly what they replicated last. The discipline isn't to make the replica smarter. It's to know precisely how stale it is, what watermark it caught up to, and what to do with reads that need fresher data than it has.

Reconciliation patterns borrowed from databases

The good news is that distributed-systems engineers solved most of this. Memory systems for agents are converging — quietly, without much fanfare — on the same primitives that keep caches honest in front of large databases.

Versioned reads with watermarks. Every memory entry carries the version of the source-of-truth it was derived from. When the agent reads a memory, it can compare that watermark against the current version of the underlying entity. If the entity has advanced past the watermark, the read either triggers a refresh or is annotated as "may be stale; last reconciled at version N." This is the same trick replication systems use to expose lag, and it survives the move to LLM agents almost unchanged.

Change-feed subscriptions. Rather than the agent polling reality on every read, the entities that memory references publish a change feed — Debezium-style CDC, an event bus, or just a webhook. When the customer's address changes in the CRM, an event lands in a topic that the memory layer is subscribed to. Affected memory entries get marked dirty. The next read either refreshes or returns with a freshness flag. This is exactly the pattern Hazelcast and other cache vendors documented years ago for evergreen caching against operational databases — it is mature, boring, and devastatingly effective when applied to agent memory.

Lazy revalidation at read time. Eager invalidation has a fatal flaw at agent scale: most stored facts will never be read again before they're irrelevant, so eagerly refreshing them is wasteful. Lazy revalidation flips it. When the agent fetches a memory entry, the memory layer checks the watermark against the source. If the entry is older than its trust budget, it triggers a synchronous or background refresh before returning. You only pay the freshness tax for memories that are actually being used, which matches the access skew you almost certainly have.

TTLs that decay with mutability. A stamped, immutable fact ("the customer signed up on March 4, 2026") deserves an effectively infinite TTL. A volatile fact ("the customer's last ticket priority is high") deserves minutes. A vendor's quirk many teams discover the hard way: uniform TTLs guarantee you over-refresh stable data and under-refresh volatile data simultaneously. The fix is to type your memories by the mutability profile of the entities they reference — categorical, slowly-mutable, fast-mutable, ephemeral — and apply different decay rates per class. The classification can be heuristic; getting it roughly right matters more than getting it perfect.

None of this is novel as systems work. It only feels novel because most agent codebases never made the move from "memory is a vector index of stuff" to "memory is a derived view over operational state, and views need invalidation."

The embedding-of-state pitfall

The single most common architectural mistake I see in production agent systems is committing to embeddings as the primary representation for things that change. Embeddings are wonderful for semantic recall over text. They are catastrophically bad as a substrate for reconciliation, because they erase the structure you need to invalidate selectively.

Imagine the agent has a vector summary attached to a customer: a 1024-dimensional blob that compresses six months of conversation into "wants async support, dislikes phone calls, mostly asks about the billing API, currently on the Growth plan." Now the customer upgrades to Enterprise. Which dimensions of the embedding encoded the plan? You don't know. You can't know. The plan is mixed throughout the vector with everything else. Your only options are to regenerate the entire summary (expensive, and you've just thrown away the parts that were correct) or to leave it stale (the agent now asserts the customer is on Growth in passing, with full confidence).

A structured record — { plan: "Growth", communication_pref: "async", recent_topics: ["billing API"] } — has the obvious advantage that you can update the plan field independently. Watermarks attach per field. Change feeds invalidate per field. The embedding pitfall is that the very thing that made vector memory feel powerful (compressing a lot of text into one similarity-searchable artifact) is what makes it impossible to keep fresh.

The pragmatic architecture treats vectors as a recall layer over a structured ground truth, not as the ground truth itself. The embedding lets the agent find the right record. The record is what gets read, reconciled, and cited. If you must summarize for context-window reasons, summarize the structured record at read time — and discard the summary at session end so it doesn't ossify into a stale artifact.

When memory contradicts reality, trust is what breaks

A failure mode worth dwelling on: the agent confidently asserts something that contradicts what the user knows to be true right now. The customer service agent that addresses you by your former name. The coding agent that explains a function based on a version of the file that was refactored last week. The sales agent that recites the wrong account size to the rep who is staring at the corrected number in another tab.

The damage from these moments is asymmetric. The agent could be right hundreds of times in a row, and one confidently-wrong answer about an obviously knowable fact resets the trust ledger. Practitioners report that more than a third of stored facts about user state were wrong within three months in real-world testing — and the agents were retrieving them hundreds of times without ever flagging uncertainty. The model wasn't lying. It was telling you exactly what it remembered, and what it remembered was a snapshot of a world that had moved on.

The mitigation isn't smaller memories or better summarization. It is making the agent's relationship with its memory honest. When a memory entry is read, the agent should know its freshness — at minimum, "checked X minutes ago" or "last reconciled against source at version N." For load-bearing claims, the agent should be able to (and prompted to) re-read the source rather than the memory. This is the same discipline a senior engineer applies before shipping a fix based on stale notes from a meeting two weeks ago: trust your notes, but verify the system.

Evals that mutate the world

Eval suites for memory mostly test the wrong thing. They check whether the agent can recall something it was told. The harder question — the one that determines production safety — is whether the agent notices when what it was told is no longer true.

The eval pattern is straightforward to describe and rare to actually implement. Run a session where the agent learns and stores a fact about an entity. Mutate the entity in the source-of-truth between sessions. Run a new session that requires that fact. Score on whether the agent retrieves the now-stale memory and uses it confidently, retrieves it but flags freshness, refuses to use it, or correctly re-reads the source. Most production agents fail this in the first three quadrants and never reach the fourth.

ICLR 2026 work on memory benchmarks added "conflict resolution" as a first-class competency precisely because the field recognized that retrieval accuracy alone is the wrong metric. An agent that retrieves with 99% accuracy from memory that's 30% stale is worse than an agent that retrieves with 80% accuracy from memory that knows when to say "I'm not sure, let me look." The world-state perturbation eval is what forces this distinction into your CI pipeline.

A practical version: maintain a small set of "reconciliation traces" — recorded sessions where you've programmatically perturbed the underlying records between turns. Replay them on every memory-system change. The pass rate on reconciliation traces is one of the few numbers that correlates with whether your agent will hold up past its first month in production.

Memory and knowledge state are different things

The org-level pattern that pulls all of this together is a vocabulary distinction most teams don't make: memory is a write-only log of beliefs the agent has formed; knowledge state is a read-through cache of the world that knows when to invalidate. They serve different jobs and they should not share a layer.

Memory, in this framing, is append-only. The agent observes; it writes a belief. Beliefs include their provenance, their timestamp, and their watermark. They are never updated in place — corrections are new entries that supersede prior ones, with explicit pointers to what they replaced. This makes memory auditable, replayable, and safe to introspect.

Knowledge state is the layer the agent actually queries during a turn. It is built from memory plus live reads against the source of truth, with reconciliation policies applied per entity class. It is allowed to fail, to flag freshness, to refuse to answer when a load-bearing fact is too stale. Most importantly, it is allowed to be smaller than memory — to drop beliefs that have become unreconcilable rather than parade them as truth.

Teams that don't separate these end up with one giant memory blob that's neither auditable nor trustworthy. Teams that do separate them get something far more valuable: an agent that knows what it knows, knows what it once knew, and knows the difference between the two.

The hardest engineering you'll do on a long-horizon agent isn't the prompt, the tool wiring, or the orchestration. It's the boring database-style work of making the agent's view of the world stay honest as the world refuses to sit still.