MARM next phase: hardening the lightweight memory stack without adding bloat

[Lyellr88]

Why this discussion exists

MARM has improved quickly over the last stretch. Recall quality is better, token use is more controlled, and the memory stack is much stronger than it was a month ago.

That progress also creates hidden debt if we are not careful.

The goal of the next phase is not to keep stacking features. The goal is to harden the lightweight memory stack so it stays fast, understandable, and maintainable as the internals grow.

Where complexity has accumulated

The current memory stack now includes:

• hybrid recall
• temporal weighting
• layered retrieval
• consolidation
• compaction
• write queue
• swarm behavior
• fallback summarization

None of these are random additions. Each one came from real usage, testing, or review findings. The risk is not that any one piece is wrong. The risk is that the interactions between them become harder to reason about over time.

What this phase should focus on

For the near term, the priority is:

1. stabilization
2. observability
3. UX clarity
4. fewer new moving parts

That means:

• better visibility into which recall path answered a query
• clearer documentation around the memory maintenance pipeline
• less brittle test coverage around recall and memory behavior
• tighter defaults and safer config handling
• resisting speculative features unless they clearly improve recall quality, reduce token cost, improve reliability, or improve adoption

Questions for contributors

• Which part of the current memory stack feels hardest to reason about?
• Where do you think observability is most missing today?
• Are there recall or compaction behaviors that feel too implicit from the outside?
• Which hardening tasks would you most want to help with?

I opened a small set of scoped issues from this discussion for contributors who want to help with the next hardening pass.