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

[aquiveal]

Is your feature request related to a problem? Please describe.
I'm always frustrated when the agent treats every new task or session like it's seeing the project for the first time. Even in the same codebase, it constantly has to re-analyze the project structure, re-learn naming conventions, and figure out the correct terminal commands to run. It’s a waste of time and tokens for the agent to "rediscover" my coding style and project architecture every single time I ask it to do something.

Describe the solution you'd like
I want Zoo Code to integrate with a long-term memory provider like Mem0 or Zep.

The agent should be able to store and retrieve "metadata" about the project and my workflow, such as:

1. Naming Conventions: If the project uses camelCase for variables and kebab-case for files, the agent should remember that forever after the first analysis.
2. Terminal Workflow: It should remember which commands (e.g., specific test runners or build scripts) actually work for this project so it stops guessing.
3. Coding Style: It should remember my preferences (e.g., functional vs. OOP, specific library preferences) across sessions.

Instead of a full re-scan, the agent should first query its memory to get a "briefing" on how I work and how this project is structured.

Describe alternatives you've considered

• Manual .roorules: This is high-maintenance. I have to manually write down everything the agent should know.
• Large System Prompts: Expensive and slow. It eats up the context window and the agent eventually forgets the top of the prompt anyway.

Additional context
The goal is to move away from the agent having to "start from zero" every time the context is cleared or a new session begins. Tools like Mem0 are designed specifically to handle this kind of persistent user/project profiling.

[edelauna]

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.

[aquiveal]

@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.

[edelauna]

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.