Summary
Add memory fusion support: detect pairs of highly similar memories about the same entity that could be consolidated into one richer record, and provide an API for the host LLM to execute the merge.
This is a follow-up to the forgetting service (Step 6). It uses the same similarity detection infrastructure but serves a different purpose: consolidation instead of deletion.
Why this matters
When an agent accumulates incremental facts about the same entity over many sessions:
- Session 1: "User prefers Python"
- Session 5: "User prefers Python 3.12 specifically"
- Session 12: "User prefers Python 3.12 with type hints and pytest"
- Session 20: "User moved from pytest to unittest"
Without fusion: 4 records, retriever returns all 4, LLM must reconcile (including stale pytest reference). With fusion: 1 record — "User prefers Python 3.12 with type hints and unittest" — cleaner context, less noise, correct answer.
This is specifically valuable for long-running user profile stores — an MCP server that an agent uses across months of work, accumulating overlapping facts about the same person, project, or environment.
Design constraint
Same as contradiction detection: the framework detects candidates and provides the mechanism. The host LLM provides the judgment (what the fused content should say). No LLM calls inside the framework.
Proposed API
POST /api/forgetting/fusion-candidates
→ Returns pairs of highly similar kept memories that could be consolidated
Response: { "candidates": [{"record_a": {...}, "record_b": {...}, "similarity": 0.92}] }
POST /api/forgetting/fuse
{
"source_ids": ["id1", "id2"],
"fused_content": "User prefers Python 3.12 with type hints and unittest",
"fused_importance": 0.8
}
→ Creates new record, supersedes both originals (importance -> 0.0, superseded_by metadata)
When to build
After Step 6 (forgetting service) lands. The similarity scanning infrastructure from 6B and the supersession mechanism are prerequisites. This adds a new use of the same infrastructure.
Prior art
- FadeMem (arXiv:2601.18642): implements "intelligent memory fusion" using LLM to merge related memories. Achieved 82.1% critical fact retention at 55% storage.
- Kore: merges memories with cosine similarity > 0.88 automatically (no LLM judgment — riskier but simpler).
- A-Mem (arXiv:2502.12110, NeurIPS 2025): new memories trigger updates to existing memories via linking, but doesn't merge content.
Summary
Add memory fusion support: detect pairs of highly similar memories about the same entity that could be consolidated into one richer record, and provide an API for the host LLM to execute the merge.
This is a follow-up to the forgetting service (Step 6). It uses the same similarity detection infrastructure but serves a different purpose: consolidation instead of deletion.
Why this matters
When an agent accumulates incremental facts about the same entity over many sessions:
Without fusion: 4 records, retriever returns all 4, LLM must reconcile (including stale pytest reference). With fusion: 1 record — "User prefers Python 3.12 with type hints and unittest" — cleaner context, less noise, correct answer.
This is specifically valuable for long-running user profile stores — an MCP server that an agent uses across months of work, accumulating overlapping facts about the same person, project, or environment.
Design constraint
Same as contradiction detection: the framework detects candidates and provides the mechanism. The host LLM provides the judgment (what the fused content should say). No LLM calls inside the framework.
Proposed API
When to build
After Step 6 (forgetting service) lands. The similarity scanning infrastructure from 6B and the supersession mechanism are prerequisites. This adds a new use of the same infrastructure.
Prior art