4 ms·

I built a memory system for Claude that solves the context loss issue

3 points by brucepro 1y ago

brucepro 1y ago
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 https://github.com/brucepro/buildautomata_memory_mcp] Gumroad: [https://brucepro1.gumroad.com/l/zizjl 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).
westurner 1y ago
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://news.ycombinator.com/context?id=45517613 .. https://github.com/joseairosa/recall https://github.com/joseairosa/recall How does buildautomata_memory_mcp differ in functionality and implementation from recall, and post-ECAN OpenCog STM/LTM decay?
- westurner 1y ago
  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 https://news.ycombinator.com/item?id=45529587
  - brucepro 1y ago
    The version history with diffs helps with that. When you store/update memories, the system tracks changes over time. You can query the timeline to see "what solutions did I already try for X problem?" The Memory decay approach (tracking access patterns + importance decay) also surfaces this - if you keep accessing the same memory about a bug that never gets resolved, that's a signal. Not automatic loop detection yet, but the infrastructure is there. Could build a simple heuristic: if similar memory content gets created/updated N times within short timeframe, flag it as potential loop. The poisoning concern is real. Our design mitigates it somewhat - agents explicitly choose what to store (tool-based, not automatic injection), and you can prune/audit memories.
    - westurner 1y ago
      > Could build a simple heuristic: if similar memory content gets created/updated N times within short timeframe, flag it as potential loop That would probably prevent waste and could scale. From https://news.ycombinator.com/context?id=45561039 https://news.ycombinator.com/context?id=45561039 : > /? llm firewall: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=llm%20firewall&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... There's probably already a name for 'Sensitivity analysis'; how does the output vary with/without particular context?
- brucepro 1y ago
  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.

3 points by brucepro 1y ago

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 https://github.com/brucepro/buildautomata_memory_mcp] Gumroad: [https://brucepro1.gumroad.com/l/zizjl 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).

westurner 1y ago

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://news.ycombinator.com/context?id=45517613 .. https://github.com/joseairosa/recall https://github.com/joseairosa/recall How does buildautomata_memory_mcp differ in functionality and implementation from recall, and post-ECAN OpenCog STM/LTM decay?

westurner 1y ago
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 https://news.ycombinator.com/item?id=45529587
- brucepro 1y ago
  The version history with diffs helps with that. When you store/update memories, the system tracks changes over time. You can query the timeline to see "what solutions did I already try for X problem?" The Memory decay approach (tracking access patterns + importance decay) also surfaces this - if you keep accessing the same memory about a bug that never gets resolved, that's a signal. Not automatic loop detection yet, but the infrastructure is there. Could build a simple heuristic: if similar memory content gets created/updated N times within short timeframe, flag it as potential loop. The poisoning concern is real. Our design mitigates it somewhat - agents explicitly choose what to store (tool-based, not automatic injection), and you can prune/audit memories.
  - westurner 1y ago
    > Could build a simple heuristic: if similar memory content gets created/updated N times within short timeframe, flag it as potential loop That would probably prevent waste and could scale. From https://news.ycombinator.com/context?id=45561039 https://news.ycombinator.com/context?id=45561039 : > /? llm firewall: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=llm%20firewall&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... There's probably already a name for 'Sensitivity analysis'; how does the output vary with/without particular context?
brucepro 1y ago
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.