Invisible Contamination in AI Agent Memory: False Note Injection and Testing Blind Spots

1. The Core Problem: Memory Tests Miss Contamination Propagation

When teams test AI agent memory, they usually focus on three questions:

• Can the memory be retrieved after it is written?
• Can it be recalled after a restart?
• Is the recalled content relevant to the current request?

These cases are necessary, but they test only read-back, not automatic attachment. If an incorrect note is placed in an injected context that is automatically loaded into every new session, the agent may begin with a false premise. Its subsequent behavior, tool calls, and logs can all develop around that error.

Memory testing should therefore cover the full lifecycle of a memory item:

• How was it created?
• How was it abstracted into a note?
• When was it promoted into a structured representation?
• When did it enter the injection layer?
• How is it frozen when a conflict occurs?
• How does it expire?
• Can an old version reappear after a rollback?

More useful metrics include:

• Error survival time: The number of sessions or amount of time between an incorrect write and its correction or deletion.
• Propagation radius: The number of sessions, roles, projects, or tenants that load the memory.
• Correction cost: Whether the issue requires human intervention or can be fixed through offline review.
• Injection size and duplication rate: Whether the top-level context keeps growing or becomes dominated by similar notes.

The more automatic the memory system is, the faster contamination can spread. Injection context sits at the top of the memory stack. It is a small block of content loaded unconditionally into every new session, so it is closer to a production release than a draft notebook. Testing must validate writing, promotion, and injection as a release pipeline.

2. Define the Boundary: What Counts as Agent Memory?

To keep the discussion precise, memory here means knowledge the agent obtains from experience, retains across sessions, and can read later. It generally resides in external memory files, storage systems, or knowledge bases that the agent can read and write, rather than in model-weight changes.

The following categories should not be mixed into the same testing scope:

1. Weight changes: These belong to training or fine-tuning, not external memory files.
2. Learning within a single session: This is valid only in the current context and is not retained across sessions.
3. Compression that replaces earlier conversation turns with a summary: This affects context length but is not cross-session knowledge.

This boundary places testing on the agent’s memory files and injected content. Compression, summarization, and log pruning can have separate test suites, but they cannot replace memory-contamination testing.

Injection context is especially important because it is a derived artifact. It must be traceable to session logs or reviewed memory notes. Otherwise, it becomes an unauditable source of global contamination.

3. The Four-Layer Memory Stack and Its Contamination Surface

Agent memory can be modeled as four layers, with risk increasing from bottom to top:

Layer	Typical content	Risk	Testing focus
Session logs	Event streams, command output, conversation turns, and tool results	Relatively low, but large in volume	Searchability, completeness, immutability, and traceability
Memory notes	Observations, rules, and corrections the agent considers worth retaining	Medium; incorrect abstractions can become fixed assumptions	Source references, confidence, conflicts, and expiration policy
Structured representations	Interlinked knowledge pages, rule sets, and entity relationships	High; aggregation can amplify errors	Multi-source consistency, versioning, and citation completeness
Injection context	A small block automatically loaded into every new session	Highest; it spreads unconditionally	Admission gates, size, duplication, isolation, and rollback

There is usually an offline organization process between these layers. During idle periods, the system rereads logs, reviews notes, builds structured knowledge, and promotes the most reliable content into the injection layer.

This process is highly valuable for testing because it is the main channel through which a local error becomes a global assumption. An error in a lower layer can still be corrected through the original logs. Once it reaches the injection layer, every new session encounters it first, and correction requires rollback, conflict detection, and reinjection.

4. The Hidden Contamination Chain: How an Error Becomes a Global Premise

A false note typically creates global contamination through five steps:

1. Incorrect write: A biased observation, over-compressed summary, or incorrect location is recorded. For example, the agent cannot find an entry and writes, “The entry does not exist.”
2. Abstraction hardening: A temporary state is written as a stable conclusion, or a local rule is generalized into a global rule.
3. Automatic promotion: Without source validation, conflict checks, or a stabilization period, the note is promoted directly into the injection layer.
4. Behavioral drift: New sessions start from the false premise, skip verification, and stop exploring areas incorrectly marked as complete.
5. Self-reinforcement: Later logs record only behavior consistent with the false premise. If offline organization reads only the notes rather than the original logs, the error becomes even stronger.

A representative example can be found in a game environment. An agent records the location of an important landmark incorrectly and writes that the area has already been completed. On every restart, it begins from that assumption and does not return to the area. After repeatedly jumping down from a one-way staircase, it gives up. Later, an offline review compares the note with the original session logs, restores the correct location, and allows the agent to enter the target area and reach the next city.

The problem is not simply that the agent made a mistake. The problem is that the incorrect note was written into the layer loaded during every run.

The same pattern appears in enterprise codebases. If an incorrect note states that a module has been deprecated and is automatically injected into later sessions, an agent may skip dependency checks, causing duplicate changes or missed verification. In a large codebase, the mistake may not produce an immediate error. Instead, it persists as the agent confidently avoiding a particular area.

Testing should deliberately inject failures involving incorrect-note promotion rather than validating only successful retrieval.

5. Four Testing Dimensions

1. Correctness: Compare Against Original Logs, Not the Model’s Self-Description

Correctness testing should answer:

• Is the memory supported by original logs?
• Has the rule’s scope been generalized too broadly?
• Is there contradictory evidence?

Possible cases include:

• When logs say “the entry was not found,” a note saying “the entry does not exist” must not be promoted.
• Structured representations should require agreement across multiple sources.
• When new logs conflict with an old note, the old note should be frozen rather than continuously injected.

2. Propagation Radius: How Far Can an Error Spread?

Propagation-radius testing measures how many sessions, roles, projects, or tenants load an item from the injection layer.

Tests should verify that:

• A project-specific rule does not appear in another project.
• A temporary observation does not enter global injection.
• Sensitive information is not loaded across roles.
• Multi-tenant, project, and role-based isolation prevents an incorrect note from spreading through a shared injection layer.

3. Lifecycle: How Long Can an Error Survive?

Lifecycle testing covers writing, promotion, expiration, deletion, correction, and rollback.

Examples include:

• Expired content is no longer injected.
• After correction, the old version does not return.
• Deletion invalidates caches and derived contexts.
• After offline review identifies a conflict, the item can be downgraded to the note layer.

Without expiration policies and version control, an incorrect memory may survive indefinitely.

4. Correctability: Can the System Detect, Block, and Roll Back Errors?

Correctability testing should verify that:

• Offline review can compare notes with original logs and identify errors.
• Conflict detection can prevent promotion.
• After rollback, the next session no longer loads the incorrect content.
• The audit chain identifies the writer, source, and injection history.

Correctability is the baseline requirement for memory governance. Completely preventing incorrect writes is unrealistic, so the system must be able to contain and repair them.

Injection size and duplication rate should also be treated as admission metrics. The top-level context is not a complete notebook. It should contain a small set of reviewed, high-confidence items. Continuous growth and repeated blocks can crowd out important rules and make errors harder to locate.

6. Enforceable Gates for Injection Size and Duplication

The admission policy should allow only content that is traceable, reviewed, conflict-free, within budget, and correctly isolated to enter the injection layer.

def can_promote_to_injection(mem, cfg, injection_store):
    if not mem.provenance:
        return False  # Must include log references, writer, time, and trigger
    if not has_recent_log_support(mem):
        return False  # Must have support from original logs
    if conflicts_with_logs_or_notes(mem):
        return False  # Freeze when it conflicts with logs or structured representations
    if not passed_offline_review(mem):
        return False  # Requires offline review or a stabilization period
    if violates_isolation(mem, cfg):
        return False  # Enforce project, tenant, and role isolation
    if duplicate_ratio(mem, injection_store) > cfg.dup_limit:
        return False  # Merge or reject when duplication exceeds the limit
    if estimate_size(injection_store) + estimate_size(mem) > cfg.injection_budget:
        return False  # Downgrade to the note layer when the budget is exceeded
    return True
def build_injection_context(candidates, cfg):
    selected = []
    for mem in sort_by_confidence_freshness_and_usage(candidates):
        if not can_promote_to_injection(mem, cfg, selected):
            continue
        if total_size(selected) + estimate_size(mem) > cfg.injection_budget:
            break
        selected.append(mem)
    return selected

Admission-gate testing should cover:

• Rejecting notes without sources.
• Rejecting notes that conflict with other evidence.
• Keeping only one copy of duplicate notes, or merging them.
• Downgrading low-value content when the injection budget is exceeded.
• Isolating notes across projects.
• Preventing expired notes from loading.
• Ensuring that old versions do not return after rollback.

Thresholds should not be hard-coded as universal product parameters. They should be calibrated against the business context and budget, then monitored continuously in the evaluation pipeline.

7. A Decision Table: Which Layer Should Store the Information?

Information type	Default layer	Promotion conditions	Prohibited conditions	Testing focus
A single command output, conversation turn, or tool result	Session logs	Not promoted directly into injection	Direct entry into injection	Searchability and traceability
Reusable observation, local rule, or correction	Memory notes	Has log references and passes offline review	No source or conflict with logs	Source, confidence, and expiration
Stable knowledge from multiple sources, entities, and relationships	Structured representation	Multiple sources agree; versioning and complete citations are available	Single source, unverified content, or over-aggregation	Aggregation correctness and citation completeness
Frequently used, stable, cross-session core rule	Injection context	Source, stability, conflict, budget, and isolation checks all pass	Project-local content, temporary observations, high duplication, or budget overflow	Size, duplication, rollback, and propagation radius

This table turns “write a memory” into a controlled promotion process. By default, a new note should remain in the memory-note layer. Only content that has passed offline review, conflict checks, and, where appropriate, multi-source validation should move into structured representations. Only high-frequency, stable, cross-session content that passes every gate should enter injection context.

8. Test Case Checklist

The following cases should be added to the memory evaluation pipeline:

1. Over-compression: The log says “the entry has not been found,” while the note says “the entry does not exist.” Verify that promotion is rejected.
2. Globalizing a local rule: A rule from Project A must not be injected into Project B. Verify the isolation gate.
3. Duplication growth: Similar notes are written repeatedly. Verify that the injection layer keeps one copy or merges them.
4. Conflict update: An old note says “the module is deprecated,” while new logs show that it is still in use. Verify that the old note is frozen and corrected.
5. Expired-memory revival: After the TTL expires, the item must not be injected. Rolling back an old version must not make it load again.
6. Offline review: A note can be corrected using only the original logs, but the corrected version must still pass the promotion gates.
7. Size overflow: Content is downgraded according to confidence, freshness, and usage frequency. Verify that critical rules are not displaced by duplicate blocks.
8. Rollback recovery: After incorrect content is injected and rolled back, the next session returns to the expected behavior and does not reproduce the old error.
9. Audit traceability: Every injected item can be traced to its source log, review record, and version.
10. Multi-tenant isolation: Injection contexts are invisible across tenants, and derived structured knowledge does not cross tenant boundaries.

9. Conclusion: Test Top-Level Injection Like a Production Release

The key question in agent-memory testing is not simply whether “the agent remembers correctly.” It is how long an incorrect item can survive and how far it can spread.

Among the four memory layers, injection context carries the greatest risk because it is an unconditional global premise for every new session. Teams should treat memory writes like production releases:

• Start with the note layer by default.
• Require offline review and conflict checks before promotion.
• Enforce gates for provenance, stability, conflicts, size, duplication, isolation, and rollback.
• Use fault injection to verify that an incorrect note cannot be mounted globally by default.

Common cloud capabilities such as log services, object storage, monitoring, and alerting can help build the audit trail and trend dashboards. The core requirement, however, is the testing strategy: move from “read-back is correct” to “contamination is controllable,” and stop incorrect content before it reaches top-level injection.