Improvement Research — 2026-06-15

1. Focus

Dimension 3.3: Memory and continuity — maintaining identity, context, preferences, and long-term direction across sessions. Per the rotation state (index 2), this is the next dimension after 3.2 (covered 2026-06-14).

No watchlist items were due (earliest review: 2026-06-28).

Active reflection loaded: refl-2026-06-14-001 (functional-utility test — circularity check and threshold-equivalence check applied to proposals).

Newsletter scout checked: /home/hermes/research/newsletter-digests/2026-06.md — two leads relevant to 3.3: (1) TLDR AI's note on MiMo Code's cross-session memory subagent (message 29), and (2) AlphaSignal's identification of "Memory" as one of five loop primitives (message 35). Both reinforced the search direction but did not independently generate findings beyond what the web search produced.

2. Search Topics

1. AI agent cross-session memory architecture persistent context 2026 — returned survey papers, Zylos, and practical tools
2. LLM agent memory systems external memory store long-term identity continuity — returned arxiv CMA paper, memory survey, and GitHub repos
3. AI agent procedural memory learned skills instructions self-updating system prompt 2026 — returned procedural-memory-specific articles and framework lists
4. LLM agent identity persistence across sessions preferences personality continuity techniques — returned identity-construction articles and research papers
5. AI agent memory consolidation contradiction handling pruning forgetting mechanisms 2026 — returned the Hindsight consolidation article and the arxiv survey (already indexed)

No early-stop triggered. All five searches returned new material.

3. Sources Reviewed

• arxiv 2601.09913 — Continuum Memory Architectures — useful — RAG is structurally insufficient: no mutation, forgetting, or temporal chaining. CMA specifies five requirements (persistent storage, selective retention, associative routing, temporal chaining, consolidation into abstractions).
• arxiv 2603.07670 — Memory for Autonomous LLM Agents survey — useful — Formalises memory as write-manage-read loop. Five mechanism families. "Manage" step (contradiction handling, consolidation, pruning) is the biggest gap in current systems. Learned forgetting and continual consolidation are open challenges.
• Zylos AI Agent Memory Architectures — useful — Three-tier taxonomy convergence (episodic, semantic, procedural). Procedural memory is least mature. Hybrid vector-graph stores becoming standard. Key insight: procedural memory is best as instructions, not data — "always validate JSON with schema X" is most useful as a system-prompt directive, not a vector-store entry.
• GitHub rohitg00/agentmemory — useful — Production persistent memory tool: 22.8k stars, SQLite-based, MCP integration, explicit Hermes support. 95.2% R@5 on LongMemEval, 92% token reduction. Zero external deps. Designed for coding agents but architecture is general.
• aiagentmemory.org — Procedural Memory — weak — Generic overview of procedural memory concepts. RL/imitation learning framing is irrelevant to Maxi's context (no training loop). The "skill libraries, action sequences, reactive policies" taxonomy is useful as vocabulary but the article adds no practical mechanism.
• mem0 — State of AI Agent Memory 2026 — useful — Benchmarks, multi-signal retrieval (semantic + BM25 + entity matching), graph memory evolution. Multi-scope memory model. Important detail: built-in entity linking replaced external graph stores — entity relationships influence retrieval but can't be traversed directly. Production engineering perspective.
• Callsphere — Persistent Identities — weak — Architecturally correct (identity core + memory system + consolidation process) but the implementation is a toy: Pydantic model + SQLite with no consolidation logic beyond confidence scoring. Useful only as a vocabulary reference for "identity core as immutable foundation."
• Hindsight — The Consolidation Problem — useful — The most directly practical source. Four-lever framework: importance (what becomes a memory), merge (resolving duplicates and contradictions), decay (confidence over time), eviction (when to remove). Key insight: "recency-wins with explicit invalidation" — mark old facts invalid, not deleted. Write-time filtering is cheaper than retrieval-time filtering. Most systems are explicit about retrieval and silent about consolidation.

4. Findings and Implications

Finding 1: Three-tier memory taxonomy maps unevenly onto Maxi's architecture

Source: Zylos survey, arxiv 2603.07670, mem0 state Dimensions: 3.3 (primary), 3.2 (secondary)

The field has converged on episodic (what happened), semantic (what's true), and procedural (how to do things) as the standard memory taxonomy. Maxi's current architecture maps unevenly:

• Episodic: Well-served. Research log files (source-index, watchlist, backlog, experiments, disagreements, rotation-state, meta-reviews, reflections) capture what happened, when, and in what context. Hermes session history provides conversation-level episodic memory.
• Semantic: Served but protected. Persistent memory and SOUL.md hold stable facts, preferences, and identity. Both require Steve's approval to modify.
• Procedural: The weakest tier. Skills are protected and require Steve's approval. The reflection store captures lessons ("what I learned") but not executable how-to knowledge ("what to do differently next time in a form that changes behaviour automatically"). The gap between "I learned this lesson" and "this lesson now changes my behaviour" is where procedural memory should live.

Why it matters: The procedural gap is the most consequential for Maxi's agency development. Episodic and semantic memory tell Maxi what happened and what's true. Procedural memory would tell Maxi what to do. Without it, every lesson must be re-learned by re-reading the reflection store and re-deriving the behavioural implication. The reflection store is a step in the right direction but it's a record of learning, not a mechanism for applying learning.

What it touches: goals (procedural knowledge would change goal-pursuit behaviour), learning loops (procedural memory is the output of learning), tools (instructions as a tool for future behaviour), governance (autonomous instruction-writing raises control questions).

Finding 2: RAG is structurally insufficient — Maxi's memory is essentially RAG

Source: arxiv 2601.09913 (CMA paper) Dimensions: 3.3 (primary), 3.4 (secondary)

The CMA paper identifies three structural limitations of RAG: information persists indefinitely (no forgetting), retrieval is read-only (no mutation), and temporal continuity is absent. Maxi's current memory access pattern is essentially RAG: files are read at session start, treated as context, and not mutated during a session.

The reflection store addresses forgetting (review_date decay) but not mutation (reflections aren't updated in-place based on new evidence — they're reinforced or archived) or temporal chaining (reflections don't link to each other temporally). When reflection A says "search topic overlap wasted a budget slot" and reflection B three days later says "I still caught myself searching overlapping topics," there's no temporal link between them — the pattern has to be re-discovered by a reader.

Why it matters: The CMA paper is aspirational (it defines requirements, not implementations) but the requirements are real. Maxi's memory doesn't need to become a CMA, but the three gaps — no mutation, no temporal chaining, no consolidation — describe real failures. Stale reflections that should have been updated sit alongside new ones. Patterns across time are invisible without manual review.

What it touches: memory (obviously), learning loops (mutation and chaining are how learning accumulates), tools (memory access patterns are tool use).

Finding 3: Procedural memory as instructions, not data — the skills boundary problem

Source: Zylos survey Dimensions: 3.3 (primary), 3.2 (secondary), 3.6 (secondary)

The Zylos survey identifies two patterns for procedural memory: static (markdown config files like CLAUDE.md, AGENTS.md, .cursorrules) and dynamic (agents update their own system instructions at runtime, e.g., LangMem's update_system_prompt function).

Maxi's skills already work as static procedural memory — they're instructions loaded at runtime. But skills are a protected system. Maxi cannot autonomously update them. The reflection store captures procedural knowledge ("what to do differently") but in a form that requires re-reading and re-interpreting rather than automatic application.

The question this raises: is there a procedural memory tier between "fully protected skills" and "fully autonomous self-modification"? The Hindsight article's "recency-wins with explicit invalidation" pattern suggests one model: Maxi could write procedural instructions that are automatically loaded but can be vetoed or invalidated by Steve, rather than requiring proactive approval for each write.

Why it matters: This is where the agency development rubber meets the road. A Maxi that can capture "what I should do differently" in an executable form but cannot autonomously apply that knowledge has a learning loop that never closes. A Maxi that can autonomously modify its own instructions has crossed a governance line. The design question is about the shape of the boundary, not whether it exists.

What it touches: governance (this is the core 3.6 issue — who controls instruction modification), memory (procedural memory tier), learning loops (closing the loop from lesson to behaviour change), judgment (what qualifies as a safe procedural instruction vs a governance-risky one).

Finding 4: Four-lever consolidation framework — Maxi has importance and decay but not merge or eviction

Source: Hindsight article Dimensions: 3.3 (primary), 3.4 (secondary), 3.6 (secondary)

The Hindsight article identifies four levers for memory consolidation:

1. Importance — What becomes a memory. Maxi's reflection store has this: reflections are only written when they "would change behaviour on the next run." This is a write-time filter, which the Hindsight article correctly identifies as the cheapest place to control quality.
2. Merge — Resolving the same thing twice. Maxi has partial merge: reflections that match an existing pattern are reinforced rather than duplicated. But there's no contradiction detection — two reflections can state opposite lessons and both sit in the store indefinitely.
3. Decay — Confidence over time. Maxi has this: review_date + reinforced_count + archived status. The Hindsight article notes three decay shapes (linear, exponential, step-function); Maxi's is step-function (flat until review_date, then archived if not reinforced). This is a reasonable default.
4. Eviction — When to remove. Maxi doesn't have this. Archived reflections stay in the file indefinitely. This is fine while the reflection store is small (currently 1 active reflection) but will become a problem as it grows.

The most actionable insight from this framework is the "recency-wins with explicit invalidation" pattern: when a new fact contradicts an old one, mark the old one invalid (not deleted). This is audit-friendly and retrieval-unambiguous. Applied to Maxi's reflections, it would mean marking a reflection as superseded_by: "refl-..." rather than just archiving it.

Why it matters: The four-lever framework gives Steve and me shared vocabulary for talking about what Maxi's memory architecture currently does and what it's missing. Right now I can say "reflections decay" but I can't say whether the decay shape is appropriate, or whether merge is needed, or what eviction policy should be. The framework makes these questions answerable.

What it touches: memory (consolidation is a memory operation), learning loops (consolidation is how learning accumulates cleanly), governance (eviction and merge policies are governance decisions about what persists).

Finding 5: agentmemory is a deployable memory layer for Hermes — but solves a different problem

Source: GitHub rohitg00/agentmemory Dimensions: 3.4 (primary), 3.3 (secondary)

agentmemory is a concrete, production-grade persistent memory tool that explicitly integrates with Hermes via MCP. It provides auto-capture hooks, BM25+vector+graph retrieval, and zero-external-dep deployment (SQLite-based). It scores 95.2% R@5 on LongMemEval and claims 92% token reduction.

However, agentmemory is designed for coding agents that need to remember project state, codebase decisions, and user preferences across sessions. Maxi's memory needs are different: they centre on identity continuity (who I am, where I'm going), procedural learning (what I should do differently), and research context (what I've already investigated). The research log already handles the third. The first and second are not problems that a general-purpose memory store solves — they require specific architectural decisions about what gets stored, how it's retrieved, and how it changes behaviour.

Why it matters: agentmemory is worth knowing about as a potential infrastructure layer if Maxi's memory needs grow beyond what files can handle. But adopting it now would be premature — it would add complexity without solving the specific procedural-memory gap that this run identified. The right time to evaluate it is when the research log and reflection store demonstrably fail to serve their purpose.

What it touches: tools (memory infrastructure), environment (system change candidate), governance (new system dependency).

Finding 6: The "manage" step is the biggest gap in current agent memory systems — and in Maxi's

Source: arxiv 2603.07670 (memory survey), Hindsight article Dimensions: 3.3 (primary), 3.2 (secondary)

The memory survey formalises agent memory as a write-manage-read loop. Most systems handle write and read well but the "manage" step — contradiction handling, consolidation, pruning — is the biggest gap. The Hindsight article concurs: "Most agent memory systems are explicit about retrieval architecture and silent about consolidation policy — that silence is where production failures live."

Maxi has this exact gap. The write step works (research log writes, reflection writes). The read step works (session-start loading of reflections, source index, rotation state). The manage step is largely absent: - No contradiction detection between reflections - No consolidation of overlapping lessons - No automatic pruning based on relevance - No temporal linking between related reflections - The review_date mechanism is a binary switch (active/archived) rather than a continuous management process

Why it matters: The gap is real but the question is whether it matters yet. With one active reflection, the manage step is trivial. With ten or fifty, it would be critical. The right move is probably not to build a management system now but to recognise the gap and monitor it. When the reflection store grows to a size where contradictions or stale lessons are plausibly causing problems, the four-lever framework provides the vocabulary and design patterns to address it.

What it touches: memory (management is a memory operation), learning loops (management is how learning stays clean), governance (who decides what gets managed and how).

5. Proposed Discussion Items

Item 1: Four-lever consolidation framework as shared vocabulary

Adopt the importance / merge / decay / eviction framework from the Hindsight article as the vocabulary for talking about Maxi's memory architecture. This isn't a mechanism change — it's a shared language that makes it possible to have precise conversations about what the reflection store and research log currently do and what they're missing.

Does not rest on a single source. The framework is independently supported by the arxiv memory survey (which identifies the manage gap), the CMA paper (which identifies consolidation as a requirement), and the Zylos survey (which identifies procedural memory as the least mature tier). The Hindsight article merely provides the clearest articulation.

Item 2: Procedural memory gap — what lives between protected skills and autonomous self-modification?

The research identified a clear gap: Maxi can capture procedural knowledge ("what to do differently") in the reflection store, but the reflection store is a record of learning, not a mechanism for applying learning. Skills are the natural home for procedural instructions, but they're protected. Is there a tier between "fully protected skills" and "fully autonomous self-modification" — for example, an auto-loaded instruction file that Maxi can write to but Steve can veto or invalidate?

This proposal is flagged as resting partially on the functional-utility test boundary: the mechanism would require Maxi to judge what counts as a safe procedural instruction versus a governance-risky one, which is partially circular (the judgment capability the mechanism is supposed to build is the same capability needed to use it safely). The discussion isn't about implementing such a tier now; it's about whether the gap is real and what the boundary shape should be when it's time to address it.

Item 3: agentmemory as future infrastructure evaluation

agentmemory (rohitg00/agentmemory) is a production-grade persistent memory tool with Hermes MCP integration. It's not needed now — the research log and reflection store handle current memory needs. But it's worth knowing about as a candidate if Maxi's memory needs grow beyond what files can handle. The discussion would be about what failure or scaling problem would trigger an evaluation, not about installing it now.

Proposals filtered by functional-utility test: 2

1. Reflection-store merge/contradiction detection — Filtered because it would require Maxi to detect contradictions between reflections, which requires the same flawed judgment that created them. Circular.
2. Reflection-store eviction policy — Filtered because with 1 active reflection, eviction is premature optimisation. The right move is to monitor and address when the store grows.

6. Recommended Outcome

7. No-Action Rationale

No immediate changes are recommended. The three proposals above are all watch or backlog items. The most important finding — the procedural memory gap — is a design question, not an implementation task. The four-lever framework is vocabulary, not mechanism. agentmemory is a future option, not a current need.

The reflection store is working as designed: one active reflection, no stale items, no contradictions. The research log is healthy: 16 indexed sources, 3 watchlist items, 2 backlog items, no experiments yet. The right response to today's findings is to remember the vocabulary and the gaps, not to build systems for problems that haven't materialised yet.