Summary
memory_correct has two modes, and they behave differently:
memory_correct(memory_id="<id>", new_content="...") — delete+recreate: old ID is gone, new ID returned
memory_correct(query="<keywords>", new_content="...") — create only: old memory survives untouched, a new independent memory is created with a different ID
This means "corrected" content can coexist with the original, returning contradictory results in future searches.
Steps to Reproduce
- Store a memory with
memory_store(content="original-text", memory_type="working") → returns ID_A
- Correct it:
memory_correct(query="original-text", new_content="corrected-text") → returns ID_B (different from ID_A)
- GET
/v1/memories/ID_A → still exists with is_active: true
- Search for "original-text" → both ID_A (old) and ID_B (new) returned
Expected Behavior
Both modes should behave consistently. Either:
Option A (preferred): memory_correct(query=...) should also delete the matched memory before creating the new one, matching memory_id mode.
Option B: If query-mode intentional design is to preserve the original, the documentation should explicitly say so, and the response should include "superseded_memory_ids": [...] so callers know which old memories to purge.
Additional Suggestion: ID change transparency
memory_correct in either mode silently changes the memory ID. Any external reference (work-notes, lessons, skill docs, code comments) that hardcodes the old ID will break without any warning.
Suggestion: the response of memory_correct should include:
{
"memory_id": "<new_id>",
"obsolete_memory_id": "<old_id>",
"warning": "⚠️ Old memory_id <old_id> is no longer valid. Update all references."
}
Or alternatively, add a keep_original_id: boolean parameter — if the backend cannot update in place, return an explicit error explaining why.
Environment
- API: api.thememoria.ai/v1
- Observed: 2026-06-01
- Tools tested:
memory_correct(memory_id=...) vs memory_correct(query=...)
Summary
memory_correcthas two modes, and they behave differently:memory_correct(memory_id="<id>", new_content="...")— delete+recreate: old ID is gone, new ID returnedmemory_correct(query="<keywords>", new_content="...")— create only: old memory survives untouched, a new independent memory is created with a different IDThis means "corrected" content can coexist with the original, returning contradictory results in future searches.
Steps to Reproduce
memory_store(content="original-text", memory_type="working")→ returns ID_Amemory_correct(query="original-text", new_content="corrected-text")→ returns ID_B (different from ID_A)/v1/memories/ID_A→ still exists withis_active: trueExpected Behavior
Both modes should behave consistently. Either:
Option A (preferred):
memory_correct(query=...)should also delete the matched memory before creating the new one, matchingmemory_idmode.Option B: If query-mode intentional design is to preserve the original, the documentation should explicitly say so, and the response should include
"superseded_memory_ids": [...]so callers know which old memories to purge.Additional Suggestion: ID change transparency
memory_correctin either mode silently changes the memory ID. Any external reference (work-notes, lessons, skill docs, code comments) that hardcodes the old ID will break without any warning.Suggestion: the response of
memory_correctshould include:{ "memory_id": "<new_id>", "obsolete_memory_id": "<old_id>", "warning": "⚠️ Old memory_id <old_id> is no longer valid. Update all references." }Or alternatively, add a
keep_original_id: booleanparameter — if the backend cannot update in place, return an explicit error explaining why.Environment
memory_correct(memory_id=...)vsmemory_correct(query=...)