Skip to content

Stale drawer retrieval can inject contradictory memory into live agent context; no official sync/update workflow exists #224

@WesleyZiwen

Description

@WesleyZiwen

Summary

The core issue here is not just that drawers do not have an update API, or that users need to manually synchronize data.

The bigger problem is that when knowledge has changed, MemPalace can still return stale drawer content through semantic search. Once those stale results are retrieved by an agent and inserted into the current context, outdated or contradictory memory can directly affect live reasoning in Codex / Claude.

This is a memory correctness risk, not just a maintenance inconvenience.

Reproduction

Example:

  1. A drawer is first filed with text containing status: active
  2. Later, the real status changes to deprecated
  3. I update the KG:
    • mempalace_kg_invalidate(... active ...)
    • mempalace_kg_add(... deprecated ...)
  4. mempalace_kg_query now reflects the new fact
  5. But mempalace_search can still return the old drawer text containing status: active

Why this matters

The issue is not only that the storage layers become inconsistent. It also affects the quality of the agent's live context:

  • the agent retrieves a stale drawer via mempalace_search
  • that stale drawer enters the current conversation context as verbatim evidence
  • the agent continues answering, summarizing, reasoning, or making decisions based on outdated facts
  • if that incorrect reasoning is later written back into memory, the error can spread further

In other words, this is not model parameter contamination, but it can absolutely contaminate the live context used in the current session.

Why this seems easy to trigger in the current design

From the current implementation, this behavior is understandable:

  • drawers and the KG are stored separately
  • the KG supports temporal fact updates, but drawers have no official update semantics
  • MCP only exposes mempalace_add_drawer and mempalace_delete_drawer
  • mempalace_search does not return drawer_id, so users cannot easily identify and repair stale drawers from search results
  • mine skips already-filed source_files, so re-running mining is not a refresh mechanism

Expected behavior

At minimum, one of these two directions should be clearly supported:

Option 1: Document the current model explicitly

  • clearly state that drawers are immutable historical snapshots
  • clearly state that the KG is the source of truth for current facts
  • clearly document how users are expected to synchronize drawers, KG, and source files when facts change
  • clearly warn that partial updates can cause stale content to be injected into live agent context through semantic search

Option 2: Provide an official sync/update path

  • add something like update_drawer or sync_source_file
  • or return drawer_id from mempalace_search
  • or support re-mining a source_file with replacement/upsert semantics instead of skipping it
  • ideally, consider KG-aware filtering or contradiction warnings before stale content is injected into context

Why this is important

The current behavior makes it easy for users to assume MemPalace behaves like an updatable memory system or a wiki-like source of truth.

But in practice it behaves more like:

  • drawers preserve historical verbatim snapshots
  • the KG preserves temporal facts
  • the two layers do not automatically stay in sync

If this model is not explicitly documented, users can easily end up with contradictory memory states after partial updates, and those contradictions can directly affect live agent behavior.

Suggested improvements

  • include drawer_id in mempalace_search results
  • add mempalace_update_drawer or mempalace_sync_source_file
  • document the consistency boundary between drawers and the KG in the README and MCP protocol
  • add KG conflict detection or at least a warning before potentially stale search results are injected into context

Question

Is the official MemPalace model currently intended to be:

  • drawers as append-only historical memory snapshots
  • KG as the current fact layer
  • synchronization left to the user

If yes, that model should be made explicit in the docs and tool interfaces.
If not, then the lack of an official drawer sync/update workflow creates a real memory correctness problem.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/searchSearch and retrievalbugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions