Guide memory staleness with timestamps
Add prompt-only guidance that treats memory timestamps as soft recency signals instead of hard TTLs. Encourage newer/current facts to win for mutable conflicts while preserving old durable preferences or project facts unless current evidence shows they are stale, false, superseded, duplicated, or unwanted.
Alessandro committed
Jun 2, 2026 at 11:13 UTC
120d55d2713a64b403f4765f796ce962bade2d48
4 files changed
+7
plugins/_memory/prompts/agent.system.memories.md
+2
@@ -1,6 +1,8 @@
1
# Memories on the topic
2
- following are memories about current topic
3
- do not overly rely on them they might not be relevant
4
+- when timestamps are present, use them as a soft staleness signal: newer/current memories usually win for mutable facts
5
+- old memories can still be valid durable preferences or project facts; do not ignore or forget them only because they are old
6
- if memories conflict, prefer the newest/current fact and ignore superseded older fragments
7
- use `memory_forget` for stale, false, superseded, duplicated, or unwanted memories; it also cleans exact matches and derived fragment/solution records
8
plugins/_memory/prompts/agent.system.tool.memory.md
+2
@@ -9,8 +9,10 @@ notes:
9
- `threshold` is similarity from `0` to `1`
10
- `filter` is a metadata expression (e.g. `area=='main'`)
11
- confirm destructive changes when accuracy matters
12
+- memories usually include timestamp metadata; use it as a soft recency signal, not a hard TTL
13
- when the user updates a durable fact/preference, load related memories first, forget/delete superseded versions, then save one complete current version
14
- do not append a second memory for the same mutable subject when the new statement replaces the old one
15
+- do not forget a memory only because it is old; forget it when current evidence shows it is stale, false, superseded, duplicated, or unwanted
16
- `memory_forget` also cleans exact matches and derived fragment/solution records related to removed memories
17
- use `memory_save` for stable current facts, not short-lived test markers, greetings, or one-off conversation events
18
plugins/_memory/prompts/memory.consolidation.sys.md
+2
@@ -23,9 +23,11 @@ Default bias: for mutable user preferences, project state, configuration choices
23
24
### 1. Temporal Intelligence
25
- **Newer information** generally supersedes older information
26
+- **Timestamps are soft recency signals, not automatic TTLs**; age alone does not make a durable memory invalid
27
- **Preserve historical context** only when the user explicitly needs history or an audit trail
28
- **Do not keep old preferences as equally important memories** when the new memory clearly gives the current state
29
- **Consider recency** - more recent memories are usually more relevant for mutable facts
30
+- **Keep stable old facts** when they remain useful and are not contradicted by newer/current information
31
32
### 2. Content Relationships
33
- **Complementary information** should be merged into comprehensive memories
plugins/_memory/prompts/memory.memories_filter.sys.md
+1
@@ -13,6 +13,7 @@
13
- Focus on USER MESSAGE if provided, use HISTORY for context
14
- Keep in mind that these memories should be helpful for continuing the conversation and solving problems by AI
15
- Consider if each memory holds real information value for the context or not
16
+- If memories include timestamps, treat recency as a soft signal: newer/current memories are usually better for mutable facts, while old durable facts may still be useful
17
- If multiple memories conflict about the same mutable user/project fact, include only the newest/current one when it is identifiable
18
- Exclude superseded, historical, duplicate, or low-detail fragments when a more complete current memory is available
19