Reviewable Memory Consolidation for Local AI Agents

AI memory is usually sold as recall.

That is only the first problem.

A serious agent does not merely need to remember more. It needs a way to keep its memory from decaying into duplicates, stale facts, contradictions, abandoned tasks, and vague summaries that feel true because nobody wants to reopen the evidence.

That is the memory problem I care about in sqlite-memory-mcp.

The project started as a pragmatic fix: a SQLite-backed MCP memory stack for Claude Code and adjacent local agents. WAL mode made concurrent sessions tolerable. FTS5 and optional semantic search made recall useful. Tasks, notes, sessions, bridge sync, context packs, and knowledge-graph tools made the memory operational instead of decorative.

But long-running memory creates a second-order failure mode.

If memory can grow, memory must also be maintained.

Repo: https://github.com/RMANOV/sqlite-memory-mcp

Why Anthropic Dreams matters

Anthropic's Dreams feature is important because it validates the category.

The core idea is simple and powerful: memory stores should not only accumulate. They should periodically be processed, consolidated, and improved from prior sessions and stored knowledge.

That is the right direction.

But local and operator-controlled agent work needs a different shape.

In a high-value workflow, I do not want a memory system to silently rewrite the record. I want it to produce candidate changes, show the evidence, let me review them, and only then apply the accepted mutations.

The distinction matters.

A hosted memory-maintenance job can be the right tool for a hosted agent platform. A local engineering workflow needs something more inspectable: what changed, why it changed, which source supported it, and what the previous state was.

That is the sqlite-memory-mcp angle: not a Dreams clone, and not a claim that local software can magically replace a managed platform. The point is narrower and more useful.

Claude Dreams shows the category. sqlite-memory-mcp makes memory consolidation local, reviewable, and auditable before mutation.

Retrieval is not enough

A vector database can answer: what looks relevant right now?

A search index can answer: where did this phrase or identifier appear?

Those are retrieval questions.

Memory consolidation asks a different question: should this memory still be trusted in its current shape?

That requires a different workflow:

current memory + recent sessions/events
        -> candidate consolidated memory
        -> evidence-backed diff/review
        -> explicit decision
        -> apply accepted changes
        -> audit trail and snapshot

This is why reviewability is not a cosmetic feature. It is the product boundary.

When an agent suggests that two notes are duplicates, I want to know which rows it compared. When it says a task is stale, I want to know the dates. When it proposes archiving a placeholder, I want the before state and the after state. When it touches operational memory, I want a ledger.

If memory is infrastructure, mutation cannot be casual.

What exists in sqlite-memory-mcp now

The current public repo contains the pieces needed for a conservative local reflection pipeline.

There is a deterministic read-only audit path: reflect_audit. It can inspect the memory database and produce candidate maintenance findings without asking an LLM to invent a new store.

There is also a Phase 1 reflection lifecycle exposed through MCP tools around:

• reflect_start
• reflect_status
• reflect_history
• reflect_cancel
• reflect_archive
• reflect_review
• reflect_decide
• reflect_apply
• reflect_discard

The schema has explicit reflection tables:

• reflection_runs
• reflection_inputs
• reflection_candidates
• reflection_apply_snapshots

That matters because candidates are materialized as reviewable records instead of disappearing inside a prose summary.

The apply path is intentionally conservative. Accepted candidates can be applied through the same task mutation ledger used by the rest of the system, and before/after snapshots are recorded.

The current implementation is not a claim of universal autonomous memory rewrite. It is a governed maintenance path for the memory surfaces where safe defaults exist.

That is the right bias.

For local agent memory, boring correctness beats theatrical autonomy.

Why local matters

A local-first memory stack has different constraints from a cloud memory API.

It has to work in a real folder, on a real machine, with real sessions, logs, tasks, notes, and project state. It has to survive restarts. It has to be inspectable with ordinary tools. It has to keep data close when privacy, offline work, or operator control matters.

SQLite is not an accident here.

A single database file gives the system a practical substrate:

• WAL mode for concurrent local sessions.
• FTS5/BM25 for lexical search.
• Optional sqlite-vec semantic search when dependencies exist.
• Structured task and note history.
• Session continuity.
• Bridge sync across machines.
• Field-level event history for mutation provenance.

The result is not the easiest hosted memory API.

It is a local control surface for agents that do real work and need their memory to remain defensible.

What this is not

This is not a pitch that every memory change should be automatic.

It is not a promise that an LLM can perfectly decide what is true.

It is not a whole-store replacement mechanism pretending that a regenerated memory blob is enough.

It is not a private premium runtime announcement.

The useful claim is smaller:

sqlite-memory-mcp can make memory maintenance explicit. It can identify candidate cleanup, keep the candidate separate from live memory, expose review decisions, apply accepted changes through a ledger, and preserve before/after evidence.

That is enough to be valuable.

Note: the GitHub release line reaches v3.11.4. The package metadata in pyproject.toml may lag that release line, so this article describes the repo/release line, not a PyPI package claim.

The product thesis

Agent memory will not be won by storing more text.

It will be won by memory discipline:

• what gets stored;
• what gets resurfaced;
• what gets challenged;
• what gets merged;
• what gets archived;
• what gets applied only after review.

For toy agents, silent memory rewrite may look convenient.

For serious work, it is a liability.

The more useful future is reviewable consolidation: agents propose, humans or policy gates decide, and the system records the evidence trail.

That is where sqlite-memory-mcp is going.

Not just memory.

Memory that can be maintained without losing accountability.

Repo: https://github.com/RMANOV/sqlite-memory-mcp

Comments

[Gilder Miller]

Hi Ruslan, thanks for your article.
Yes, memory decay into duplicates and contradictions is such a real problem. Most people just ignore it until the agent starts hallucinating.
The review-before-mutation approach is smart. But I'm wondering what happens when two reflection runs propose conflicting changes? Is there a merge strategy, or do you just queue them and let the operator decide?