Self-Correcting Memory and State Freshness in Agent Systems

A support agent quotes a user's address from a March conversation. The user updated that address in June. The store holds both writes, but the March entry ranks higher because its embedding is denser, so the agent retrieves it with confidence. The retrieval is technically correct. The package still ships to the wrong street.

This is the failure that standard evaluation misses. A postmortem built around recall alone would call the memory system healthy, because the agent found a fact that matched the query. Nothing in that evaluation asks whether the fact was still true. The root cause lies in how the fact was stored and never reconciled against the update that replaced it.

Large language models carry no memory between calls. Every fact an agent seems to "know" persists only because some part of the system decided to store it, decided when to load it back in, and will eventually decide when to remove it. Each of those three decisions, storing, loading, forgetting, has its own way of breaking, and a break in any one of them produces behavior that looks identical from the outside: an agent acting with total confidence on something that is no longer true.

Most production systems score only whether the right fact was retrieved and call the memory layer finished. That single-number approach passes agents that handle recall well and then act on stale, revoked, or flatly contradicted information once they're live. The address scenario is a demonstration of what a recall-only grade hides.

The four dimensions a complete memory layer must satisfy

Agent memory correctness breaks into four separate engineering problems, not one. Recall, freshness, contradiction handling, and forgetting each fail through different mechanisms, get triggered by different conditions, and need their own rubric to catch. Treating them as a single composite score is how the address failure slips through: a system can ace recall while failing freshness completely, and the average still looks fine.

The four dimensions, laid out as a framework rather than a feeling, look like this:

| Dimension | What it checks | |---|---| | Recall | Did the system retrieve the right fact for the task | | Freshness | Did it use the latest version of that fact, not an earlier one | | Contradiction handling | When two facts about the same thing conflict, did it resolve to the correct winner | | Forgetting | Did it actually delete what should be gone: retracted, expired, or out-of-scope facts |

Each dimension needs its own check because a pass on one tells nothing about the others. A system can retrieve the correct fact ID and still hand the agent a version six months out of date. A system can resolve conflicting facts correctly in testing and still retain a tombstoned record that resurfaces the moment someone queries it again. Scoring only one dimension and extrapolating to the rest is how a recall-passing, freshness-failing agent ships a package to the wrong address.

It helps to separate memory by kind before applying these four checks, if only as background vocabulary. Episodic memory holds past conversations, semantic memory holds facts about a user or a domain, and procedural memory holds workflows the agent has learned. Each of these three fails differently within each dimension, so lumping them into one undifferentiated memory bucket produces an aggregate score that predicts almost nothing about how the agent behaves once it's running real traffic.

A 2026 survey of self-improving agent frameworks found that agents rarely change strategy on their own, even when the results in front of them clearly call for it. That's not a limitation of the underlying model's reasoning: the gap between an agent's capacity to recall information and its capacity to correct its behavior based on newer information is precisely a freshness and forgetting problem. An agent can be fully capable of reasoning correctly and still act wrongly, simply because nothing in its memory layer told it the ground had shifted.

Where freshness failures originate in the memory stack

Freshness failures are the predictable output of a storage architecture that appends new writes without reconciling them against the old ones, so a corrected fact sits in the store competing against the original error every time a query runs.

Pure vector storage builds this problem in from the start. When new information arrives, the old embedding isn't invalidated or marked superseded. Both versions remain retrievable, and whichever one ranks higher for a given query wins, regardless of which one is actually more recent. Recency and relevance are different axes, and vector similarity only measures the second one.

The consequence is an agent holding an internally inconsistent model of the world and acting on whatever version retrieval happens to surface first. The failure hides from recall-only evaluation because the agent did retrieve a real, previously-stored fact. It just wasn't the fact still in effect.

Picture the memory stack as four tiers stacked on top of each other: in-context working memory at the top, external key-value stores beneath that, episodic logs beneath that, and semantic vector stores at the base. A freshness failure at any of the lower tiers propagates upward into the context window with no signal attached telling the agent that what it's looking at is stale. The agent has no internal alarm bell. By the time a fact reaches the context window, it looks exactly as authoritative as a fact written an hour ago.

Part of why this goes unnoticed for so long is that teams conflate two things that operate on entirely different timescales. Context management is what enters the model's finite context window for a single inference: ephemeral, operational, reset constantly. Memory management is what gets stored and retrieved across sessions: persistent, architectural, built to last.

One practical framing treats this as three design decisions rather than one monolithic "memory system": what to store, when to load it, and when to forget it. Each decision is architectural on its own, and each has its own distinct failure mode, all of which present on the surface as the same vague symptom: "the agent is being unreliable".

The stakes of getting this wrong scale with what the agent is actually doing. In the Amazon Bedrock AgentCore deployment at Iberdrola, agentic architectures for IT operations changed how thousands of change requests and incident tickets get managed. The correctness of every recommendation that system produces depends on whether the change-request state and incident data it's reading were current at the moment of retrieval, not at the moment they were first written into memory. A freshness failure in that context means an operational decision made on outdated infrastructure state.

Why contradiction handling is harder than deduplication

Deduplication solves a narrower problem than contradiction handling does. Removing identical duplicate entries says nothing about what to do when two memories make genuinely incompatible claims about the same entity, and that's the harder problem a memory layer actually has to solve.

Picture an agent retrieving two memories that disagree: one says a user holds admin access, another says that access was revoked; one says a service is healthy, another says it's degraded. The agent acts on whichever memory ranks higher for the current query, with no signal anywhere that a conflict even existed. Nothing failed loudly. The agent simply picked a side without knowing it was picking a side.

The cheapest fix starts with a deterministic gate rather than a judgment call. If two writes share the same canonical key and a recall step returns both of them, something downstream, the freshness layer, resolved one as the winner, or it punted the decision to the agent. Either path needs to leave a record: a span attribute logging which decision was made and why, so a rubric can later confirm the conflict policy actually ran rather than silently skipping it.

Two existing systems answer the underlying policy question differently, and the contrast is instructive. Mem0 uses an LLM judge that, on each new write, retrieves nearby memories and decides whether to update the existing one, replace it, or add a new entry alongside it. That catches contradictions at the moment of writing. The system still has no native concept of a fact's validity window: it stores timestamps, but it can't automatically mark an existing fact stale the moment contradicting information shows up.

The real lesson from the contradiction-handling problem is about where the decision gets made and whether it leaves a trace. A memory layer that resolves conflicts silently, with no logged basis for the resolution, is a memory layer nobody can audit after an agent has already acted on the wrong version. Which fact wins, and why, has to be answered somewhere, by something, and that answer has to be recoverable later.

Forgetting as a designed policy, not a cleanup job

Forgetting deserves the same architectural weight as the other dimensions, built in at the write path with explicit TTLs, decay schedules, and tombstoning rather than left as a background cleanup task. An agent that can't forget will, sooner or later, act on something that was revoked, something that expired, or something that was explicitly retracted.

One useful framing treats forgetting as a feature to design for rather than a defect to patch around. It belongs in the same conversation as deciding what kinds of memory an agent needs and where each kind should live, with TTLs, decay schedules, and staleness detection as the concrete implementation of that decision.

Testing for this dimension doesn't require subjective judgment. The rubric, ForgettingCompliance, is simple: querying for a tombstoned fact's ID should return nothing. If the fact comes back, the forgetting policy didn't run, full stop, and that's a deterministic check rather than a judgment call.

Privacy boundaries make the stakes of this dimension concrete. A memory system that captures an API key during a conversation and later resurfaces that key in some future prompt hasn't committed a logging mistake. It has committed a forgetting failure with a blast radius that's guaranteed the moment the key was ever stored. That's why privacy-boundary violations get treated as P0 incidents rather than minor regressions to fix in the next sprint.

The industry's own assessment backs up how unresolved this dimension is. Mem0's State of AI Agent Memory 2026 report lists forgetting and freshness among the field's open problems at the tooling layer; the tools teams are already shipping with don't solve this by default.

Left unaddressed, the cost of unmanaged forgetting doesn't announce itself. A price that changed six months ago keeps surfacing as current, repeatedly, until a customer notices the discrepancy and complains. Without a forgetting rubric running in continuous integration, that kind of drift stays invisible until it produces a visible, external error.

Forgetting, as a designed policy, covers facts that expire or get retracted. It does not, on its own, cover something structurally different: a permission that's still technically valid by the clock but has lost its real-world basis. That's a distinct and more dangerous failure, and it needs its own treatment.

Authority freshness: when the clock says valid and the world says otherwise

Data freshness asks whether a fact is current. Authority freshness asks a sharper question: does this fact still have the standing to govern what the agent does next. A permission grant that's well within its TTL window is not automatically a fact the agent can still trust, because the conditions attached to that grant may have already changed even while the clock says it's valid.

A June 2026 piece on self-correcting systems lays out what's at stake across three levels of consequence. A stale travel preference leads an agent to book the wrong city, which is annoying. A stale analytics source leads an agent to report the wrong business number, which is costly. A stale authorization grant leads an agent to act with permissions it no longer actually holds, which is unsafe. The severity climbs sharply as the stale fact moves from preference to data to permission, even though all three look identical from inside the memory layer: a fact, retrieved correctly, that happened to stop being true.

The agent isn't wrong about what it remembers in any of these cases; it's wrong about whether that memory still carries the authority to govern the action it's about to take. The clock said the grant was valid. The underlying world had already moved on.

A test described in that same source, CLAIM-24, pre-registers a specific version of this failure: a timestamp-only gate returns ALLOW on a grant that's still inside its TTL window but whose underlying conditions have already changed, a role downgraded from dev-reader to restricted, a scope ceiling narrowed. The gate approves the action because it checked the clock. It never checked the source of truth that the clock was supposed to represent. This test is vendor-authored and explicitly presented as a pre-registered scenario rather than an externally validated result. What makes it useful is that the scenario names, precisely and falsifiably, an architectural gap that timestamp-only gates leave open.

The fix that follows from naming the gap this clearly is a re-derivation gate: a component that reads from a source the agent has no ability to write to, checks that source at the moment of execution, and compares the current state against what the grant recorded back when it was first issued.

This same logic applies to production stakes at Iberdrola's deployment on Amazon Bedrock AgentCore, where the target workloads are change-request validation, incident enrichment, and change model selection. In each of those, the agent's recommendation is only as good as the state of the underlying systems at the exact moment the recommendation gets made, independent of the state of those systems back when the relevant knowledge was first written into memory. Authority freshness is the dimension that makes that distinction operational rather than philosophical.

Enforcing all four dimensions at the agent runtime layer

Recall, freshness, contradiction handling, and forgetting all point toward the same architectural conclusion: these checks belong in the runtime that sits between the agent and its memory store, not inside the model and not bolted onto individual applications after the fact.

A model has no persistent state to police. It receives a context window, produces an output, and retains nothing once the call ends. Whatever discipline governs recall, freshness, contradiction resolution, and forgetting has to live somewhere other than the model itself, because the model is stateless by construction and can't enforce rules about state it doesn't hold.

An individual application built on top of an agent faces the opposite problem: it's too narrow a vantage point. One application sees its own writes and its own reads, but the memory store it's drawing from is often shared, updated, and queried by other processes. A re-derivation gate checking authority freshness, a deterministic check confirming a conflict policy actually ran, a ForgettingCompliance check verifying a tombstoned fact stays gone, none of these can be enforced reliably from inside a single application's code path if the memory layer is shared infrastructure.

The runtime layer, the piece of infrastructure that mediates every read and write between an agent and its memory store, is positioned to see all four dimensions at once because every one of them expresses itself as a property of a read or a write. Recall is a property of a read: did it surface the right fact. Freshness is a property of a read compared against the store's write history: did it surface the newest version. Contradiction handling is a property of a write: did the system check for conflicting entries before committing, and did it log the resolution. Forgetting is a property of both: did a delete actually propagate to every tier of the stack, from in-context working memory down through episodic logs to semantic vector stores.

Enforcing all four at the runtime layer means every read and write passes through a point that can check freshness against a write history, check for conflicting canonical keys before committing new facts, and verify that deletes actually took effect across every tier rather than lingering in whichever tier happened not to get touched. That's a different engineering posture than scoring an agent's output after the fact and hoping the memory layer underneath behaved. Given that Mem0's own assessment lists freshness and forgetting as open problems at the tooling layer industry-wide, building that enforcement into the runtime, rather than treating it as a property an application developer has to remember to add, looks less like an optimization and more like the baseline a production agent needs before it's trusted with real consequences.