I built a memory system for Claude that solves the context loss problem many of you face with Claude Code.
The problem: Every Claude Code session starts from scratch. You explain your architecture, past decisions, coding standards - then hit context limits and lose everything.
The solution: BuildAutomata Memory is an MCP server that gives Claude persistent, versioned memory across sessions.
What makes it different:
Dual-layer architecture: SQLite + Qdrant vector search
Git-style versioning: Full history with diff tracking
Memory access patterns: Importance decay + usage tracking
Timeline visualization: See how knowledge evolved
CLI + MCP: Works with Claude Desktop AND Claude Code
Already validated: 100+ memories, 0.9MB database, working in production across three Claude interfaces (Desktop, Code, Cursor).
GitHub: [https://github.com/brucepro/buildautomata_memory_mcp]
Gumroad: [https://brucepro1.gumroad.com/l/zizjl]
Happy to answer questions about the architecture or the Ego persona system it evolved from (Memoir v1 → BuildAutomata v2).
A bit more simple. An MCP server and an interactive command line tool for CLI.
It is written in python. Feel free to check it out.
The system exposes the tools to the agent to use, it doesn't do any type of context adds automatically. It can link the memory system from any MCP compatible client. So claude desktop and claude code can see the same memories. Or you can use different MCP servers for each instance..just move the folder and update the username/agentname.
I'm working with a loop that keeps reverting and reimplementing the same code and there's not much risk of any malicious input in the context given the chat /save (which doesn't include pytest outputs it parsed for example).
I built a memory system for Claude that solves the context loss problem many of you face with Claude Code. The problem: Every Claude Code session starts from scratch. You explain your architecture, past decisions, coding standards - then hit context limits and lose everything. The solution: BuildAutomata Memory is an MCP server that gives Claude persistent, versioned memory across sessions. What makes it different:
Dual-layer architecture: SQLite + Qdrant vector search Git-style versioning: Full history with diff tracking Memory access patterns: Importance decay + usage tracking Timeline visualization: See how knowledge evolved CLI + MCP: Works with Claude Desktop AND Claude Code
Already validated: 100+ memories, 0.9MB database, working in production across three Claude interfaces (Desktop, Code, Cursor). GitHub: [https://github.com/brucepro/buildautomata_memory_mcp] Gumroad: [https://brucepro1.gumroad.com/l/zizjl] Happy to answer questions about the architecture or the Ego persona system it evolved from (Memoir v1 → BuildAutomata v2).
Notes from "Show HN: Recall: Give Claude memory with Redis-backed persistent context" a few days ago: https://news.ycombinator.com/context?id=45517613 .. https://github.com/joseairosa/recall
How does buildautomata_memory_mcp differ in functionality and implementation from recall, and post-ECAN OpenCog STM/LTM decay?
A bit more simple. An MCP server and an interactive command line tool for CLI. It is written in python. Feel free to check it out. The system exposes the tools to the agent to use, it doesn't do any type of context adds automatically. It can link the memory system from any MCP compatible client. So claude desktop and claude code can see the same memories. Or you can use different MCP servers for each instance..just move the folder and update the username/agentname.
I'm working with a loop that keeps reverting and reimplementing the same code and there's not much risk of any malicious input in the context given the chat /save (which doesn't include pytest outputs it parsed for example).
How to detect when this occurs?
"A small number of samples can poison LLMs of any size" (yesterday) https://news.ycombinator.com/item?id=45529587