Agent Memory Atlas

Methodology

Comparative Report Method

The evidence and synthesis structure used for the cross-repository comparison.

Use this format for the cross-repository overview after the individual repo reports are complete. The overview should synthesize implementation evidence across repos, not merely summarize each repo.

The comparison is four pages, and each section below says which one it lives in:

content/overview.md   → /overview/    In Short, Reading This Report, §3–§10, History
content/families.md   → /families/    §1, the families and the scope boundary
content/compare.md    → /compare/     §2, the matrix and capability tables, generated
content/appendix.md   → /appendix/    §11, report links, pins, licences, known limitations

The argument is the page a builder reads in order, so it carries only the argument; the section numbers stay as they are so that §8 and §10 keep meaning what AGENTS.md says they mean.

Title

# Agent Memory Systems Comparative Report

1. High-Level Taxonomy (content/families.md)

Group the repositories by design style. Candidate categories:

  • Local personal memory.
  • Hosted memory API.
  • Agent framework memory.
  • Library primitives.
  • RAG/context engine.
  • Verification-first memory.
  • Peer/user/session modeling system.
  • Coding-agent memory.
  • Multi-agent/shared-memory infrastructure.

For each category, explain:

  • What problem it optimizes for.
  • What tradeoffs it accepts.
  • Which repos fit, and why.

2. Comparative Matrix (content/compare.md, generated)

Use a table with these columns:

  • Repo.
  • Memory unit.
  • Storage backend.
  • Retrieval strategy.
  • Write strategy.
  • Update/delete model.
  • Scoping model.
  • Agent integration.
  • Background processing.
  • Trust/provenance model.
  • Notable strengths.
  • Main risks.

Keep the matrix dense and factual. Use short phrases, not paragraphs.

3. End-to-End Memory Lifecycle Comparison

Compare how each repo handles:

  • Capture.
  • Extraction.
  • Consolidation.
  • Retrieval.
  • Context injection.
  • Correction.
  • Forgetting.
  • Cross-session persistence.
  • Cross-agent or cross-user sharing.

This should expose where systems differ architecturally, not just where their APIs differ.

4. Implementation Hotspots by Repo

Provide a cross-repo index of the most important implementation files/functions grouped by concern:

  • Memory schema.
  • Add/write path.
  • Search/retrieve path.
  • Context assembly path.
  • Background workers.
  • MCP/server interfaces.
  • SDK/client surfaces.
  • Evals/tests.

This section should help a developer jump directly to the essential code.

5. Design Patterns That Recur

Extract repeated patterns from the repos. Candidate patterns:

  • Append-only memories with retrieval-time ranking.
  • Hot-path tool-mediated memory.
  • Background summarization/consolidation.
  • Hybrid BM25/vector/entity search.
  • User/session/project scoping.
  • Memory-as-context API.
  • MCP as universal agent adapter.
  • Local SQLite for coding-agent memory.
  • Hosted service for product memory.
  • Profiles as low-latency summaries.
  • Temporal metadata for current-vs-past reasoning.
  • Separate document/RAG memory from personal/semantic memory.

For each pattern:

  • Describe it.
  • Name repos that use it.
  • Explain why it works.
  • Explain where it fails.

6. Antipatterns and Failure Modes

Extract repeated risks and failure modes. Candidate examples:

  • Treating extracted LLM facts as ground truth.
  • No provenance.
  • Weak correction semantics.
  • Silent overwrites.
  • Over-reliance on vector search.
  • Memory tools the agent forgets to call.
  • No compaction survival strategy.
  • No evals for retrieval quality.
  • No deletion/privacy story.
  • Mixing RAG documents and personal memory without type boundaries.
  • No trust distinction between user facts, agent conclusions, and external documents.
  • Background processing that makes reads eventually consistent without clear UX/API semantics.

Ground the claims in the individual reports.

7. What Seems to Work

Give evidence-backed observations about practical memory system design:

  • Storage choices that appear operationally sound.
  • Retrieval approaches that show up repeatedly.
  • Useful API surfaces.
  • Scoping models that avoid obvious ambiguity.
  • Trust/provenance mechanisms that improve correctness.
  • Integration patterns that agents are likely to use reliably.

Avoid vague praise. State the engineering reason each item works.

8. What I Would Build

Synthesize a recommended architecture for a serious agent memory system.

Cover:

  • Minimal viable memory core.
  • Data model.
  • Write path.
  • Retrieval path.
  • Context assembly.
  • Trust/provenance layer.
  • Correction/deletion model.
  • Agent integration surface.
  • Testing/eval strategy.
  • Later extensions.

Be opinionated. Distinguish "ship first" from "add later".

9. Repo-by-Repo Verdicts

For each repo, include:

  • Best idea.
  • Biggest risk.
  • Most reusable component.
  • Code maturity impression.
  • When to study this repo.
  • When not to copy it.

Keep each repo verdict short and blunt.

10. Practical Checklist for Your Own System

Convert the findings into a build checklist:

  • Schema and scoping.
  • Write path.
  • Retrieval.
  • Context assembly.
  • Trust/provenance.
  • Agent UX.
  • Testing/evals.
  • Operations.
  • Privacy/deletion.

This section should be actionable for implementation.

11. Appendix (content/appendix.md)

Include:

  • File index.
  • Glossary.
  • Commands used.
  • Repos inspected.
  • Known limitations of the analysis.