Repository navigation
Consider promoting basic-memory-skills lifecycle/defrag conventions (stale-fact marking) into core #1588
Description
Activity
@Flynn-Kawolsky I’d be interested in the concrete workflow you offered. I’m studying correction and review of agent memory while building GFT Map.
If this is still occurring, could you share one non-sensitive example of the older observation, its replacement, and what a later search returned? Does status filtering or archiving already resolve it, or what do you still need to check or change yourself before continuing?
@Flynn-Kawolsky One concrete baseline for this proposal: the released v0.23.2 search tool already accepts a frontmatter
statusfilter.A small check on two disposable note copies:
- Give the old copy
status: supersededand its replacementstatus: activein their existing YAML frontmatter, then let Basic Memory sync them. - Search for a phrase present in both, using your actual project name:
{ "query": "shared phrase", "project": "your-project", "search_type": "text", "entity_types": ["entity"], "status": "active" }Compare with the same call without
status. This is exact, whole-note filtering: unlabelled notes are excluded too. It still requires someone to maintain the labels, and it doesn't retire an old observation inside a still-active note. Ordinary searches don't apply this filter automatically.I've checked the released source, not run this against your notes. If you try it, the useful distinction would be whether whole-note exclusion covers your case, or whether the remaining work is deciding which individual observations are still valid. No real note content needs to be shared.
- Give the old copy
Hi team,
Thanks again for the great work on Basic Memory — following up on a separate point from my earlier note (#1372/#1587) about progress visibility.
I noticed the core note format (frontmatter + free-text Observations with optional [category] tags) has no built-in way to distinguish a durable fact from a point-in-time status, or to mark a note/fact as superseded or expired. In practice, older notes can end up contradicting newer ones, and nothing in the core schema or retrieval flags that.
I see the companion repo basic-memory-skills already addresses this with Memory Defrag (removing stale info, merging conflicts), Memory Reflect (consolidating recent notes into long-term memory), and Memory Lifecycle (folder-based status/archiving, "archive never delete"). That's a solid approach, but it currently lives as an optional workflow layer rather than something the core tool is aware of.
Would it be worth considering a lightweight, optional signal in core, for example a status: or as_of: frontmatter field, or a freshness/recency weighting at search time? That would mean, first, users without the extra skills installed still get some protection against stale or contradicting notes surfacing in search, and second, the lifecycle/defrag conventions in basic-memory-skills would have an underlying primitive to build on, rather than relying purely on file organization.
Happy to share more detail on the specific workflow that surfaced this if useful. Thanks for considering it.