Persistent Memory for LLM Agents: A Production Architecture

For connected entities and multi-hop retrieval, the Neo4j agent memory guide adds a two-layer authority model and drift-and-exit test.

LangChain teams can apply this lifecycle with a runnable namespace, correction, and framework-exit test.

For a framework-specific implementation that separates runtime recall from canonical project truth, see the AutoGen agent memory guide.

Coding teams can apply this boundary with a dual-layer codebase memory MCP setup: regenerate structural facts from source while keeping decisions and runbooks in reviewable markdown.

For a concrete LangGraph implementation of scoped, filesystem-shaped memory, use the Deep Agents memory production setup.

For an implementation of read-only policy plus writable observations, use the secure Claude Managed Agents memory setup.

For a runnable implementation of the personal-versus-project boundary, see the Hermes Agent memory guide.

Persistent memory for LLM agents is not the transcript you forgot to delete. It is a governed system that selects durable information, stores it beyond one session, retrieves the right evidence, and lets newer facts supersede old ones. For project knowledge, the canonical memory should often be files you can read, edit, version, and self-host—not embeddings locked in an opaque store.

That distinction matters because persistence alone does not make memory reliable. A database can preserve a wrong preference forever. A large context window can faithfully replay stale instructions. The engineering target is maintainable memory: scoped, attributable, correctable, and cheap enough to retrieve on every relevant task. Meshnote implements that model as agent-agnostic Markdown wikis exposed through MCP.

A useful four-layer model

Separate memory by lifetime and authority instead of sending everything to one retrieval pipeline:

1. Working memory: the current prompt, recent messages, tool results, and temporary plan. It disappears with the run.
2. Episodic memory: dated events such as “deployment failed because disk was full.” Preserve the source and timestamp.
3. Semantic memory: consolidated facts and decisions such as “stage artifacts before stopping production.” This is the layer most likely to become a maintained page.
4. Procedural memory: executable or reviewable instructions: commands, checklists, schemas, and recovery steps.

The difficult part is promotion. Tool output does not become semantic truth merely because an agent observed it. Define what may move from a run into durable memory, who can approve high-impact claims, and what evidence accompanies the write. The memory guide for AI coding agents applies this separation to repository work and cross-tool handoffs.

What current approaches optimize

The leading systems solve different problems, so “best memory” is not a meaningful category without a workload.

Mem0’s current documentation describes an add/search loop that extracts durable facts and scopes them by user, agent, app, or run. Zep models evolving facts and relationships in a temporal graph. Letta persists the state surrounding an agent and distinguishes always-visible memory blocks from searchable archival memory. None is inherently wrong; each chooses a different unit of memory.

Benchmarks help, but they do not test ownership

LoCoMo, LongMemEval, and newer large-scale evaluations measure recall, temporal reasoning, knowledge updates, and related abilities. LongMemEval uses 500 questions; LoCoMo’s evaluation covers 1,540 questions. A March 2026 Memori paper reported 81.95% LoCoMo accuracy while adding an average of 1,294 tokens per query, versus 26,031 for its full-context condition. Those numbers are useful evidence that structured retrieval can reduce prompt load, not a universal vendor ranking.

Results are sensitive to the answer model, retrieval budget, evaluator, dataset version, and whether numbers come from a system’s own authors. More importantly, passive QA benchmarks usually do not answer operational questions: Can an engineer inspect the exact stored belief? Can a correction replace current guidance without destroying history? Can one tenant’s note leak into another tenant’s result? Can the team reconstruct memory after removing the vendor?

Use public benchmarks to shortlist architectures. Use your own failure cases to choose one. The vector versus readable memory comparison explains why a canonical store and a retrieval index should be evaluated separately.

The missing production contract: promote, correct, expire

Most explainers describe storage and retrieval. A production design also needs an explicit state transition for every durable claim. Use this minimal contract:

candidate -> verified -> current -> superseded -> archived

Required fields:
  scope: project | user | organization
  owner: team or person responsible for correction
  observed_at: when the evidence was produced
  source: URL, file, ticket, or command output
  review_after: date or triggering condition
  supersedes: stable ID of the older claim, if any

This is the original operational angle missing from the top-ranking pages: memory quality is treated as a lifecycle with an owner and expiry trigger, not only as a retrieval score. A user preference can be auto-promoted at low risk. A production deployment rule should require evidence and review. A temporary incident workaround should expire after the root fix ships.

Keep raw events append-only when they matter, but expose one clearly current statement. That prevents an agent from averaging contradictory facts. For example, retain both “API uses v1” and the later migration event, while the canonical page says “API uses v2” and links to the migration evidence.

A six-case acceptance test

Run this against the same interface your agent will use in production. Do not inspect the database manually until the behavioral test is complete.

1. Persist: save “Project Atlas uses port 7401,” end the session, then ask a new session for the port.
2. Correct: change it to 7402. Ask for the current port and why it changed. The answer must not hedge between values.
3. Scope: save port 8100 in Project Beacon. An Atlas query must never retrieve it.
4. Provenance: request the source and observation date. A bare generated sentence fails.
5. Expire: mark a workaround for review, cross the review condition, and verify it is withheld or flagged as stale.
6. Recover: export or copy the canonical data, rebuild any indexes, and reproduce the current answer without the original retrieval service.

Record correctness, retrieved tokens, p95 latency, and false cross-scope recalls. A high benchmark score cannot compensate for a tenant leak or an unrecoverable source of truth. For a broader multi-client setup, see shared memory across AI tools with MCP.

Where readable files fit

Markdown is strongest when knowledge is compact enough to curate and important enough to audit: architecture decisions, operating constraints, customer commitments, research conclusions, and runbooks. Files provide stable names, diffs, code review, backups, and direct human correction. BM25 or vector search can remain a disposable index over those files.

Do not force files to replace every database. High-volume event streams belong in append-oriented storage; rapidly changing entity relationships may benefit from Zep’s temporal graph; personalized conversational facts may fit Mem0; a deeply stateful agent may fit Letta. A robust system often combines these with a readable canonical layer.

Meshnote gives MCP-compatible agents tools to search, read, write, link, and recover Markdown wiki pages while humans can browse the same source. The hosted plan is $8/month, and teams can self-host from $10/seat/month with a five-seat minimum.

Implementation checklist

• Define memory scopes before the first write.
• Store only information with a plausible future use.
• Separate observations from current conclusions.
• Attach provenance and timestamps to high-impact claims.
• Make correction, deletion, and export first-class operations.
• Treat embeddings and graphs as rebuildable indexes where possible.
• Run the six-case test after changing models, prompts, chunking, or retrieval.

Persistent memory should make an agent more dependable, not merely more familiar. Start with the lifecycle and acceptance test, then choose the storage model that satisfies them. Start syncing — $8/mo.

For an AWS-managed implementation, the Bedrock AgentCore Memory guide shows how to pair extracted recall with an auditable Markdown knowledge plane.

Related Reading

• Memory for AI Coding Agents: A Cross-Tool Setup That Works
• Shared Memory Across AI Tools: A Practical MCP Architecture
• Vector Memory vs Readable Memory
• Mem0 vs Letta: Memory Layer or Stateful Agent Runtime?

For a current example of agent-owned Git memory versus shared cross-tool knowledge, see how Letta Code memory and MemFS work.

For a managed edge-runtime implementation and a concrete authority boundary, see the Cloudflare Agent Memory production guide.