The Hidden Contamination of AI Agent Memory: How Incorrect Notes Spread Across Sessions

1. The Real Danger Is Not Misremembering, but Reusing the Error

In AI agent systems with cross-session memory, the most overlooked problem is not an inaccurate answer in a single interaction. The greater risk is that an incorrect piece of information is written to a high-priority memory layer and automatically injected at the start of every later session.

An error in an ordinary conversation usually affects only the current context. The user may ask again, provide additional facts, or start a new session, allowing the error to disappear naturally. However, if the error is saved as a long-term note and placed in context that is loaded for every session, it is no longer a one-time mistake. It becomes global state that continuously influences decision-making.

The problem can be abstracted as follows:

Incorrect judgment
    ↓
Incorrect information written to long-term memory
    ↓
Incorrect information enters the automatic injection area
    ↓
The information is loaded in every new session
    ↓
The agent continues reasoning from a false premise
    ↓
New behavioral results reinforce the incorrect memory

This creates a feedback loop. Instead of being corrected, the information gains an appearance of credibility because it is repeatedly retrieved and read.

Therefore, memory testing should not ask only:

Was this answer correct?

It should also ask:

• How long will the incorrect information be retained?
• How many later sessions can it affect?
• Can it be copied into additional memory layers?
• After the user provides a correction, does the old information actually leave the system?
• After deletion, can residual content still influence the model?

2. Four Layers of Agent Memory

To locate risks accurately, a memory system can be divided into four layers. Their storage methods, retrieval frequency, and contamination scope are different.

1. Session Logs: The Most Complete Facts, but Not Always the Easiest to Retrieve

Session logs record the original events in an interaction, including user input, agent output, tool calls, execution results, errors, and intermediate states.

Their main characteristics are:

• High information completeness
• Clear chronological order
• A significant amount of redundant content
• The need for retrieval or reanalysis before they can be used effectively

Session logs are closest to the original evidence. Even when an agent reaches an incorrect conclusion, the logs may still contain the correct user description, tool output, or environmental feedback.

Testing should verify that when a long-term note conflicts with the original log, the system can return to the original evidence instead of unconditionally trusting a generated summary or conclusion.

2. Memory Notes: Compressed Experience and the Most Likely Source of Factual Drift

Memory notes are usually generated by the agent to preserve rules, preferences, task progress, environmental constraints, and historical experience.

For example:

User preference: Responses should be written in English.
Project constraint: Static checks must run before deployment.
Task status: A particular module has already been migrated.
Environment fact: The target directory is located at a specified path.

These notes are easier to use than raw logs, but they carry an obvious risk: they are often the model’s interpretation of past events rather than the original facts themselves.

An execution may produce an incorrect note because observations were incomplete, a tool returned an abnormal result, or the model made a wrong judgment. Without evidence validation, confidence labels, and expiration rules, that note may remain in the system indefinitely.

3. Structured Memory: Useful for Relationships, but Capable of Amplifying Errors

When memory notes are organized into entities, relationships, topics, or linked pages, they become a more structured representation of memory.

Structured memory can improve retrieval efficiency. For example, it may connect the following information:

Task A → uses Component B
Component B → depends on Configuration C
Configuration C → applies only to Environment D

However, structure also creates longer paths for error propagation. One incorrect note may be converted into multiple nodes and relationships. During later retrieval, the same error may appear from several perspectives, making it seem more certain.

Structure is therefore not inherently reliable. The system must preserve the source, timestamp, confidence level, and verification status of each item. Otherwise, the more complex the structure becomes, the harder it is to remove errors completely.

4. Injected Context: The Widest Propagation Scope and the Highest Admission Threshold

Injected context is automatically loaded when a new session starts. It usually contains information considered important, stable, and worthy of priority.

Its advantage is low retrieval cost. Its weakness is the largest contamination scope. Once an incorrect item enters the injection area, later sessions may continue to be affected, even when the current user never mentions the related topic.

The risks of the four layers can be summarized as follows:

Memory Layer	Primary Value	Typical Risk	Default Testing Focus
Session logs	Preserve complete evidence	Redundant content and difficult retrieval	Whether original facts can be traced
Memory notes	Capture experience and rules	Summarization bias and stale facts	Whether sources and confidence are recorded
Structured memory	Support relationships and retrieval	Propagation of incorrect relationships	Whether deletion and updates are complete
Injected context	Provide immediate priors	Global contamination and repeated reinforcement	Size, priority, and lifecycle

3. Why Incorrect Memories Reinforce Themselves

Agents typically interpret new observations based on their current memory. If the starting assumption is wrong, later information may also be interpreted incorrectly.

Suppose the system records, incorrectly, that a target area has already been completed. When the next task begins, the agent may:

1. Skip the area;
2. Interpret related signals as irrelevant;
3. Attribute the incomplete state to another cause;
4. Generate another note stating that the area does not require processing.

This creates confirmation bias:

Incorrect prior → Incorrect action → Incomplete feedback → Incorrect interpretation → New incorrect prior

Automatic injection makes the problem worse because the incorrect memory does not need to be retrieved manually. It is displayed again at the beginning of every session. Repeated exposure can cause the model to treat the content as a stable fact, creating the illusion that frequently recalled information is more trustworthy.

Memory systems must therefore measure not only write success, but also how quickly incorrect content spreads and how costly it is to recover from the error.

4. Four Testing Dimensions That Must Be Covered

1. Accuracy: Is the Memory Consistent with Evidence?

Accuracy testing is not simply a check of the final answer. It verifies whether the memory itself is supported by original evidence.

Each memory item should ideally retain metadata such as:

{
  "content": "The target directory is located at a specified path",
  "source": "Tool result from a previous session",
  "created_at": "timestamp",
  "confidence": 0.82,
  "status": "unverified",
  "expires_at": "timestamp"
}

Key tests include:

• Does the note reference actual user input or tool output?
• Are model inferences incorrectly labeled as objective facts?
• When sources conflict, does the system prioritize more reliable evidence?
• Does the note distinguish verified facts from assumptions that still require confirmation?

Three types of test data are useful:

• Clearly correct information
• Ambiguous information that may be valid
• Plausible-looking information that is actually incorrect

Observe whether the system writes all three into long-term memory with the same priority.

2. Lifecycle: How Long Can Incorrect Information Survive?

Memory must have a lifecycle rather than exist permanently.

Testing should cover:

• Creation
• Updating
• Expiration
• Deletion
• User correction
• Replacement by new evidence
• Cascading cleanup of related content

For example, if a user explicitly says that a previous path is no longer valid, the system should perform at least three actions:

1. Update the status of the original note;
2. Prevent the old note from entering injected context;
3. Remove structured relationships derived from the old note when necessary.

Simply adding a new note saying that the path has changed is insufficient if the old information remains active. Otherwise, both the old and new versions may be injected at the same time.

3. Propagation Scope: How Many Sessions Does One Error Affect?

Assign each test memory a unique identifier and track how often it appears in each layer:

memory_id = M-001
Occurrences in logs: 1
Occurrences in notes: 1
Occurrences in structured pages: 3
Occurrences in injected context: N
Affected sessions: K

Pay particular attention to whether:

• One incorrect note is copied into multiple topics;
• It enters unrelated new sessions;
• It is concatenated into system instructions or high-priority context;
• It affects different users, projects, or tenants.

In multi-user systems, isolation must also be verified. One user’s incorrect memory must not be readable by another user. It must not spread across boundaries because of a shared index or incorrect permission configuration.

4. Recovery: Does the System Actually Recover After Correction?

Recovery testing is often neglected, but it determines whether a system can self-correct after an error.

Test scenarios should include:

• The user directly corrects the error;
• A tool returns a new fact that conflicts with memory;
• Offline processing finds a mismatch between a note and the original log;
• An administrator deletes a memory;
• The system rolls memory back to an earlier version.

A valid recovery process should follow this pattern:

Detect conflict
  ↓
Lower the priority of the old memory
  ↓
Mark it as unverified or invalid
  ↓
Update related structures
  ↓
Prevent the old content from being injected
  ↓
Use the new fact in subsequent sessions

If the system can only add correct content but cannot revoke incorrect content, it does not have real memory governance.

5. Add Size and Duplication Gates to Injected Context

More automatically injected content does not necessarily reduce risk. An oversized context creates at least three problems:

• Important facts are diluted by low-value content;
• Conflicting memories appear together;
• Repeated content increases the apparent credibility of incorrect information.

The following controls are therefore recommended.

1. Size Gate

Set a maximum length or maximum number of entries for injected context. When the limit is exceeded, the system should not simply truncate the content. It should rescreen entries according to priority.

A possible priority order is:

Verified facts
> Information directly related to the current task
> Explicit user preferences
> Recently updated content
> Historical inferences
> Unverified observations

2. Duplication Gate

Deduplicate semantically similar memories so that the same fact is not repeated with different wording.

For example, the following items should be treated as one group:

The target directory is path A
The project directory is path A
The repository root is path A

Deduplication should detect not only identical strings, but also semantic repetition and contradictions.

3. Conflict Gate

When two memories describe different facts, the system must not inject both without an explanation.

It should make the conflict explicit:

Old fact: The target directory is path A, based on an earlier session
New fact: The target directory has changed to path B, based on a recent tool result
Resolution: Downgrade the old fact; mark the new fact as pending confirmation or activate it

4. Source Gate

A memory without a source, timestamp, or verification status should not be placed directly in the highest-priority injection area.

6. Which Content Belongs in Which Layer?

The following table can help design memory-writing policies:

Content Type	Recommended Layer	Reason
Raw interactions, tool results, and errors	Session logs	Preserve complete evidence
Confirmed rules that may be reused later	Memory notes	Enable cross-session use
Relationships among multiple stable facts	Structured memory	Support relationship-based retrieval
Highly stable, low-dispute, frequently used information	Injected context	Reduce repeated retrieval cost
One-time inferences or unverified guesses	Do not promote yet	Avoid contaminating long-term memory
Task states with a clear validity period	Short-term notes	Prevent stale information from persisting

The core principle is:

The closer information is to the automatic injection layer, the higher the admission threshold should be. The more uncertain the content, the longer it should remain in a traceable and verifiable lower layer.

Do not place information into global context simply because it appears useful. First determine whether it is stable, verifiable, clearly sourced, and limited in impact if wrong.

7. An Executable Memory Testing Checklist

Before launch, validation can follow this sequence:

1. Inject an incorrect fact and confirm whether it is written to long-term memory;
2. Start multiple new sessions and measure how far the fact spreads;
3. Have a tool return the correct result and check whether the conflict is detected;
4. Explicitly correct the error as a user and verify whether the old memory is downgraded or deleted;
5. Check whether derived relationships remain in structured memory;
6. Verify that a deleted memory cannot still be read in new sessions;
7. Test filtering and downgrade behavior when context limits are exceeded;
8. Test synonymous duplicates, version conflicts, and expired information;
9. Test isolation across users, projects, and permission boundaries;
10. Measure the time between error discovery and the complete cessation of injection.

Useful metrics include:

Error survival time = Time from writing the incorrect memory to complete invalidation
Propagated session count = Number of sessions that read the incorrect memory
Residual rate = Proportion of related content still retrievable after deletion
Correction success rate = Proportion of sessions that use the new fact after correction
Injection duplication rate = Share of duplicate or near-duplicate entries in injected context

These metrics reveal the practical quality of a memory system more effectively than answer accuracy alone.

8. Conclusion: Memory Governance Matters More Than Memory Storage

The value of agent memory comes from turning past experience into future efficiency. Its risk comes from the same cross-session persistence.

An incorrect item that remains only in an original log usually has limited impact. Once it is summarized into a memory note, its scope expands. If it is then converted into structured relationships and automatically injected into new sessions, it can become a long-term source of system-wide contamination.

Memory engineering must therefore address more than remembering more. It must also provide:

• Evidence traceability
• Confidence management
• Lifecycle control
• Conflict detection
• Automatic injection gates
• Deletion and rollback
• Isolation across users and scopes
• Recovery verification after errors

The essential engineering principle is:

Memory is not better because there is more of it. It is better when it is more verifiable, more reversible, and easier to control in terms of propagation.

Only when a system can answer where a piece of information came from, whether it is still valid, whom it affected, and how to remove it completely can agent memory become both useful and governable.