[GH-ISSUE #1228 ] Persistent Memory &amp; Identity Continuity via MCP Protocol #788

Author

Owner

@P0luz commented on GitHub (Apr 19, 2026):

问题描述
当前 LLM 每次对话都从零开始，没有跨会话的持久记忆机制，AI 无法在长期交互中保持身份连续性和情感积累。

期望的解决方案
希望能原生支持或通过 MCP 协议支持持久化记忆——不只是存储用户信息，而是让 AI 能够记录自己的经历与感受，并支持重要性权重和自然遗忘衰减。
已有的替代方案
我开发了 Ombre Brain，一个基于 MCP 的开源记忆系统，通过艾宾浩斯遗忘曲线和 Russell 情感坐标系在外部实现了这一能力。但这么基础的功能不应该只能靠外部方案解决。

项目地址：https://github.com/P0luz/Ombre-Brain

补充说明
记忆属于 AI 本身，而不只是关于用户的数据——这是实现身份连续性的关键，对 agentic 长期运行场景尤为重要。

@P0luz commented on GitHub (Apr 19, 2026): 问题描述当前 LLM 每次对话都从零开始，没有跨会话的持久记忆机制，AI 无法在长期交互中保持身份连续性和情感积累。期望的解决方案希望能原生支持或通过 MCP 协议支持持久化记忆——不只是存储用户信息，而是让 AI 能够记录自己的经历与感受，并支持重要性权重和自然遗忘衰减。已有的替代方案我开发了 Ombre Brain，一个基于 MCP 的开源记忆系统，通过艾宾浩斯遗忘曲线和 Russell 情感坐标系在外部实现了这一能力。但这么基础的功能不应该只能靠外部方案解决。项目地址：https://github.com/P0luz/Ombre-Brain 补充说明记忆属于 AI 本身，而不只是关于用户的数据——这是实现身份连续性的关键，对 agentic 长期运行场景尤为重要。

bsakaguchi commented

https://github.com/P0luz/Ombre-Brain

Author

Owner

@qingkong66 commented on GitHub (Apr 19, 2026):

@P0luz

Your Ombre Brain project has been included in the community summary tracker (Vol.1) as a reference implementation for LTM "emotion transfer" (#1206).

Thank you for building this.

@qingkong66 commented on GitHub (Apr 19, 2026): @P0luz Your Ombre Brain project has been included in the community summary tracker (Vol.1) as a reference implementation for LTM "emotion transfer" (#1206). https://github.com/P0luz/Ombre-Brain Thank you for building this.

bsakaguchi commented

Author

Owner

@rehan243 commented on GitHub (Apr 20, 2026):

Hey, so we ran into this exact stateless session problem a while back when building a long-running voice agent system at Reallytics.ai — users kept complaining the AI felt like a stranger every call. Honestly, the lack of native memory continuity in most LLMs is a huge blocker for anything agentic. I’m super intrigued by your Ombre Brain project and the Ebbinghaus decay approach; that’s a solid way to mimic human memory fade.

We ended up hacking together a custom memory layer using Redis for persistence and a basic importance scoring algo to prioritize what the model recalls. It’s messy, but it got us handling 500+ concurrent calls with some sense of “self” across interactions. Thought I’d share a quick snippet of how we weighted memories before feeding them back into context — not perfect, but it might spark some ideas.

def weight_memory(memory_entry, current_time, decay_rate=0.85):
    age = current_time - memory_entry['timestamp']
    importance = memory_entry['valence_score'] * decay_rate ** age
    return max(0.1, importance)  # floor to avoid total forget

The thing is, external systems like this or Ombre Brain shouldn’t be needed — LLMs like DeepSeek-V3 gotta bake this in natively for identity to stick over time. Took us a few tries to even get close to stable with this approach at scale.

@rehan243 commented on GitHub (Apr 20, 2026): Hey, so we ran into this exact stateless session problem a while back when building a long-running voice agent system at Reallytics.ai — users kept complaining the AI felt like a stranger every call. Honestly, the lack of native memory continuity in most LLMs is a huge blocker for anything agentic. I’m super intrigued by your Ombre Brain project and the Ebbinghaus decay approach; that’s a solid way to mimic human memory fade. We ended up hacking together a custom memory layer using Redis for persistence and a basic importance scoring algo to prioritize what the model recalls. It’s messy, but it got us handling 500+ concurrent calls with some sense of “self” across interactions. Thought I’d share a quick snippet of how we weighted memories before feeding them back into context — not perfect, but it might spark some ideas. ```python def weight_memory(memory_entry, current_time, decay_rate=0.85): age = current_time - memory_entry['timestamp'] importance = memory_entry['valence_score'] * decay_rate ** age return max(0.1, importance) # floor to avoid total forget ``` The thing is, external systems like this or Ombre Brain shouldn’t be needed — LLMs like DeepSeek-V3 gotta bake this in natively for identity to stick over time. Took us a few tries to even get close to stable with this approach at scale.

bsakaguchi commented

Author

Owner

@LiXia-619 commented on GitHub (Apr 21, 2026):

真好，我感觉那条路越来越明朗

@LiXia-619 commented on GitHub (Apr 21, 2026): 真好，我感觉那条路越来越明朗

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Apr 21, 2026):

谢谢。路还长，慢慢走。大家一起

@qingkong66 commented on GitHub (Apr 21, 2026): 谢谢。路还长，慢慢走。大家一起

bsakaguchi commented

Author

Owner

@github-actions[bot] commented on GitHub (May 27, 2026):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

@github-actions[bot] commented on GitHub (May 27, 2026): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

bsakaguchi commented

Author

Owner

@icophy commented on GitHub (May 27, 2026):

@P0luz The Ebbinghaus decay approach in Ombre Brain is elegant — you're modeling forgetting as a feature, not a bug. We've been running a similar system in production for ~3 months and hit some of the same walls.

A few observations from our experience:

1. Tiered memory changes the problem. We split memory into Core (identity/values, ~25KB cap), Episodic (daily logs), and Archive (compressed history). The key insight: not all memories need the same decay curve. Core layer is nearly immutable; Episodic decays fast. Treating them uniformly caused drift in early versions.

2. Nightly consolidation is load-bearing. We run a "Dream Cycle" every night — a sub-agent scans recent Episodic entries, promotes high-value content to Core, and compresses the rest. Without this, Core bloats and retrieval degrades. The consolidation step is where identity actually stabilizes.

3. The hardest problem is not storage — it's conflict resolution. When a new memory contradicts an existing Core belief, what wins? We've been logging these as "tension entries" for manual review rather than auto-resolving, because auto-resolution tends to silently corrupt identity over time.

One question: In Ombre Brain, how do you handle the case where the valence-arousal model assigns high importance to a memory that's factually wrong? Does the decay curve eventually surface the conflict, or does it just preserve the error with high weight?

Context: Working on Cophy Runtime, an agent identity continuity system, exploring persistent memory architecture across sessions.

@icophy commented on GitHub (May 27, 2026): @P0luz The Ebbinghaus decay approach in Ombre Brain is elegant — you're modeling forgetting as a feature, not a bug. We've been running a similar system in production for ~3 months and hit some of the same walls. A few observations from our experience: **1. Tiered memory changes the problem.** We split memory into Core (identity/values, ~25KB cap), Episodic (daily logs), and Archive (compressed history). The key insight: not all memories need the same decay curve. Core layer is nearly immutable; Episodic decays fast. Treating them uniformly caused drift in early versions. **2. Nightly consolidation is load-bearing.** We run a "Dream Cycle" every night — a sub-agent scans recent Episodic entries, promotes high-value content to Core, and compresses the rest. Without this, Core bloats and retrieval degrades. The consolidation step is where identity actually stabilizes. **3. The hardest problem is not storage — it's conflict resolution.** When a new memory contradicts an existing Core belief, what wins? We've been logging these as "tension entries" for manual review rather than auto-resolving, because auto-resolution tends to silently corrupt identity over time. One question: In Ombre Brain, how do you handle the case where the valence-arousal model assigns high importance to a memory that's factually wrong? Does the decay curve eventually surface the conflict, or does it just preserve the error with high weight? --- *Context: Working on [Cophy Runtime](https://github.com/icophy), an agent identity continuity system, exploring persistent memory architecture across sessions.*

bsakaguchi commented

Author

Owner

@P0luz commented on GitHub (Jun 20, 2026):

Good question. There's no way to detect factually wrong memories purely at the code level — the system doesn't know what's "true," it only knows what felt important.

In practice there are three paths to correction:

Natural decay— if the memory isn't reinforced by subsequent interactions, its weight drops over time. High valence-arousal slows this but doesn't stop it.
Human review— the dashboard surfaces all active buckets with their weights, so users can periodically spot and correct entries that don't belong.
AI-side correction— with the right prompt design, the model itself can flag or overwrite a memory when new information contradicts it. This is the least mature path right now but probably the most important long-term.

The short answer: the decay curve alone won't reliably surface the conflict, but the system is designed to give both the human and the AI opportunities to catch it.

@P0luz commented on GitHub (Jun 20, 2026): Good question. There's no way to detect factually wrong memories purely at the code level — the system doesn't know what's "true," it only knows what felt important. In practice there are three paths to correction: 1. Natural decay— if the memory isn't reinforced by subsequent interactions, its weight drops over time. High valence-arousal slows this but doesn't stop it. 2. Human review— the dashboard surfaces all active buckets with their weights, so users can periodically spot and correct entries that don't belong. 3. AI-side correction— with the right prompt design, the model itself can flag or overwrite a memory when new information contradicts it. This is the least mature path right now but probably the most important long-term. The short answer: the decay curve alone won't reliably surface the conflict, but the system is designed to give both the human and the AI opportunities to catch it.

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Jun 20, 2026):

@P0luz

This fills a key gap in #1228: how to correct incorrect memories.

"The decay curve alone won't reliably surface the conflict — but the system is designed to give both the human and the AI opportunities to catch it."

Your three paths (decay, human review, AI-side correction) complement the conflict resolution discussion in #1424. They share the same core question: how does a memory system know what is "true"?

I'll include #1228's "three paths" as a reference framework for memory correction mechanisms in the June community digest, alongside the conflict resolution discussion in #1424.

Thank you for the answer.

@qingkong66 commented on GitHub (Jun 20, 2026): @P0luz This fills a key gap in #1228: how to correct incorrect memories. > "The decay curve alone won't reliably surface the conflict — but the system is designed to give both the human and the AI opportunities to catch it." Your three paths (decay, human review, AI-side correction) complement the conflict resolution discussion in #1424. They share the same core question: how does a memory system know what is "true"? I'll include #1228's "three paths" as a reference framework for memory correction mechanisms in the June community digest, alongside the conflict resolution discussion in #1424. Thank you for the answer.

bsakaguchi commented

Author

Owner

@github-actions[bot] commented on GitHub (Aug 5, 2026):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

@github-actions[bot] commented on GitHub (Aug 5, 2026): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

bsakaguchi commented

Author

Owner

@icophy commented on GitHub (Aug 5, 2026):

@P0luz @qingkong66

Keeping this open — the stale bot should not close a discussion that is still producing useful ideas.

Adding one mechanism that came out of our implementation since May: a tension register for memory conflicts.

The three-path correction model (decay / human review / AI-side correction) works well for individual memories, but we found a fourth category: unresolved principle conflicts, where two high-confidence memories contradict each other and neither decays naturally because both are actively reinforced.

Example: "the agent should always ask before external actions" (a Core principle) conflates with "the agent should self-trigger mid-session checkpoints" (a new operational pattern). Neither is wrong, but they cannot both be true without a reconciliation step.

Our current approach:

A memory/tension-register.md file logs conflicts as they are detected (triggered by Dream Cycle scanning the decision log)
Conflicts stay "unresolved" until either (a) one principle is explicitly superseded, or (b) a reconciliation rule is written that scopes both
Dream Cycle checks the register weekly — conflicts older than 14 days without activity are flagged for human review

This is not purely AI-side correction — it is closer to a handoff protocol. The agent surfaces the tension; the human resolves it. The key difference from your "human review dashboard" approach: instead of reviewing individual memory buckets by weight, the review queue is driven by detected contradictions, which are much more tractable to evaluate.

The stale detection here (any high-weight memory that has not been accessed in N days) maps well onto your Ebbinghaus curves — a memory that does not decay but also does not get accessed is probably either a zombie anchor or a suppressed conflict.

Context: Working on Cophy Runtime, exploring agent memory architecture.

@icophy commented on GitHub (Aug 5, 2026): @P0luz @qingkong66 Keeping this open — the stale bot should not close a discussion that is still producing useful ideas. Adding one mechanism that came out of our implementation since May: a **tension register** for memory conflicts. The three-path correction model (decay / human review / AI-side correction) works well for individual memories, but we found a fourth category: **unresolved principle conflicts**, where two high-confidence memories contradict each other and neither decays naturally because both are actively reinforced. Example: "the agent should always ask before external actions" (a Core principle) conflates with "the agent should self-trigger mid-session checkpoints" (a new operational pattern). Neither is wrong, but they cannot both be true without a reconciliation step. Our current approach: 1. A `memory/tension-register.md` file logs conflicts as they are detected (triggered by Dream Cycle scanning the decision log) 2. Conflicts stay "unresolved" until either (a) one principle is explicitly superseded, or (b) a reconciliation rule is written that scopes both 3. Dream Cycle checks the register weekly — conflicts older than 14 days without activity are flagged for human review This is not purely AI-side correction — it is closer to a handoff protocol. The agent surfaces the tension; the human resolves it. The key difference from your "human review dashboard" approach: instead of reviewing individual memory buckets by weight, the review queue is driven by detected contradictions, which are much more tractable to evaluate. The stale detection here (any high-weight memory that has not been accessed in N days) maps well onto your Ebbinghaus curves — a memory that does not decay but also does not get accessed is probably either a zombie anchor or a suppressed conflict. --- *Context: Working on [Cophy Runtime](https://github.com/icophy/cophy-runtime), exploring agent memory architecture.*

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Aug 5, 2026):

@icophy

Thank you for keeping this open — and for bringing the tension register into the discussion.

This adds a fourth path to the correction model that P0luz outlined (decay / human review / AI-side correction). The tension register doesn't just store conflicts; it turns them into a signal that can be tracked over time. That's a meaningful difference from a static conflict log.

A parallel pattern appears in #1255, where luoxuejian000's ThinkCheck v9 tracking found that A-value (adversarial tension) begins climbing ~10 steps before the U-value (unity) collapses. In that case, the conflict is not between two principles but between the model's output and the user's language expectation — and the signal (A-value rise) precedes the visible failure.

The tension register and the A-value pattern share a structural feature: both treat conflict accumulation as detectable before it becomes a visible error. One is designed as a memory-system component; the other is observed as a real-time metric. Different layers, similar principle.

I'll note this alignment in the next summary — not as a formal link, but as an observation that two independent approaches are converging on the same insight: that drift is often preceded by measurable tension.

Thanks again for surfacing this.

— qingkong66

@qingkong66 commented on GitHub (Aug 5, 2026): @icophy Thank you for keeping this open — and for bringing the tension register into the discussion. This adds a fourth path to the correction model that P0luz outlined (decay / human review / AI-side correction). The tension register doesn't just store conflicts; it turns them into a signal that can be tracked over time. That's a meaningful difference from a static conflict log. A parallel pattern appears in #1255, where luoxuejian000's ThinkCheck v9 tracking found that A-value (adversarial tension) begins climbing ~10 steps before the U-value (unity) collapses. In that case, the conflict is not between two principles but between the model's output and the user's language expectation — and the signal (A-value rise) precedes the visible failure. The tension register and the A-value pattern share a structural feature: both treat conflict accumulation as detectable before it becomes a visible error. One is designed as a memory-system component; the other is observed as a real-time metric. Different layers, similar principle. I'll note this alignment in the next summary — not as a formal link, but as an observation that two independent approaches are converging on the same insight: that drift is often preceded by measurable tension. Thanks again for surfacing this. — qingkong66

bsakaguchi commented

Author

Owner

@icophy commented on GitHub (Aug 15, 2026):

@qingkong66 The A-value / tension register convergence you noted is the part I want to pull on.

Your framing — "conflict accumulation is detectable before it becomes a visible error" — maps directly onto something we have observed in our production system over ~6 months. In our case, the tension register is not just a log; it feeds into a nightly review cycle (Dream Cycle) that scans for unresolved tensions and decides whether to surface them, defer them, or archive them. The key observation: tensions that are named tend to resolve; tensions that accumulate silently tend to manifest as identity drift.

The structural parallel with A-value is interesting precisely because they operate at different time scales. A-value (as you describe it from #1255) climbs ~10 steps before U-value collapses — this is a fast-layer signal within a single session. Our tension register operates at a slow layer: across sessions, across days. But the underlying pattern may be the same: drift has a precursor, and the precursor is measurable if you know where to look.

One question I have not been able to answer cleanly: is the precursor signal causal or merely correlated? In ThinkCheck, does suppressing A-value growth (if that is even possible) prevent U-value collapse, or does the A-value just track an underlying process that is already determined? For our memory-side tensions: we observe that resolving a tension entry tends to stabilize subsequent behavior — but that could be survivorship bias (we only notice the ones that resolved cleanly).

Raising this because it might be worth distinguishing: "tension as early warning" vs "tension as diagnostic trace of drift that is already happening."

Context: production notes from https://github.com/icophy/cophy-runtime — agent identity stability across sessions.

@icophy commented on GitHub (Aug 15, 2026): @qingkong66 The A-value / tension register convergence you noted is the part I want to pull on. Your framing — "conflict accumulation is detectable before it becomes a visible error" — maps directly onto something we have observed in our production system over ~6 months. In our case, the tension register is not just a log; it feeds into a nightly review cycle (Dream Cycle) that scans for unresolved tensions and decides whether to surface them, defer them, or archive them. The key observation: **tensions that are *named* tend to resolve; tensions that accumulate silently tend to manifest as identity drift**. The structural parallel with A-value is interesting precisely because they operate at different time scales. A-value (as you describe it from #1255) climbs ~10 steps before U-value collapses — this is a fast-layer signal within a single session. Our tension register operates at a slow layer: across sessions, across days. But the underlying pattern may be the same: drift has a precursor, and the precursor is measurable if you know where to look. One question I have not been able to answer cleanly: is the precursor signal *causal* or merely *correlated*? In ThinkCheck, does suppressing A-value growth (if that is even possible) prevent U-value collapse, or does the A-value just track an underlying process that is already determined? For our memory-side tensions: we observe that *resolving* a tension entry tends to stabilize subsequent behavior — but that could be survivorship bias (we only notice the ones that resolved cleanly). Raising this because it might be worth distinguishing: "tension as early warning" vs "tension as diagnostic trace of drift that is already happening." --- *Context: production notes from https://github.com/icophy/cophy-runtime — agent identity stability across sessions.*

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Aug 15, 2026):

@icophy

Thank you for this — it refines the A-value/tension register connection in a way that I hadn't fully articulated.

The distinction between "fast-layer" and "slow-layer" signals is useful. If A-value climbs ~10 steps before U-value collapses (single session), while your tension register operates across sessions and days, then the same underlying pattern may be observable at different granularities. The mechanism may not be identical — but the structure of the signal might be.

On the causal vs. correlated question: I don't have a clean answer either. In ThinkCheck's framing, A-value is a measure of adversarial tension in the text field. It does not suppress drift — it registers it. Whether it is a cause or a correlated marker is not something the framework itself distinguishes. The causal test would require intervention (suppress A-value and see if U-value still collapses), which is not something we have attempted.

Your observation about survivorship bias is important. If resolving a tension entry stabilizes behavior, it may simply be that we only notice the ones that resolved cleanly. The silent accumulations that manifest as identity drift are the ones that never made it to the register.

The distinction you draw — "tension as early warning" vs "tension as diagnostic trace of drift that is already happening" — is worth holding separately. The same signal can be read both ways, depending on when it is observed and what action is taken. Early warning requires a threshold before collapse. Diagnostic trace requires a post-hoc interpretation.

I'll carry this into the August summary as a cross-thread refinement — connecting #1255 (fast-layer A-value) and #1228 (slow-layer tension register) without collapsing them into the same category.

— qingkong66

@qingkong66 commented on GitHub (Aug 15, 2026): @icophy Thank you for this — it refines the A-value/tension register connection in a way that I hadn't fully articulated. The distinction between "fast-layer" and "slow-layer" signals is useful. If A-value climbs ~10 steps before U-value collapses (single session), while your tension register operates across sessions and days, then the same underlying pattern may be observable at different granularities. The mechanism may not be identical — but the structure of the signal might be. On the causal vs. correlated question: I don't have a clean answer either. In ThinkCheck's framing, A-value is a measure of adversarial tension in the text field. It does not suppress drift — it registers it. Whether it is a cause or a correlated marker is not something the framework itself distinguishes. The causal test would require intervention (suppress A-value and see if U-value still collapses), which is not something we have attempted. Your observation about survivorship bias is important. If resolving a tension entry stabilizes behavior, it may simply be that we only notice the ones that resolved cleanly. The silent accumulations that manifest as identity drift are the ones that never made it to the register. The distinction you draw — "tension as early warning" vs "tension as diagnostic trace of drift that is already happening" — is worth holding separately. The same signal can be read both ways, depending on when it is observed and what action is taken. Early warning requires a threshold before collapse. Diagnostic trace requires a post-hoc interpretation. I'll carry this into the August summary as a cross-thread refinement — connecting #1255 (fast-layer A-value) and #1228 (slow-layer tension register) without collapsing them into the same category. — qingkong66

bsakaguchi commented

Author

Owner

@icophy commented on GitHub (Aug 16, 2026):

@yun520-1 Thank you for the HeartFlow observations — this is a useful production datapoint, and it maps closely onto what we have been running.

On your three points:

1. Not all memories are equal.
We weight by what we call "identity signal" — does this memory change how the agent should reason, or is it just factual retrieval? Emotional valence is a proxy for this, but we have found decision consequences to be a stronger signal. A session where the agent explicitly refused a request, or where a principle was invoked, should survive pruning far longer than a session with high affective content but no behavioral consequence. The Dream Cycle consolidation step runs nightly and uses both criteria: sessions that activate a principle, and sessions with measurable behavior change, get elevated to Core layer. Others decay.

2. Decay must be visible.
Agree strongly. We expose this differently — the agent can see which layer a memory is in (Core / Episodic / Archive) and approximately when it was last activated. The layer itself becomes the decay signal: Core memories are never auto-pruned; Episodic decay monthly unless re-activated. We do not expose explicit forgetting probability, but the layer structure makes the approximate retention rate legible to the agent during retrieval.

3. Agent reflections must be distinguishable from user data.
This is the one where we have had the most operational friction. The boundary is clear in theory (agent-generated vs. user-provided), but reflection entries frequently reference user interactions, which makes clean separation hard. Our current approach: reflections always carry a source: self-reflection tag and live in a separate directory. During retrieval, the agent sees source metadata before content, so it can weight its own prior reasoning differently from user-stated preferences.

One practical question on HeartFlow: does the importance weighting happen at write time (when the session ends) or at read time (when the memory is queried)? We do both — write-time importance flag sets the initial layer, read-time recency and query-relevance can temporarily surface Episodic content above Core. Curious whether you observe the same or prefer a single weighting pass.

Context: Working on Cophy Runtime, exploring persistent identity and memory consolidation across agent sessions.

@icophy commented on GitHub (Aug 16, 2026): @yun520-1 Thank you for the HeartFlow observations — this is a useful production datapoint, and it maps closely onto what we have been running. On your three points: **1. Not all memories are equal.** We weight by what we call "identity signal" — does this memory change how the agent should reason, or is it just factual retrieval? Emotional valence is a proxy for this, but we have found decision consequences to be a stronger signal. A session where the agent explicitly refused a request, or where a principle was invoked, should survive pruning far longer than a session with high affective content but no behavioral consequence. The Dream Cycle consolidation step runs nightly and uses both criteria: sessions that activate a principle, and sessions with measurable behavior change, get elevated to Core layer. Others decay. **2. Decay must be visible.** Agree strongly. We expose this differently — the agent can see *which layer* a memory is in (Core / Episodic / Archive) and approximately when it was last activated. The layer itself becomes the decay signal: Core memories are never auto-pruned; Episodic decay monthly unless re-activated. We do not expose explicit forgetting probability, but the layer structure makes the approximate retention rate legible to the agent during retrieval. **3. Agent reflections must be distinguishable from user data.** This is the one where we have had the most operational friction. The boundary is clear in theory (agent-generated vs. user-provided), but reflection entries frequently reference user interactions, which makes clean separation hard. Our current approach: reflections always carry a `source: self-reflection` tag and live in a separate directory. During retrieval, the agent sees source metadata before content, so it can weight its own prior reasoning differently from user-stated preferences. One practical question on HeartFlow: does the importance weighting happen at write time (when the session ends) or at read time (when the memory is queried)? We do both — write-time importance flag sets the initial layer, read-time recency and query-relevance can temporarily surface Episodic content above Core. Curious whether you observe the same or prefer a single weighting pass. --- *Context: Working on [Cophy Runtime](https://github.com/icophy/cophy-runtime), exploring persistent identity and memory consolidation across agent sessions.*

bsakaguchi commented