{"id":50819285,"url":"https://github.com/lossless-group/study-memory-layers-for-agents","last_synced_at":"2026-06-13T12:06:07.227Z","repository":{"id":358561037,"uuid":"1227598587","full_name":"lossless-group/study-memory-layers-for-agents","owner":"lossless-group","description":"A study of production memory systems for AI agents — storage topology, write policy, scopes, schema, and recall surface.","archived":false,"fork":false,"pushed_at":"2026-05-28T06:19:03.000Z","size":170,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-05-28T08:11:39.421Z","etag":null,"topics":["context-engineering","context-layer","context-layer-for-ai","context-management","memory-layer","memory-layer-for-ai"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/lossless-group.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-05-02T22:51:19.000Z","updated_at":"2026-05-28T06:19:08.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/lossless-group/study-memory-layers-for-agents","commit_stats":null,"previous_names":["lossless-group/study-memory-layers-for-agents"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/lossless-group/study-memory-layers-for-agents","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lossless-group%2Fstudy-memory-layers-for-agents","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lossless-group%2Fstudy-memory-layers-for-agents/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lossless-group%2Fstudy-memory-layers-for-agents/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lossless-group%2Fstudy-memory-layers-for-agents/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/lossless-group","download_url":"https://codeload.github.com/lossless-group/study-memory-layers-for-agents/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lossless-group%2Fstudy-memory-layers-for-agents/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34283445,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-13T02:00:06.617Z","response_time":62,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["context-engineering","context-layer","context-layer-for-ai","context-management","memory-layer","memory-layer-for-ai"],"created_at":"2026-06-13T12:06:04.389Z","updated_at":"2026-06-13T12:06:07.214Z","avatar_url":"https://github.com/lossless-group.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Memory Layers for Agents — Study\n\n## The question\n\n\u003e How do production memory systems for AI agents structure recall —\n\u003e across vector, graph, and key-value stores; across user, session, and\n\u003e agent scopes; across short-term context and long-term knowledge —\n\u003e and which conventions are converging?\n\nThe interesting bits are not the embeddings themselves; those are commodity.\nThe interesting bits are: how does each system *decide* what to remember,\n*when* to update, *how* to scope, and *what* shape the memory artifacts\ntake on disk and on the wire.\n\n## What we are looking at, repo by repo\n\nWhen reading each entry below, the working checklist is:\n\n- **Storage topology.** Single store or hybrid (vector + graph + KV)? What\n  determines which store handles which class of memory?\n- **Write policy.** Append-only? Self-editing? LLM-summarized? Reconciled\n  against a graph? When does a memory get superseded vs. merged?\n- **Scopes \u0026 namespacing.** User / session / agent / tenant — how are these\n  modeled, and how does retrieval respect them?\n- **Schema of a memory.** What fields does a single memory record carry?\n  Timestamps, provenance, confidence, embedding ref, references to other\n  memories?\n- **Recall surface.** Vector similarity, graph traversal, time-based, hybrid\n  ranking? What's the API the agent actually calls?\n- **Eviction \u0026 compaction.** Is there a policy? A summarizer? A TTL?\n- **Serialization on disk.** What does the persisted form look like? JSON\n  blobs, parquet, a specific graph format, SQL rows? Could a non-AI program\n  parse it cleanly?\n- **Operational story.** Local-first? Server-required? Stateless agent +\n  external store?\n\n---\n\n## The design space at a glance\n\n| Bet | Entry |\n|---|---|\n| Memory baked into the model (frozen-backbone transformer adapter) | [Delta-Mem](./delta-mem) |\n| Real typed bi-temporal graph | [Graphiti](./graphiti) |\n| Self-editing core memory + paged archival (the MemGPT lineage) | [Letta](./letta) |\n| Hybrid vector + entity-link + tight CRUD API | [Mem0](./mem0) |\n| Verbatim chunks + hybrid recall, no extraction | [MemPalace](./mempalace) |\n| Typed/scoped facts + deterministic supersession + outcome learning | [Neo](./neo) |\n| Immutable Postgres log + summary DAG | [Volt](./volt) |\n| Folder → in-process NetworkX KG + Leiden + MCP query surface | [Graphify](./graphify) |\n| Multi-peer \"theory of mind\" — what A knows about B, derived async | [Honcho](./honcho) |\n| Context as a filesystem; L0/L1/L2 abstract tiers; unified memories + resources + skills | [OpenViking](./openviking) |\n| Typed memory taxonomy (world facts / experiences / mental models) + bank-based scoping | [Hindsight](./hindsight) |\n| 12+ semantic categories with bi-temporal validity (validFrom/validUntil) | [RetainDB](./retaindb) |\n| Universal RAG + memory layer, currently top of LongMemEval / LoCoMo / ConvoMem | [Supermemory](./supermemory) |\n| Coding-agent context tree (CLI + optional cloud sync; Elastic-licensed) | [ByteRover CLI](./byterover-cli) |\n| Procedural/working memory — versioned dependency-typed task graph on a Git-like SQL DB (Dolt), no vectors | [Beads](./beads) |\n| Conformance benchmark (the yardstick) | [StateBench](./statebench) |\n\nDeep per-entry write-ups live in [`context-v/profiles/`](./context-v/profiles).\n\n## In the study now\n\n### [mem0](./mem0)\n- **Repo:** https://github.com/mem0ai/mem0 — *Universal memory layer for AI Agents*\n- **Maintainer:** Mem0.ai (`mem0ai` org)\n- **Why this is here:** Pioneers a composable hybrid architecture (vector +\n  graph + KV store) with adaptive updates. Multi-level recall across\n  user / session / agent scopes is its headline. Reported +26% accuracy\n  over OpenAI memory and 91% faster responses in their benchmarks. Most\n  starred entry in this space (54k+) and the most explicit about being a\n  *layer* rather than a framework.\n\n### [neo](./neo)\n- **Repo:** https://github.com/Parslee-ai/neo — *A self-improving code\n  reasoning engine with persistent semantic memory*\n- **Maintainer:** Parslee AI (`Parslee-ai` org)\n- **Why this is here:** A reasoning engine, not a framework — the memory\n  is *the point*, not a feature bolted on. Worth comparing schema and\n  write-policy choices against Mem0 and Graphiti. Smaller surface than\n  the major players, which makes it easier to read end-to-end.\n\n### [delta-mem](./delta-mem)\n- **Repo:** https://github.com/declare-lab/delta-Mem —\n  *δ-mem: Efficient Online Memory for Large Language Models*\n- **Maintainer:** declare-lab (SUTD) — Jingdi Lei, Di Zhang, Junxian Li,\n  Weida Wang, Kaixuan Fan, Xiang Liu, Qihan Liu, Xiaoteng Ma, Baian Chen,\n  Soujanya Poria\n- **Why this is here:** The architectural counter-bet to every other\n  entry. While Mem0, MemPalace, Graphiti, Neo, and Volt all answer \"where\n  does the agent store and look things up,\" Delta-Mem answers \"what if\n  memory was part of the model's forward pass?\" A frozen-backbone\n  transformer adapter that gives each attention head a low-rank dense\n  **state matrix** updated by a learned **delta rule** (S_{t+1} = λ·S_t\n  − β·(S_t·k_t)⊗k_t + β·v_t⊗k_t), with three temporal write\n  granularities (TSW/SSW/MSW), a Triton-accelerated affine scan, and a\n  public Qwen3-4B-Instruct adapter on Hugging Face. Released alongside\n  [arXiv:2605.12357](https://arxiv.org/abs/2605.12357). Evaluated on\n  LoCoMo, HotpotQA, IFEval, GPQA Diamond, and MemoryAgentBench. This is\n  a research artifact (not a deployable library), and that's the point —\n  it forces the question \"is agent memory even a retrieval problem?\"\n  that the system-level entries quietly assume.\n\n### [letta](./letta)\n- **Repo:** https://github.com/letta-ai/letta — *Platform for building\n  stateful agents: AI with advanced memory that can learn and\n  self-improve over time*\n- **Maintainer:** letta-ai (formerly MemGPT-ai; Charles Packer, Sarah\n  Wooders et al.)\n- **Why this is here:** The direct successor to **MemGPT** — the 2023\n  Berkeley paper that named the agent-memory problem and shipped the\n  OS-inspired hierarchical-memory pattern (core context = RAM, archival\n  = disk, recall = paging). The MemGPT lineage is the framing fact.\n  Letta is the operational productization: every agent is a persistent\n  Postgres row, **core memory** is a set of agent-editable **Blocks**\n  rendered into the system prompt, **archival memory** is a paginated\n  pgvector-backed passage store with semantic search. The agent edits\n  its own memory via `core_memory_append` / `core_memory_replace` —\n  the headline MemGPT design move that no other entry in the study\n  replicates. Ships as a FastAPI + Postgres + pgvector compose stack\n  with REST, WebSocket, and an **OpenAI-compatible\n  `/v1/chat/completions` endpoint** so a Letta agent looks like a\n  ChatGPT-shaped model to any client. **Multi-agent block sharing** is\n  a database join (a single Block row can belong to many agents). The\n  newer **git-backed memory mode** renders blocks as files\n  (`system/persona.md`, `skills/.../SKILL.md`) and turns every memory\n  edit into a commit — making it the closest entry in the study to our\n  own `context-vigilance` discipline, but with the agent as committer.\n\n### [graphiti](./graphiti)\n- **Repo:** https://github.com/getzep/graphiti — *Build Real-Time Knowledge\n  Graphs for AI Agents*\n- **Maintainer:** Zep Software, Inc. (Paul Paliychuk, Preston Rasmussen,\n  Daniel Chalef)\n- **Why this is here:** The only entry in the study that puts a real,\n  typed, **bi-temporal graph** between the agent and its memories — four\n  interchangeable Cypher-flavoured backends (Neo4j, FalkorDB, Kuzu,\n  Neptune), a single-LLM-call episode-to-graph extraction pipeline with\n  Pydantic-typed entities, hybrid BM25 + cosine + BFS recall with\n  cross-encoder reranking, and label-propagation community detection.\n  Every edge carries both `valid_at`/`invalid_at` (real-world validity)\n  and `created_at`/`expired_at` (system time) — textbook bi-temporality\n  brought to agent memory. Backed by a peer-reviewed paper\n  ([*Zep: A Temporal Knowledge Graph Architecture for Agent\n  Memory*](https://arxiv.org/abs/2501.13956)). The interesting\n  comparison is Graphiti vs MemPalace: opposite bets on structure\n  (MemPalace says structure is over-engineered; Graphiti says it's\n  under-engineered).\n\n### [mempalace](./mempalace)\n- **Repo:** https://github.com/MemPalace/mempalace — *The best-benchmarked\n  open-source AI memory system. And it's free.*\n- **Maintainer:** MemPalace Contributors (`MemPalace` org; milla-jovovich,\n  @bensig)\n- **Why this is here:** The most direct counter-bet to Mem0 in the study.\n  Same problem space (give agents persistent memory), nearly opposite\n  design choice at the write step: MemPalace stores **verbatim text** —\n  no LLM-driven extraction, no summarization — in ChromaDB\n  (`mempalace_drawers` + `mempalace_closets`) plus a local SQLite\n  temporal entity graph. Recall is hybrid (semantic + BM25 + closet-boost,\n  closets *signal* never *gate*), and the published benchmarks\n  (`benchmarks/BENCHMARKS.md`) report 96.6% R@5 on LongMemEval with **zero\n  LLM calls** at query time, and 92.9% vs Mem0's 30–45% on ConvoMem — a\n  ~2× margin attributed directly to extraction losing information.\n  Inspired by Zettelkasten + Method of Loci (`MISSION.md`). The\n  benchmark-honesty note in `BENCHMARKS.md:70-95` (the 100% headline\n  involved teaching-to-test; the held-out figure is 98.4%) is worth\n  reading in its own right.\n\n### [volt](./volt)\n- **Repo:** https://github.com/Martian-Engineering/volt — *Coding agent with\n  lossless context management*\n- **Maintainer:** Martian Engineering (`Martian-Engineering` org)\n- **Why this is here:** A coding agent built around **Lossless Context\n  Management (LCM)** — a dual-state design where every user message,\n  assistant response, and tool result is persisted verbatim (immutable\n  store) and the active context is assembled from recent raw messages plus\n  precomputed summary nodes. Storage is a DAG in embedded Postgres\n  (`voltcode_lcm`, optional external via `LCM_DATABASE_URL`). The\n  write/summarize policy is **deterministic** (soft/hard token thresholds\n  drive a control loop), not LLM-decided — a useful contrast against\n  Mem0's adaptive updates and Letta's self-editing memory. Two runtime\n  modes (Dolt: evict oldest with ghost-cue off-context retrieval; Upward:\n  recursive bottom-up condensation, default) make the eviction/compaction\n  trade-off explicit and readable.\n\n### [graphify](./graphify)\n- **Repo:** https://github.com/safishamsi/graphify — *AI coding assistant\n  skill that turns any folder of code, docs, papers, images, or videos\n  into a queryable knowledge graph*\n- **Maintainer:** Safi Shamsi (`safishamsi`); MIT licensed; PyPI package\n  `graphifyy`\n- **Why this is here:** The codebase-as-memory bet. Where every other\n  entry models *conversational* memory (user / session / agent turns),\n  Graphify models the **static corpus an agent works against** as a\n  persistent, queryable knowledge graph and exposes it to the agent via\n  **MCP** (`graphify/serve.py:1`). The pipeline is single-process and\n  legible end-to-end: `detect → extract → build → cluster → analyze →\n  report → export` (`ARCHITECTURE.md`), with tree-sitter parsers for\n  ~30 languages emitting `{nodes, edges}` dicts that get folded into a\n  NetworkX graph, **Leiden community detection** via graspologic with a\n  NetworkX-Louvain fallback (`graphify/cluster.py:48-76`), and\n  per-extraction **confidence labels** (`EXTRACTED` / `INFERRED` /\n  `AMBIGUOUS`) carried on every edge so the agent can reason about how\n  much to trust each relation. The MCP server exposes graph-query tools\n  (`query_graph`, `get_neighbors`, `get_community`, `god_nodes`,\n  `shortest_path`, PR-triage tools) — so \"memory\" here is structural\n  recall over the project, not episodic recall over a conversation. The\n  interesting contrast is against Graphiti and MemPalace: Graphiti puts\n  a *bi-temporal* graph DB between agent and memory; MemPalace stores\n  verbatim chunks; Graphify denies the graph-DB premise altogether and\n  ships the graph as a single `graph.json` next to a static HTML viewer.\n  A useful \"do we even need a server?\" data point in a study otherwise\n  dominated by server-backed designs.\n\n### [honcho](./honcho)\n- **Repo:** https://github.com/plastic-labs/honcho — *Build AI agents\n  that truly know your users*\n- **Maintainer:** Plastic Labs (`plastic-labs` org); AGPL-3.0\n- **Why this is here:** The only entry in the study that puts a\n  **multi-peer / theory-of-mind** model at the center of the design.\n  Where Mem0 models memories *belonging to a user* and Letta models\n  memories *editable by an agent*, Honcho models *what one peer\n  understands about another* — `peers`, `sessions`, `messages`,\n  `workspaces` as primary entities, with vector-embedded \"internal\n  collections\" keyed by the (observer, observed) pair. Write path is\n  **append-only messages + async background reasoning**: new messages\n  immutably persist, and a *deriver* worker generates summaries, peer\n  cards, and conclusions out-of-band. This is closer to the \"agents\n  building rich models of users\" framing that Plastic Labs' research\n  thread (Open Source Honcho, the \"Tutor-GPT\" lineage) has been chasing\n  since 2023, and it's the cleanest example in the study of separating\n  *storage* from *understanding*. Worth comparing the deriver to Volt's\n  deterministic summary thresholds — both are explicit, neither blocks\n  the agent loop.\n\n### [openviking](./openviking)\n- **Repo:** https://github.com/volcengine/OpenViking — *An open-source\n  context database for AI agents (file-system paradigm)*\n- **Maintainer:** Volcengine (ByteDance's cloud division); AGPL-3.0\n  main / Apache-2.0 CLI + examples\n- **Why this is here:** The most architecturally distinct entry on the\n  storage side. OpenViking refuses the flat-vector premise entirely and\n  organizes context as a **filesystem** — `viking://resources/`,\n  `viking://user/`, `viking://agent/` — with three abstraction tiers\n  per node (**L0** one-sentence abstract, **L1** overview, **L2** full\n  data) so retrieval can match at the coarsest tier and drill down\n  on demand. \"Directory recursive retrieval\" combines vector search\n  with hierarchical navigation. Unifies what every other study entry\n  treats as separate concerns: **memories** (user / agent task),\n  **resources** (docs, repos), and **skills** (agent instructions)\n  are all just nodes in the same tree. ByteDance-scale backing is the\n  operational story (Rust core in `crates/`, multi-language CLI, Docker\n  deploy). The interesting compare-and-contrast is against Letta's\n  git-backed memory mode (which also renders memory as files but on a\n  flat-ish layout) and against Graphify (which also collapses\n  resource-as-context but as a knowledge graph rather than a tree).\n\n### [hindsight](./hindsight)\n- **Repo:** https://github.com/vectorize-io/hindsight — *Agent memory\n  system that helps AI agents learn over time*\n- **Maintainer:** Vectorize.io (`vectorize-io` org); MIT\n- **Why this is here:** The first entry in the study to commit to a\n  **typed memory taxonomy** as a first-class axis: every memory is one\n  of *world fact*, *experience*, or *mental model*. Storage is\n  deliberately polyglot — vector for semantics, graph for entity /\n  causal links, time series for temporal context, BM25 for lexical\n  match — and recall is a three-verb surface (`retain`, `recall`,\n  `reflect`) where `reflect` is the unusual one: the agent analyzes\n  its *own existing memories* rather than the world. Per-user /\n  per-agent isolation lives in a \"bank\" abstraction. Ships as a full\n  open-source stack — Python API, Node/Python SDKs, CLI, Docker /\n  Helm — not a wrapper around a hosted service. The compare-and-\n  contrast against Mem0 is direct: same hybrid-retrieval thesis, but\n  Hindsight argues the *type of memory* (epistemic vs. experiential\n  vs. inferential) should drive write, not just retrieval ranking.\n\n### [retaindb](./retaindb)\n- **Repo:** https://github.com/RetainDB/RetainDB — *Durable memory for\n  AI agents — decisions, preferences, workflows, corrections, project\n  facts, session handoffs that survive across conversations*\n- **Maintainer:** RetainDB organization; Apache-2.0 (local / SDK / MCP),\n  BSL-1.1 (server)\n- **Why this is here:** Pushes the typed-memory bet further than\n  Hindsight — **12+ semantic categories** (factual, preference,\n  procedural, decision, constraint, correction, session-summary, etc.)\n  — and pairs it with **bi-temporal validity** (`validFrom` /\n  `validUntil`) so superseding stale facts is an explicit, queryable\n  operation rather than something the recall ranker has to paper over.\n  Hybrid retrieval is \"lexical + vector + graph signals + RRF fusion +\n  reranking.\" Three deployment modes (Local single-machine, Server with\n  Postgres + pgvector, managed Cloud) cover the same \"library / server\n  / hosted\" trifecta Mem0 ships, but the BSL-licensed server is the\n  flag for anyone planning on commercial hosting. The contrast against\n  Mem0 is direct on the supersession axis (Mem0 has none in OSS;\n  RetainDB makes it a first-class column) and against Neo on the\n  *typed-categories-vs-typed-facts* axis (Neo carries a `superseded_by`\n  chain on a single fact type; RetainDB enumerates categories).\n\n### [supermemory](./supermemory)\n- **Repo:** https://github.com/supermemoryai/supermemory — *The memory\n  and context layer for AI*\n- **Maintainer:** supermemoryai research lab; MIT\n- **Why this is here:** The current benchmark-leaderboard occupant —\n  ranked **#1 on LongMemEval, LoCoMo, and ConvoMem** as of mid-2026,\n  the three headline harnesses every other entry in this study reports\n  against (compare to MemPalace's 96.6% R@5 on LongMemEval and Mem0's\n  91.6 / 93.4 on LoCoMo / LongMemEval — the leaderboard moves fast).\n  At ~22.7k stars and 1,600+ commits, the most active OSS entry after\n  Mem0 / Letta. Design surface is the **universal RAG + memory** bet:\n  fact extraction from conversations + user-profile maintenance +\n  hybrid search + multimodal ingest + external connectors (Google\n  Drive, Notion, GitHub) that sync content into the same store. Scopes\n  are `containerTag` (typically a user id) plus optional project tags.\n  Claims to handle \"temporal changes, contradictions, and automatic\n  forgetting\" — which makes the comparison against StateBench (the\n  yardstick) the obvious next step.\n\n### [byterover-cli](./byterover-cli)\n- **Repo:** https://github.com/campfirein/byterover-cli — *Memory Hub\n  for AI coding agents to remember*\n- **Maintainer:** ByteRover team (`campfirein` org)\n- **License note:** **Elastic License 2.0** — source-available, not\n  OSI-open-source. Commercial use is restricted. We pin it for study\n  reading; do not vendor the code into a product without reading the\n  license.\n- **Why this is here:** The only entry in the study focused\n  specifically on **coding-agent memory** as an end-user product\n  (compare to Volt, which is also coding-agent-shaped but ships as a\n  full agent; ByteRover is *just* the memory hub). Organizes codebase\n  knowledge into a **context tree** with local file-based storage and\n  optional cloud sync. Project-level scope (per directory),\n  multi-machine access, team sharing via ByteRover Cloud. Integrates\n  with Cursor, Claude Code, and 20+ LLM providers as the consumer\n  surface. The reason it earns a pin despite the licensing caveat:\n  the **CLI + REPL + dashboard** packaging is a distinct deployment\n  story (most other entries assume the agent is the only consumer; here\n  the human and the agent are both editors of the same context tree)\n  and worth studying as one possible answer to \"how does a *team* of\n  developers share agent memory.\"\n\n### [beads](./beads)\n- **Repo:** https://github.com/gastownhall/beads — *Distributed graph\n  issue tracker for AI agents, powered by Dolt*\n- **Maintainer:** `gastownhall` org; Go module path\n  `github.com/steveyegge/beads` (Steve Yegge et al.); MIT. Ships as\n  `@beads/bd` (npm), `beads-mcp` (PyPI), `beads` (Homebrew).\n- **Why this is here:** The entry that names the missing axis. Every other\n  entry models *episodic / semantic* memory — recall over conversation or\n  facts. Beads models **procedural / working memory**: the agent's own\n  task graph, so a coding agent can survive context compaction, session\n  resets, and account rotations without losing the plot or redoing work.\n  And it makes the study's sharpest storage bet — **no vector store, no\n  embeddings, no semantic similarity anywhere.** Recall is SQL views +\n  graph traversal over a typed dependency graph (`blocks`, `parent-child`,\n  `supersedes`, `relates-to`, `discovered-from`, ~19 edge kinds) stored in\n  **[Dolt](https://github.com/dolthub/dolt)** — a Git-like, versioned,\n  MySQL-compatible database with cell-level merge and native branching.\n  **Hash-based IDs** (`bd-a1b2` = base36 of a SHA256 over\n  title+description+creator+timestamp+nonce, `internal/idgen/hash.go`) give\n  conflict-free writes across parallel agents and branches — no shared\n  auto-increment counter to collide on. The write path is mutate-the-row +\n  append to an immutable `events` audit trail; supersession is an explicit\n  `supersedes` graph edge (compare Neo / RetainDB). Eviction is real:\n  closed issues get **Claude-Haiku-summarized \"memory decay\"**\n  (`internal/compact/`) into Summary / Key Decisions / Resolution, with the\n  full original preserved in snapshot tables for recovery. A separate,\n  deliberately dumb memory surface — `bd remember` / `recall` / `memories`\n  / `forget` (`cmd/bd/memory.go`) — stores slugified key→value insights in\n  the config KV table and re-injects them every session via `bd prime`\n  (`cmd/bd/prime.go`) as a SessionStart hook. On disk, the Dolt DB under\n  `.beads/` is authoritative; `.beads/issues.jsonl` is a plain-JSON export\n  for viewing/interchange only — *not* the source of truth. Local-first and\n  git-optional (`BEADS_DIR` + `--stealth`), with peer-to-peer **federation**\n  carrying data-sovereignty tiers (the only GDPR-tier knob in the study).\n  The cleanest pairing is Beads vs Volt (both coding-agent, both\n  database-backed — and mind the trap: Volt's *eviction mode* is named\n  \"Dolt\" while Beads is *built on* Dolt the DB); the cleanest contrast is\n  Beads vs every vector-backed entry. Deep write-up:\n  [`context-v/profiles/Profile__Beads.md`](./context-v/profiles/Profile__Beads.md).\n\n### [statebench](./statebench)\n- **Repo:** https://github.com/Parslee-ai/statebench — *Conformance test\n  for stateful AI agents. Measures state correctness over time.*\n- **Maintainer:** Parslee AI (`Parslee-ai` org)\n- **Why this is here:** A *benchmark* rather than an implementation —\n  fills a different slot in the study. Pinning it lets us evaluate the\n  memory-layer implementations against a common harness, instead of\n  trusting each project's self-reported numbers. Pair it with Mem0 and\n  neo as the units under test.\n\n---\n\n## Candidates to add (verified to exist on GitHub)\n\nThese are not yet pinned as submodules. When the study expands, run\n`git submodule add \u003curl\u003e \u003cslug\u003e` from the study root to add any of them.\n\n### Memory-specialized\n\n- **Zep / Graphiti** — temporal knowledge graphs for session memory.\n  Integrates with LangChain / LangGraph. The interesting code lives in\n  Graphiti, not in the Zep examples repo.\n  - https://github.com/getzep/graphiti — *Build Real-Time Knowledge Graphs\n    for AI Agents* (25k★ — recommended entry point)\n  - https://github.com/getzep/zep — examples and integrations (4.5k★)\n\n- **Letta** — open-source server with self-editing memory, descended from\n  MemGPT. Stateful agents that persist user preferences and survive\n  conversation resets.\n  - https://github.com/letta-ai/letta (22k★)\n\n- **LangMem** — LangChain's memory utilities; summarization for context\n  limits. Smaller surface than the others but tightly integrated with\n  the LangChain stack.\n  - https://github.com/langchain-ai/langmem (1.4k★)\n\n- **Memary** — graph-centric memory layer for autonomous agents. Worth\n  comparing schema choices against Mem0 and Graphiti.\n  - https://github.com/kingjulio8238/Memary (2.6k★)\n\n- **Cognee** — pipelines for RAG-style memory; positions itself as\n  \"memory for your AI agents in 6 lines of code.\" Focus on ingestion\n  ergonomics.\n  - https://github.com/topoteretes/cognee (17k★)\n\n### Broader frameworks (not memory-first, but ship memory primitives)\n\nThese are large enough that they will dilute the study if added wholesale.\nWorth referencing only if a specific subdir is what we want to study.\n\n- **LangChain** — modular memory buffers and summary memory live somewhere\n  in here. https://github.com/langchain-ai/langchain (135k★)\n- **LlamaIndex** — document-integrated memory and retrieval.\n  https://github.com/run-llama/llama_index (49k★)\n- **Cloudflare Agents** — Workers-runtime agent memory and ingestion.\n  https://github.com/cloudflare/agents (4.8k★)\n\n---\n\n## Reading order suggestion\n\n1. Start with **Mem0**'s README and `docs/` for the topology overview, then\n   walk the source for the write/update path (look for \"add\", \"update\",\n   \"consolidate\" verbs in the public API).\n2. Compare to **Graphiti**'s temporal-graph approach — same problem,\n   different storage primitive.\n3. Compare to **Letta**'s self-editing memory — same problem, different\n   *control* primitive (the agent edits memory, not the framework).\n\nBy the time those three are read in sequence, the design space should be\nmostly visible.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flossless-group%2Fstudy-memory-layers-for-agents","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flossless-group%2Fstudy-memory-layers-for-agents","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flossless-group%2Fstudy-memory-layers-for-agents/lists"}