Support for persistent long-term memory (Mem0, Zep, etc.) #221

Activity

1. aquiveal

   added

   enhancementNew feature or requestNew feature or request

   on May 20, 2026
2. aquiveal

   added the

   Feature

   issue type on May 20, 2026
3. edelauna commented on May 21, 2026

   

   edelauna

   on May 21, 2026

   Contributor

   More actions

   Thanks for opening this. I agree this is a valuable direction.

   Zoo Code already persists task/session metadata, but we do not yet have a strong mechanism for cross-task semantic recall: remembering stable workspace conventions, preferred workflows, and reusable lessons across sessions.

   My bias would be to keep the first implementation narrow:

   • local-first and opt-in
   • memory scoped to global and/or workspace
   • explicit create/search/delete flows first
   • retrieval at task startup or session handoff

   I also think it would be better to build on the existing persistence and embedding/vector infrastructure rather than introduce a completely separate memory stack on day one. The harder part here is likely memory lifecycle and hygiene, not storage alone.

   A few design questions seem important early:

   • what scope model we want for v1
   • how memory should be retrieved/injected without turning into prompt bloat
   • what metadata each memory should carry
   • how users inspect, edit, and delete stale memories
   • whether automatic extraction belongs in v1 or should come later

   If there’s interest, a good next step would be aligning on a small v1 design before discussing external providers like Mem0 or Zep.
4. aquiveal commented on May 21, 2026

   

   aquiveal

   on May 21, 2026

   Author

   More actions

   @edelauna. I agree that starting narrow and focusing on memory lifecycle makes sense, but I'd love some clarification on the technical architecture of the local-first approach.

   Mem0 and Zep are definitely not just simple files. They are highly sophisticated, purpose-built memory engines for AI that combine both RAG and Knowledge Graphs to intelligently manage context, entity extraction, and memory decay.

   If we build on the existing infrastructure for a local system first, how exactly will it work under the hood? Are we talking about storing simple JSON/text files in a workspace folder, or leveraging a local database/vector store to handle the embeddings and search?

   I just want to understand how we plan to reliably replicate that cross-task semantic recall locally.
5. edelauna commented on May 21, 2026

   

   edelauna

   on May 21, 2026

   Contributor

   More actions

   I was thinking a simple memory.md or something to start. Then once the mechanics are wired in we can extend that to more technical endpoints/providers.
6. aquiveal commented on Jun 2, 2026

   

   aquiveal

   on Jun 2, 2026

   Author

   More actions

   I’ve been digging deep into this and it turns our memory is not one-size-fits-all. There are different types of memory profiles under the hood, for example:

   • Episodic / Behavioral Memory (Developer Quirks): This is highly dynamic, user-specific, and behavioral. Example: "This developer always writes functional components instead of class components," or "The local environment requires pnpm test:unit rather than standard npm test."
   • Semantic / Structural Memory (Codebase Architecture): This is relatively static, deeply interconnected system data. Example: "The authentication layer lives under /src/lib/auth and relies on a Redis sidecar for JWT blacklisting."

   Because these profiles are so distinct, I'm implementing a multi-provider approach wrapped in a unified abstraction layer, using a structured memory.json that follows Anthropic's memory schema rather than unstructured markdown.

   Here is exactly how I'm structuring the architecture on my fork:

   1. The Storage Layer & Cross-Dev Syncing

   Instead of throwing a loose text file into the workspace, using a structured JSON schema allows the agent to parse, query, and update entities with strict deterministic boundaries. By writing this memory.json directly into the repo root, we get cross-developer memory for free via Git. When one dev maps out a complex project quirk and commits it, the entire engineering team’s agent instantly inherits that architectural context.

   2. Dual-Pathway Ingestion Pipeline

   To keep execution fast and clean, I’ve separated how memory is actually saved into two distinct pathways:

   • The Implicit Way (Asynchronous Background Worker): This runs out-of-band so it doesn't block the user. A smaller, cost-optimized model (or the same model running on a background thread) evaluates conversation logs turn-by-turn or session-by-session. It distills the messy chat history down into cold, hard facts to update the memory.json file asynchronously.
   • The Explicit Way (Agentic Tool-Calling): The runtime LLM is explicitly provisioned with memory-mutation tools. If the agent encounters a specific error, fixes it, and realizes, "Oh, this is an undocumented architectural dependency," it can proactively invoke a tool to write that rule directly into long-term memory.

   3. Mitigating Prompt Bloat (The Lifecycle)

   Dumping the entire memory file into the system prompt on every turn is a massive waste of tokens and degrades attention performance.

   To solve this, memory is strictly pull-based. The system only hydrates a lightweight, top-level context briefing at the absolute start of a session. Beyond that initial bootstrap, the memory tools are completely abstracted; the agent has to intentionally invoke a tool to query its long-term store only when it recognizes it needs historical context for a specific task.

   This setup gives us a zero-dependency, local-first foundation that scales. It works out of the box via Git, keeps our context windows lean, and allows us to easily swap in dedicated graph or vector backends (like Mem0 or Zep) down the road without rewriting the core agent loop.