Memory Digest Now Scales to Hundreds of Memories

Memory Digest already gives you a complete project briefing in one command. Search, organize, synthesize — all handled automatically. It works well for the typical case: 20-40 memories about a project, assembled into a coherent status report in seconds.

But we kept thinking about what happens as your memory store grows. Power users accumulate hundreds of memories across dozens of conversations. A month of active development can easily produce 150+ memories. We wanted digest to handle that scale with the same level of detail it delivers for smaller sets.

So we built recursive digest synthesis — a strategy that partitions large memory sets into focused groups, synthesizes each group at full fidelity, and merges the results into one comprehensive briefing. The more memories you have, the richer your digest gets.

Scaling Synthesis with Research-Backed Techniques

Recent research on Recursive Language Models (MIT CSAIL, Dec 2025) demonstrates that multiple focused LLM calls consistently outperform a single large call for long-input tasks — even when using the same model. The key insight: instead of compressing inputs to fit, decompose them and let the model give full attention to each piece.

We applied this directly to the digest pipeline. When a digest draws from more than 30 memories, the synthesis stage now partitions them into conversation-coherent groups of 20-30, synthesizes each group with full memory content, and merges the sub-digests into a final briefing.

175 memories across 92 conversations
|
|-- Group 1: Conversations 1-15  (28 memories) -> sub-digest
|-- Group 2: Conversations 16-32 (30 memories) -> sub-digest
|-- Group 3: Conversations 33-48 (27 memories) -> sub-digest
|-- Group 4: Conversations 49-65 (31 memories) -> sub-digest
|-- Group 5: Conversations 66-80 (29 memories) -> sub-digest
|-- Group 6: Conversations 81-92 (30 memories) -> sub-digest
|
+-- Merge: 6 sub-digests -> final digest

Every memory is seen at full content length. Each LLM call processes a manageable group — the sweet spot where synthesis produces its best results. The merge step combines sub-digests (already concise summaries of ~500-2000 tokens each) into a coherent final briefing.

Seven calls instead of one. Full fidelity at any scale.

What This Looks Like in Practice

We tested recursive synthesis on a real workload: 175 memories across 92 conversations spanning a week of platform development.

The digest covered every workstream with specifics: GDPR compliance (4 PRs across 4 phases), billing integration, marketing site SEO (with product analytics decision rationale), the memory digest feature itself (5 PRs), entity extraction phases, customer portal enhancements, cloud deployment, and worktree isolation. PR numbers, dates, decisions, blockers — all preserved throughout.

The level of detail scales with the size of your memory store. More memories means a richer, more comprehensive digest — exactly as it should be.

How Partitioning Works

The system groups memories by conversation, because conversations are naturally coherent units of work. A debugging session stays together. A feature implementation stays together. This produces sub-digests that read well on their own and merge cleanly.

When a single conversation has more than 30 memories, it gets split chronologically. When conversations are small, they get bin-packed together. The goal is always: each partition has roughly 20-30 memories, and related work stays in the same group.

# Recursive synthesis activates automatically — no flags needed
mx memories digest --query "project status" --max-sources 200

Below 30 memories, the efficient single-call synthesis runs as before. Above that, recursive synthesis kicks in automatically.

Under the Hood

The Pipeline

The three-stage digest pipeline (Gather -> Organize -> Synthesize) continues to work the same way. Recursive synthesis enhances the third stage:

1. Gather — High-limit semantic search with graph expansion. Unchanged.
2. Organize — Conversation grouping, topic traversal, entity linking. Unchanged.
3. Synthesize — Now uses recursive partition-synthesize-merge for larger memory sets.

Budget Controls

We cap resource usage with a configurable call budget:

• Max LLM calls: 8 per digest (configurable)
• Max concurrency: 3 parallel leaf calls (configurable)
• Leaf threshold: 30 memories per group (configurable)

When the budget is reached, remaining groups gracefully fall back to concatenation. You get every section represented, with the most detailed groups receiving full LLM synthesis.

In practice, most digests need 5-8 calls. The 175-memory digest used 7 — 6 leaf syntheses plus 1 merge.

Metadata

The digest response now includes recursion stats when recursive synthesis is used:

{
  "metadata": {
    "sourcesUsed": 175,
    "conversationsSpanned": 92,
    "recursion": {
      "enabled": true,
      "leafGroups": 6,
      "llmCallsUsed": 7,
      "maxDepthReached": 1
    }
  }
}

When the memory count is below the threshold, the recursion field is absent. No API contract changes.

Latency

A single-call digest takes 2-5 seconds. A recursive digest takes 4-10 seconds, depending on the number of leaf groups. Leaf calls run in parallel (up to 3 at a time), so the wall-clock time scales efficiently — closer to ceil(groups/3) * call_time + merge_time than linear.

The LRU cache still applies. A repeated query returns near-instantly regardless of whether it was generated recursively.

Cost

| Scenario | Memories | LLM Calls | Estimated Cost | |----------|----------|-----------|---------------| | Small (single-call) | 20 | 1 | ~$0.001 | | Medium (recursive) | 80 | 4-5 | ~$0.005 | | Large (recursive) | 175 | 7 | ~$0.010 |

At $0.01 for a comprehensive 175-memory digest, recursive synthesis delivers substantially richer output for a modest increase in cost.

Design Decisions

Why Conversation-Based Partitioning?

We evaluated three partitioning strategies: by conversation, by topic cluster, and by time window. Conversation-based partitioning produces the most coherent groups. A debugging session has a beginning, middle, and end. A feature implementation follows a logical arc. Keeping these together means each sub-digest captures a complete narrative, and the merge step assembles them naturally.

Topic clustering works well when you have few conversations covering many topics. Time windows serve as a reliable fallback. For this release, we shipped conversation-based partitioning — it covers the vast majority of real-world usage patterns.

Why Not Just Use a Bigger Context Window?

Larger context windows are valuable, but the "lost in the middle" attention pattern persists even in models with 100K+ token windows. The challenge isn't fitting the input — it's ensuring the model gives equal attention across the full sequence. Multiple focused calls address this directly, and the research confirms they consistently outperform single large calls for dense information tasks.

Full Content, Always

We considered various compression strategies — extracting key sentences, using extracted facts as compact representations. But every compression strategy involves judgment calls about what to keep. Recursive synthesis sidesteps this entirely: the model sees every memory at full length. If a user wrote it, it's in the synthesis input. No editorial filtering.

Try It

If you're already using Memory Digest, recursive synthesis is live now. It activates automatically for digests with 30+ memories — no configuration needed.

Update your CLI and try it with a broad query:

mx update
mx memories digest --query "everything I worked on" --recent 7d --max-sources 200

Check the metadata for the recursion field to see it in action. The more memories you have, the more comprehensive your digest becomes.

---

Recursive Digest Synthesis is available now in MemNexus Core API v1.33.3 and CLI v1.7.34.