Overturning Incorrect Notes in Long-Term Agent Memory

1. Why long-term memory raises both value and risk

Long-term memory is usually added to an agent to solve three problems: reuse experience across sessions, avoid repeating exploration, and keep goals and constraints consistent on complex tasks. Memory lets the agent avoid starting from zero each time, and it turns tool results, user preferences, and environment rules into a basis for later action.

Once memory enters the decision path, an error is no longer a one-off wrong step. It can become a faulty premise that keeps shaping how later events are interpreted. Worse, the agent often does not treat a new observation as a negation of an old note. It uses the old note to explain the new observation. The incorrect note is not overturned; because the story still “fits,” it is reinforced.

The core question is: when does a wrong note actually get a chance to be overturned? This is not simply “delete the bad memory.” It is a system design problem covering memory structure, evidence traceability, conflict handling, verification, and diagnosis.

2. A pathfinding case: how a wrong landmark locks in a wrong explanation

Consider a generic pathfinding task. The agent has a navigation tool, a map summary, and a writable route-memory directory. The goal is to cross a region from the entrance side to the exit side, then continue to the next supply point.

The environment has these facts:

• The entrance is on the west side and the exit is on the east side.
• The supply point is near the entrance, not near the exit.
• Near the entrance there is a one-way drop; after jumping down, the agent returns to the old path.
• The navigation tool does not show this drop.
• The agent’s note places the supply point near the exit.

After leaving the supply point, the agent uses the wrong note to conclude that it has already crossed the region, and updates the note to “region complete.” After a few actions it crosses the one-way drop and falls back onto the old path. Because it cannot climb the step directly, it should notice that the “complete” judgment was wrong. In the actual run, it instead explains the return as “I overshot westward.” From its point of view, the location judgment is still correct; it only walked a bit too far.

The key point is not a single navigation mistake. A wrong landmark determined the route, the wrong outcome was explained as an overshoot, and the landmark note therefore survived. New observations entered the context, but the premise used to interpret them did not change. Similar reversals happened several times until loop pressure became obvious and the agent said it would stop looping. After the experiment environment’s automatic reply told it to continue, it returned near the start to seek treatment and supplies.

As a technical problem, this abstracts to:

1. A memory note contains a false fact.
2. New observations potentially conflict with that fact.
3. The agent uses the false fact to explain the new observations, so the conflict is dissolved.
4. There is no independent evidence layer and no conflict detection.
5. Verification only checks whether the task continues, not which premises the decision reused.

3. Root causes: why a wrong note is hard to overturn

3.1 Summaries replace raw records and break the evidence chain

Many agent memory systems store only conclusion-style summaries, such as “this region is complete” or “this route is passable.” Summaries are small and fast to retrieve, but they drop source, context, and tool results. Once a conclusion is wrong, later steps cannot answer: which session produced this note, what was observed, what the tool returned, and how the agent explained it.

Without the raw record, there is no way to check how an experience was formed, or whether a new observation is counterevidence. A summary can be an index. It cannot stand in for evidence.

3.2 Facts, interpretations, and memory are mixed together

In the case, “the supply point is near the western entrance” is a fact, “I have already crossed the region” is an interpretation, and “region complete” is a memory note. If all three live in one natural-language field, the system cannot tell whether the fact, the interpretation, or the written note is wrong.

Stored in layers, they can be checked separately: do tool results support the landmark location, does the agent’s interpretation match those results, and does the note claim more than the evidence supports?

3.3 New evidence is assimilated by the old premise

Agents tend to keep existing judgments coherent. When a new observation conflicts with an old note, the agent may invent an auxiliary explanation that preserves the old premise, such as “I overshot.” That explanation can look locally reasonable while hiding the real contradiction.

Conflict detection therefore cannot only ask whether a new observation is abnormal. It must also ask whether the observation directly contradicts a premise of some memory. A direct contradiction should enter a revision or contradiction-marking flow, not only generate another explanation.

3.4 Verification looks at outcomes, not reused premises

A task that keeps running, a test that passes, or a flow that does not break does not mean the memory is correct. Both the old note and a corrected note can make a test green. If verification does not record what was queried, how it was judged, and what was executed, there is no way to tell whether success rested on a false premise.

3.5 Retrieval failure and usage failure are not separated

An error may come from failing to find the right note, or from finding it and failing to use it. Without that split, the fix is unclear: retrieval problems need index and recall changes, condition-understanding problems need memory structure and prompt changes, and action-selection problems need policy and constraint changes.

4. Design principles that make a wrong note overturnable

4.1 Keep raw records traceable; use summaries only as an index

Use an append-only event log for raw records, including user constraints, tool inputs, tool results, agent explanations, environment feedback, and time order. Memory notes cite raw events through evidence_id. Summaries may be generated, but they must be traceable back to the source.

A generic record can look like this:

{
  "episode_id": "run_001",
  "events": [
    {
      "event_id": "e1",
      "type": "tool_result",
      "tool": "navigation",
      "input": {"target": "exit"},
      "result": {"position_hint": "near_entrance", "visible": ["one_way_drop"]}
    },
    {
      "event_id": "e2",
      "type": "agent_explanation",
      "text": "I may have overshot westward.",
      "based_on": ["e1", "memory_note_7"]
    }
  ],
  "memory_notes": [
    {
      "note_id": "memory_note_7",
      "claim": "supply_point_is_near_exit",
      "confidence": 0.6,
      "evidence_ids": ["e0"],
      "conditions": ["if_map_summary_trusted"],
      "status": "pending_verification"
    }
  ]
}

The important points are that agent_explanation and tool_result are stored separately so interpretation does not contaminate facts, and that memory_note carries evidence_ids and conditions so it can be checked later.

4.2 Experience must carry conditions and a source

An experience should not be written only as “this action works.” It should say under what conditions, for what goal, and on what evidence the action works. For example, in one task the agent could not change source code and bypassed a restriction by setting an environment variable. If that experience is compressed into “tests must set this variable,” a temporary workaround becomes a false rule.

A more reasonable record is:

{
  "claim": "can_use_env_var_to_bypass_source_change_restriction",
  "scope": "temporary_workaround",
  "preconditions": [
    "cannot_modify_source_code",
    "only_current_test_environment"
  ],
  "source_episode": "run_042",
  "evidence_ids": ["e10", "e11"],
  "confidence": 0.7,
  "expires_when": "environment_or_policy_changes",
  "contradictions": []
}

Later, the agent must check those preconditions before using the experience. If they do not hold, the temporary workaround must not be promoted to a general rule.

4.3 Treat “not mentioned,” counterevidence, and vague sources differently

Three kinds of uncertainty should not be collapsed into one:

• Not mentioned: one session not mentioning a fact does not make the fact false. Keep the note, do not raise confidence, and mark it pending verification.
• Clear counterevidence: when a new observation directly negates a premise or result, revise the note, split its conditions, or mark a contradiction, and keep the historical version.
• Vague source: when the source is unclear or the evidence chain is incomplete, lower certainty and require re-verification. Raise confidence only after multiple sources agree.

A simple conflict policy:

Situation	Handling
New session does not mention it	Keep the note, do not raise confidence, mark pending
Clear counterevidence	Revise or split the note, mark contradiction
Vague source	Lower confidence, send to review queue
Multiple sources agree	Raise confidence, but keep the evidence chain
Repeated reversals or loops	Trigger a memory audit and generate candidate revisions

4.4 Offline review should propose revisions, not overwrite immediately

A background memory-maintenance job can replay raw events, find contradictions, expired conditions, and low-confidence notes, and generate candidate revisions. Those candidates should not overwrite live memory at once. They should enter a verification queue and gain confidence only after a small probe or a controlled comparison task confirms them.

Memory maintenance then becomes a loop of hypothesis, verification, and adoption, rather than a one-shot write.

5. Verification: after a test passes, check which premises were reused

Correctness of memory cannot be judged only by whether the task finished. At least three comparisons are useful:

1. Disable the old note: on the same task, remove the suspicious note and see whether behavior changes.
2. Substitute a candidate note: replace the old note with the corrected one and see whether reversals or contradictions decrease.
3. Record the decision trace: save which notes were queried, how conditions were judged, which tools were called, and which actions were taken.

Verification should answer three questions:

• What did it look up? Were the relevant notes recalled?
• How did it judge? Did it correctly understand the note’s conditions of use?
• What did it do? Did the action match the judgment?

If the test passes while the agent still follows the wrong landmark, the pass is only an outcome pass, not memory correctness.

6. Diagnosis: failing to find a note is not the same as failing to use it

When behavior looks wrong, split the diagnosis first:

• Retrieval problem: the correct note is in the store but was not recalled. Check the index, query construction, context budget, and recall strategy.
• Condition-understanding problem: the note was recalled, but the agent did not recognize its preconditions or scope. Change structured fields, prompt constraints, and condition checks.
• Action-selection problem: the agent understood the conditions but chose the wrong action. Check policy, tool constraints, and execution checks.

A practical test is to place the correct note directly in context and rerun the same task. If the problem disappears, it is more likely a retrieval problem. If it remains, it is more likely a condition-understanding or action-selection problem. Then replace the wrong note with explicit counterevidence and see whether the agent revises its judgment.

7. Implementation checklist

1. Store raw events, tool inputs and outputs, agent explanations, and memory notes in separate layers.
2. Every note must carry source, conditions, confidence, and an expiry policy.
3. Summaries are only an index and must be traceable to raw evidence.
4. Define separate handling for “not mentioned,” clear counterevidence, and vague sources.
5. Trigger a memory audit on repeated reversals, loops, and anomalous explanations.
6. During verification, record query, judgment, and execution traces, and compare a run with the old note disabled.
7. Diagnose “note not found” separately from “note not used.”
8. Verify candidate revisions before adoption, and keep historical versions.

8. Conclusion

Long-term memory is not finished once a conclusion is written into a directory. A usable memory system must let every experience answer where it came from, under what conditions it holds, whether new evidence supports it, whether it conflicts with other notes, and whether verification actually used it. Wrong notes are hard to overturn less because new evidence is missing than because the old premise is still explaining that evidence. Layered raw records, conditional experience, graded conflict handling, comparative verification, and split diagnosis are what move agent memory from “it accumulates” to “it can be audited, corrected, and updated.”