Self-Correcting Memory in Persistent Agent Knowledge Bases

Persistent agent knowledge bases need more than the ability to remember. They need to recognize when stored knowledge is wrong, repair what depends on it, and withdraw corrections that cause harm. Self-correction is the architectural prerequisite that makes persistent memory safe to rely on.

Why a persistent agent memory is only as useful as its capacity to self-correct

An agent learns a fact, stores it, and later acts on it after the fact has changed. Retrieval worked just as it should, but the agent acted on bad information. The system failed by preserving a claim without preserving a way to question it. Confidence in recall has become misplaced confidence in truth.

Agents that reset after every session cannot accumulate knowledge, while agents that retain state can accumulate errors as readily as insights. The Always-On Agents survey describes a lifecycle that moves from observation through writing, validation, organization, retrieval, and action, then returns through updating, forgetting, auditing, and rollback. It finds that research concentrates on accumulation and retrieval while governance and recovery remain thin. That imbalance matters because it is easier to show that memory grows than that it stays accurate. The self-correction gap begins where remembering succeeds but responsibility for maintaining the remembered claim ends.

What stale knowledge actually does to an agent operating on accumulated state

Stale knowledge comes in through retrieval, becomes a premise the agent reasons from, and shapes what it does next. A retrieval-backed store without an internal model of time may return both an old fact and its replacement, leaving the agent to arbitrate. The STALE benchmark tests whether agents can detect invalidated memory across a broad set of scenarios. Its best-performing model reached only a bare majority. Detecting staleness is therefore not a dependable ability that storage systems can simply leave to the model.

The Always-On Agents survey separates update selection, which decides that a fact has changed, from propagation, which revises what depended on it. It finds propagation nearly unstudied. ReTree, from Shanghai Jiao Tong University, identifies the resulting failure in search agents. Standard compression methods can replace an erroneous fact while leaving downstream reasoning derived from it intact. Those branches remain logically stranded, so correcting a stored claim can leave the agent’s working conclusions wrong. Uncontrolled memory is not just additional knowledge but a hidden set of unaudited commitments.

Why self-correction cannot be an add-on layer and must be built into the write path

If an audit finds an error only after the agent has acted, it cannot prevent that action. Correction therefore has to start at or near the time of the write, before the system trusts the proposed knowledge as state. The Always-On Agents survey calls validation “the missing gate” between writing and organizing. Skipping that gate treats an observation as ready for durable use merely because the agent produced it.

WikiSkill, from Google Research and Virginia Tech, makes that decision structural. Its gate tests each proposed skill change on a separate validation set before committing it, and rolls the skill back if the change does not help. Crucially, the failed proposal remains in the wiki. The system rejects the change without throwing away the knowledge of what was tried and why it failed. Otherwise, a later proposal can rediscover the same dead end.

EvoSC, from UCAS, HKISI-CAS, and Nanjing University of Science and Technology, approaches the same gap through contrastive reflection. It extracts error-prone patterns to avoid and successful patterns to replicate from each iteration. Retrieving only successful trajectories loses the guidance contained in failure. Together, these mechanisms distinguish a deployable skill from the evidence used to develop it. A knowledge base needs both, because knowing that an approach worked is less useful than knowing the conditions under which it worked or failed.

The scoping problem: why a locally valid correction can corrupt knowledge across unrelated tasks

Where does the evidence authorize the correction to apply? Scope Before You Persist demonstrates the stakes on PROCSTREAM-RSI, where a global-memory baseline performs below a static agent with no memory at all. Locally valid edits interfere with unrelated task families.

The paper separates certification, which asks whether an update is supported, from retrieval scope, which determines where it can be used. Its scoped-retrieval intervention changes the deployment domain without changing the accepted edit or the gate decision. Family-scoped retrieval eliminates harmful deployments and substantially increases useful accepted updates in randomized-order stream tests.

The same risk applies beyond code repair. A customer-service agent that learns a workaround for one product class and applies it to another crosses the same boundary. Scope therefore needs to be stored with the knowledge item at write time so the agent has it when retrieval occurs, without having to guess. The evidence that certifies an update also defines its deployment boundary.

How knowledge-graph and temporal memory structures make staleness detectable rather than invisible

Enforcing that boundary requires a representation that can express it. A flat vector store does not by itself represent time, provenance, or contradiction, so competing claims can remain available without a recorded relationship between them. The Always-On Agents survey assesses persistent state through six axes, namely authority, scope, mutability, provenance, recoverability, and actionability. These ask who may write a claim, where it applies, how it changes, where it came from, whether it can be recovered, and what it can cause. These questions guide how memory systems are built as well as how they are compared.

Temporal knowledge graphs attach validity periods to facts, making expiration queryable rather than something the agent must infer from competing passages. An expired fact can then be flagged or excluded instead of appearing beside current knowledge without qualification. Provenance supports a different operation. It connects a claim to the evidence that may need revisiting. Without that connection, a system lacks the record needed to localize a repair.

ReTree keeps this record in evidence nodes that hold bounded summaries, evidence linked to its source, and a history of revisions. When new evidence contradicts a claim, it traces the claim to its originating node, replaces the evidence, regenerates summaries, and prunes affected branches before resuming. This structure lets the system fix the affected part and keep the rest of the knowledge base. Recoverability matters too, because the correction itself may be wrong. A representation that supports updates but not rollback leaves that second error without a reliable route back.

What the OS-layer analogy reveals about who should manage correction

Once correction depends on authority, scope, provenance, and recovery, it becomes a question of responsibility within the stack. Should every application build these controls independently? The Always-On Agents survey uses an agentic-OS analogy to place the duty to handle state identity, isolation, durability, and recovery with the infrastructure. Virtual memory management belongs to the operating system. By the same logic, persistent-state governance belongs to the agent runtime.

The distinction matters most when memory can authorize action. The survey separates remembered facts and procedural skills from control-relevant state, including permissions, task ledgers, trigger conditions, and external commitments. Stale state in that second category can have external consequences, so correction cannot be treated as text editing alone. WikiSkill keeps immutable raw traces, a persistent wiki, and the active skill separate. The trace preserves evidence, the wiki supports revision, and the skill is what gets deployed.

That separation lets the runtime expose validation, scoped writes, and rollback as operations with consistent rules. Application logic can call those operations and use the safeguards already built into them. Correction then becomes auditable and enforceable across hosted agents, rather than a scattered set of application conventions.

How production incident-response agents handle the tension between learned memory and case-by-case judgment

Two incidents can look alike while having different causes, so a remembered resolution may be useful evidence without being an authorized response. MemoryOps makes this distinction explicit in its design. Historical solutions should influence investigation.

AWS DevOps Agent, built on Amazon Bedrock AgentCore, analyzes past investigations to identify patterns and improve future troubleshooting workflows. Its production use at WGU showed a measured reduction in mean time to resolution. Azure SRE Agent continuously observes production environments and reasons across logs, metrics, code changes, and deployment records. It handled tens of thousands of incidents autonomously at Microsoft internally over a nine-month period. These cases establish that agents operating across continuing production work are not just a research setting.

They do not remove the boundary between learning from an incident and judging a new one. A past resolution is certified within its original context. MemoryOps has humans review memory before it shapes what the agent does. The review recognizes that the original evidence may not represent the differences that matter now.

The adversarial dimension: when persistent memory becomes a target for intentional corruption

The same path that preserves an innocent mistake can preserve a planted instruction. An attacker causes an agent to store malicious content, then a legitimate task brings it back into use weeks later. The attacker changes how the agent behaves in later sessions without changing the model. The delay between the write and the harmful action also makes the source harder to trace.

The CoSnitch vulnerability in Microsoft Copilot, CVE-2026-24301, demonstrated this in production. Instructions in web content that an attacker controlled entered Copilot’s long-term memory when a victim asked it to summarize the page. They persisted into later, unrelated sessions. The vulnerability, patched server-side August 18, 2026, exposed a failure to validate the authority of content entering persistent memory. Material supplied for summarization had crossed into state that could govern later behavior.

The Always-On Agents survey’s authority axis asks who or what is permitted to write a state item. Write-time authority checks, provenance, and rollback help a system resist and recover from poisoning without relying only on its ability to spot malicious intent. Scope controls also limit where the system can use what it has stored. These properties subject planted instructions to the same scrutiny required for safe learning.

What a self-correcting knowledge base requires the agent runtime to provide

The runtime requirements follow directly from these failures. Every proposed durable write should pass through an execution-grounded validation gate before it becomes active knowledge, and its authority should be checked as it enters. Failed proposals should remain available in structured records so future attempts can learn from them without deploying them. Accepted updates should carry their certification evidence and scope from the moment they are written. This keeps support for a claim tied to the boundary within which it may be used.

Every state item also needs provenance, including where it came from and when, so a disputed claim can be traced and its dependents repaired. Rollback must be a first-class operation because validation cannot guarantee that every correction will remain sound. The memory used to evolve knowledge should also be separate from what the executor reads at inference time. WikiSkill’s ablation found that giving the inference agent direct access to the wiki degraded performance. Evidence useful to the proposer can become noise at the point of action.

Applications still supply task logic, but they should not have to reinvent the rules that make durable state trustworthy. The database analogy is the closing test. Just as applications rely on a database’s ACID properties rather than rebuilding transaction logic, agents need correctness guarantees for persistent state from the infrastructure layer.