Tier 3 · Agent memory Agent memory · fetched 2026-07-02

AI Memory Patterns

Production patterns for building AI agent memory systems, distilled from operating a real multi-tenant system (154K+ observations, 3-node cluster) that competes with commercial offerings like Mem0 and Zep - architectural patterns and lessons, not a tutorial.

View source on GitHub

Key takeaways

01
Patterns come from production scale, not toy demos
02
Write/read/compress/update form the core memory pipeline
03
Multi-tenancy forces clean memory isolation design

Flows built on this research

Memory & Context

Add File-Based Persistent Memory

Give your agent durable memory with plain files - the radical-minimalism approach production practitioners keep converging on.

4 steps · 45-75 minutes

Memory & Context

Memory Write Policies

Decide what gets remembered: write gates, provenance, confidence, and validation - because memory quality is set at write time.

4 steps · 60-90 minutes

From the archive

Verbatim excerpts mined from our local archive of this repository — the prompts, schemas, and patterns worth stealing.

MCP & tools

Tool descriptions are LLM routing hints

Real failure: An LLM tried to call a memory API via fetch() in a code block, hallucinated the endpoint path, and returned fabricated results instead of admitting failure.

Solution: expose memory operations as typed MCP tools.

{
  name: "mem_hybrid_search",
  description:
    "Hybrid search combining vector embeddings + FTS. " +
    "Use this for most queries. Use mem_vector_search only for pure semantic similarity.",
  ...
}

28 tools organized by domain: Search (4), Observation (4), Curation (5: pin, set_importance, contradict, drift_check, set_event_date), Entity (2), Ingest (1), Workflow (3), Skill (5), Snapshot (4).

From a production system with 154K+ observations: write routing guidance directly into tool descriptions, because descriptions are the only signal the model uses to choose.

patterns/12-mcp-plugin.md

Memory

Three-signal retrieval fused with RRF

User Query -> Intent Detection -> Complexity Analysis
  -> Weight Map (factual: 0.7 FTS / relational: 0.7 Vector) + Retrieval Params (limit/rerank)

Signal 1: FTS (keywords, LIKE %query%)
Signal 2: Vector (768d, HNSW cosine)
Signal 3: Graph (concepts, 1-2 hop traverse)

  -> RRF Fusion (k=60)
     combined = Wv*vec + Wf*fts + 0.15*graph

Query intent decides the fusion weights before retrieval runs - factual queries lean on keywords, relational queries lean on vectors, and the graph contributes a constant 15%.

README.md