Question: compact emotional state as a cross-client prompt prelude?

[pioneerjeff]

Hi,

I found claude-mem while looking for memory projects that care about cross-client continuity, especially across coding-agent environments such as Claude Code, Codex, OpenClaw, and Hermes-style workflows.

I am maintaining a small open-source project called Emotion Engine:
https://github.com/pioneerjeff-labs/emotion-engine

It is not a memory retrieval system. It keeps a compact emotional-continuity state packet:

• PAD-style mood state
• agent-to-user trust
• decay toward a personality baseline
• optional boundary signals
• compact affective log entries

The reason claude-mem seems relevant is the cross-client problem. If a user moves between Claude Code, Codex, OpenClaw, and other agent hosts, the durable facts may be handled by memory, but there is also a smaller question:

What emotional / relational state should the next client inherit?

A possible shape would be:

claude-mem project/user memory
  -> compact Emotion Engine state file
  -> prompt prelude injected by whichever client is active

I am curious whether you think that belongs as a separate portable artifact, or whether it should just be another memory note managed by claude-mem.

This is not a request to add a dependency. I am trying to understand whether emotional continuity has any real value in cross-client coding-agent memory, or whether it is mostly useful for companions/NPCs and less relevant here.

[thedotmack]

I love this!!

[pioneerjeff]

Thanks, appreciate the kind words.

I spent some more time reading through claude-mem after posting this. My takeaway is that our projects are probably working on adjacent but different layers: claude-mem is focused on memory compression and cross-session context for coding agents, while Emotion Engine is focused on compact affective / relationship state.

So I do not want to force an integration idea where the boundary is not obvious.

That said, since claude-mem has already gone much deeper on the memory/context side than we have, I would welcome any feedback if you see something in Emotion Engine that feels off, unclear, or worth changing.

Separately, I am also starting to sketch a new Agent Harness project that will include long-term memory and portable runtime state across agent environments. In that context, claude-mem's approach to memory compression is definitely relevant, and I would be glad to compare notes if there is ever a natural overlap.

[ferhimedamine]

The cross-client continuity problem @pioneerjeff identified is the key architectural gap. Emotional state, memory, and identity all need to survive client switches — but they have different update cadences and different persistence requirements.

The layered approach that works: emotion/mood state (updates every turn, compact, inject as system prompt prelude), factual memory (updates on significant events, retrieved semantically), and procedural memory (updates rarely, always injected). Each layer has a different decay rate.

For the emotional-continuity packet specifically, storing it as a working memory with very short decay makes sense — mood state from 3 days ago is rarely relevant. But the TRUST dimension should persist longer (semantic memory, slow decay) because trust is earned over many interactions and shouldn't reset between clients.

The practical integration: an external memory service that all clients (Claude Code, Codex, OpenClaw, Hermes) connect to. Each client writes observations, the service handles the emotional state tracking as a special memory type with its own decay curve. Client switch = new session on the same agent namespace, so all prior emotional state and factual memory transfers seamlessly.

Memory type separation with per-type decay: https://github.com/Dakera-AI/dakera-py/blob/main/examples/basic_usage.py — working, episodic, semantic, procedural types each with different importance and decay characteristics.

[pioneerjeff]

Thank you for the concrete feedback. I think you pointed at a real design boundary that was still too blurry in Emotion Engine.

After checking the implementation, mood and trust were not literally using the same decay function, but the distinction was not explicit enough in the code and protocol. The emotional packet could still be read as if mood and trust were just two fields under one general decay model, which is not the right framing.

I pushed a small cleanup to the repo to make this clearer:

• PAD mood is now described as short-lived working state, with hour-level drift back toward the personality baseline.
• Trust is described as slower relationship-level continuity, with its own day-level decay curve and trust_anchor floor.
• The helper now has an explicit compute_mood_time_decay path, while keeping the old compute_time_decay name as a compatibility alias.
• I also added a test that captures the intended behavior: after several days, mood should mostly return to baseline, while trust should only move slightly.

This helped clarify the design quite a bit. The next thing I want to evaluate is your broader point about update cadence by state type: mood, trust, and boundary-related signals probably should not be treated as one uniformly decaying memory packet.

Appreciate the sharp read. This turned into a concrete protocol cleanup.