Semantic Memory

Semantic Memory gives Monday Morning local-first semantic recall over your project’s accumulated knowledge. Agents and Claude Code can store durable memories, recall them by meaning rather than exact words, and search across what’s been remembered — all without sending a single byte off your machine.

It’s the same compounding-knowledge idea behind the rest of .mm/: the work you’ve already done becomes a retrievable artifact that primes future sessions. Semantic Memory just makes that recall semantic — a query surfaces the right note even when the wording doesn’t match.

Local-first, by construction

Privacy isn’t a setting here; it’s the architecture. Embeddings are computed offline inside the MCP server using a bundled local model. The server makes no LLM calls of its own — it only embeds the content you give it and persists it locally. There is no remote vector service, no API key, and no network round-trip.

• Embeddings run on-device — the bundled model turns your memory text into vectors locally.
• The vector store is local — records live under .mm/index/amem/ inside your project, alongside the rest of your file-based .mm/ data.
• Data never leaves the machine — nothing is uploaded; recall works fully offline.

This keeps Semantic Memory consistent with Monday Morning’s core principles: local-first, file-based, and AI-ready context.

What you can do

Two built-in MCP tools drive the memory loop, and one more lets you search the rest of your .mm/ entities.

Tool	What it does
mm_remember	Stores an enriched memory note — embeds the content with the local model and persists it under .mm/index/amem/. You supply the enrichment (summary, tags, keywords, links) in-session; the server only embeds and persists what you give it.
mm_recall	Embeds a query with the same local model and returns the top-k nearest stored notes, each with a cosine similarity score and metadata (summary, tags, keywords, links, source). Optionally filter by source, tags, or model.
mm_search	Full-text search across all .mm/ entity types (specs, features, issues, notes, ideas), returning matching entities with snippets.

A typical flow: recall first to find related notes (and their ids, to link against and avoid duplicates), then remember the new knowledge with those links. mm_remember is idempotent on a stable id, so re-remembering the same id updates the record in place rather than duplicating it — you can evolve a memory over time.

What’s worth remembering: durable, non-obvious knowledge — a decision and its reasoning, a completed spec, a gotcha — not transient or trivial state.

Privacy guarantees

• No network calls for embedding, storing, or recalling memory.
• No third-party LLM sees your memory content during storage — the server only embeds it.
• The store is plain local files in your project, under your version control and your control.
• Fail-soft: if the model or store is unavailable, the memory tools return an error result without breaking other Monday Morning tools.

How it fits the Claude Code workflow

Semantic Memory is enabled per-project via .mm/config.json:

{
  "semantic_memory": {
    "enabled": true
  }
}

Once enabled, an agent or Claude Code session can store and recall memories and run semantic search over the project’s .mm/ knowledge as part of normal work — capturing a decision when it’s made, then recalling it by meaning in a later session. Because the store is just files under .mm/index/amem/, it travels with your repository and stays available offline.

Related

• The .mm/ Data Model — where .mm/index/ and the rest of your project knowledge live
• Spec Retrieval (Prior Work) — the complementary, structured-field retrieval built into the spec lifecycle
• mm_remember, mm_recall, mm_search — the built-in MCP tools that drive memory