v2.21.0: Log Entries Join Semantic Memory, LoCoMo Benchmark, MARM Console

This is the first tagged release since v2.18.0, so it rolls up three versions: the concept graph (v2.19.0), the project rename and doc overhaul (v2.20.0), and v2.21.0 itself.

v2.21.0: Log entries join semantic memory, LoCoMo benchmark, MARM Console

Log entries are now semantically recallable

marm_log_entry dual-writes. Every entry lands in log_entries as before, and is also embedded into the memories table through the serialized write queue, so marm_smart_recall's hybrid semantic + FTS5 engine can actually find logged content. Before this, nothing agent-facing wrote to the semantic store; it was only reachable through the dashboard's manual Add Memory form.

• The response gains a memory_id field next to entry_id. If the semantic write fails, the log write still succeeds (memory_id: null).
• Dual-written memories carry metadata.source = "log_entry" and metadata.log_entry_id for provenance, and flow into compaction like any other memory.
• marm_delete (type="log") cascades: deleting a log entry or a whole log session also removes its dual-written memories, and the response reports a memories_deleted count. Deleted logs stop surfacing in recall.
• One tradeoff to know: each marm_log_entry call now waits on the write queue for an embedding instead of doing a single cheap INSERT. Normal agent logging won't notice; heavy concurrent writers share one queue.
• marm_smart_recall's log_results now include the log entry id, so a recalled row can be tied back to the exact entry that produced it. HTTP and STDIO behave identically, and pre-2.21 log rows are untouched.

LoCoMo retrieval benchmark

New in scripts/benchmarking/accuracy/locomo/: a deterministic, LLM-free retrieval benchmark against the LoCoMo long-conversation dataset. It ingests each conversation through marm_log_entry, then checks whether marm_smart_recall returns the gold evidence turns for every annotated question. Scoring is pure evidence-ID matching with per-category and per-lane (semantic vs log) hit rates. No judge model anywhere, so every number is reproducible.

MARM Console

The repo now includes marm-console/, a local web app for browsing and debugging your memory layout (not fully active yet, full launch coming in an upcoming release):

• Concept builds start asynchronously and persist durable run records (queued/running/terminal state, extraction counts, duration, stable error codes) in the isolated concept database, with stale-run detection.
• The Knowledge workspace supports entity provenance (source memories and linked code), bounded directional and predicate-filtered neighborhood queries, and read-only duplicate candidates from entity embeddings.
• The Projects workspace drives the code graph: repository indexing through bounded background jobs with live status, plus architecture overview, code search, call tracing, change-impact analysis, and typed-confirmation project deletion.
• These run over Console-only internal routes on the MCP server. They are not new MCP tools, so the agent-facing tool count stays at 14.

v2.20.0: Project rename and doc overhaul

• The GitHub repository was renamed from MARM-Systems to marm-memory. The PyPI package (marm-mcp-server), Docker image (lyellr88/marm-mcp-server), and MCP Registry listing are unchanged. No installed artifact names moved and no tool schema changed, so nothing breaks for existing consumers.
• MCP-HANDBOOK.md was merged into the README, which also gained an architecture comparison table against Mem0, Letta, Zep/Graphiti, and agentmemory. Stale 12-tool references left over from the v2.19.0 launch were corrected to 14 everywhere.
• The marm-init skill no longer generates or handles API keys in conversation for setups that need one; it hands you copy-paste commands to run in your own terminal instead. Also fixed: the Docker HTTP command block (missing SERVER_HOST and a wrong volume mount), and the dashboard address, which pointed at a port that doesn't exist.

v2.19.0: Concept graph

• Two new tools, marm_concept_build and marm_concept_recall, move the tool count from 12 to 14 (HTTP and STDIO parity). They extract entities (concept, decision, pattern, error, tool, plus spaCy NER types) and typed relationships out of stored memory content, and let an agent query them by name or traverse "related to X". When marm-graph has the project indexed, extracted entities cross-link to code symbols.
• Everything runs in-process against its own SQLite file with its own connection pool. Builds are explicit and on-demand, never a live hook into the memory write path.
• Relationships carry real predicates (fixes, implements, depends_on, uses, causes, replaces, extends) derived from spaCy's dependency parse. No LLM call involved.
• marm_concept_recall gains depth (1-5) and direction for bounded, cycle-safe multi-hop traversal; defaults reproduce the original one-hop behavior exactly.
• marm_concept_build flags near-duplicate entities via cosine similarity as possible_duplicates without ever auto-merging them.
• spaCy stays an optional dependency: pip install marm-mcp-server[concepts] enables real extraction, and without it both tools stay registered and return cleanly.

Upgrading

pip install --upgrade marm-mcp-server
# or
docker pull lyellr88/marm-mcp-server:2.21.0

Full details in CHANGELOG.md.