Live data from Hacker News

Show HN: MCP Memory – Fast Agent Memory Using Google's OKF and SQLite FTS5

github.com

31–40 of 47 posts

Re: Show HN: MCP Memory – Fast Agent Memory Using Google's OKF and SQLite FTS5

#31
What I do currently is having a markdown file named MEMORY.md at the root folder. Then, whenever I create a new conversation with an agent, I refer to that file. That file becomes the initial source of context and knowledge. At the end of an task, before I leave the conversation, I ask the agent to update MEMORY.md with lessons and new knowledge it has gathered from our conversation, it also removes stale or outdated information from that markdown file.

I myself do not care what's written in that file, I steer, instruct and share my knowledge, visions, goal and preferences in our conversations, and the agent will boil that down and update the markdown folder. It has worked very well for me.

I now do not have to worry about creating handoff prompts when creating a new conversation or that I have to teach an agent from the ground up about the context we're in, I just refer to that markdown file.

Re: Show HN: MCP Memory – Fast Agent Memory Using Google's OKF and SQLite FTS5

#33
Last month a Show HN: ContextVault proposed an interesting long-term memory architecture. I discussed the design with the founder: https://news.ycombinator.com/item?id=48900288#48901679 (I think he bailed the conversation when I got too close haha.)

The basic shape is to periodically "distill the conversation into several areas (problem, solution, learnings, 'context' or original problem, plus other fields) and vectorized" (aka vector embedding), then queried against pgvector table to find related "memories". The vectorized distillates are also inserted into the pgvector table with a reference to back to the source conversation to add new memories.

Vector search requires a full scan but it's still pretty fast and I bet it's more accurate the FTS.

Re: Show HN: MCP Memory – Fast Agent Memory Using Google's OKF and SQLite FTS5

#34
post #32

What if the memory were git repo backed, and the FTS5 were a speed-specific optimization? Then the memories could easily be human-reviewed. The repo would be the canonical source, and the FTS5 would be one specific materialization.

that's what we started with, exactly because of the human review part. however we soon found out that there will be a lot of merge conflicts in the text (usually markdown) which heavily depends on the instructions and structure of the data. that's why for Markbase we opted for etag based validations to avoid any potential of conflicts.

Re: Show HN: MCP Memory – Fast Agent Memory Using Google's OKF and SQLite FTS5

#35
post #10

Cool idea. Why is this beneficial over just using markdown files and allowing agents to grep for whatever they need? I've tried various MCP things in the past and I've found they tend to slow down the agent and waste tokens more than they end up helping, but a better memory system is 100% needed for agents.

At hundreds of notes you blow a lot of tokens just to _find one thing_.

Indexing your corpus as you go makes retrieval a lot faster, and then the agent can dig into the specific file if it needs something more.

Re: Show HN: MCP Memory – Fast Agent Memory Using Google's OKF and SQLite FTS5

#36
I have a similar project that I have built and found great success with it storing things like coding standards, decisions, etc.

One thing that is interesting during my work is that Codex and OpenCode using OpenAI models are REALLY good at using the tool, whereas new models and changes in Claude code keep making it difficult to stay on top of it's usability there. It seems like instructions and/or models are changing that cause for it to prefer the Claude Code memory tooling instead of allowing for remote memory tooling.

Opus 5 seems to have made it materially worse (or some harness change around Opus 5, I haven't dug in entirely to analyze). I had to get more in-depth setup instructions to make sure that Claude Code would consistently use my memory tooling.

Re: Show HN: MCP Memory – Fast Agent Memory Using Google's OKF and SQLite FTS5

#37

I have a similar project that I have built and found great success with it storing things like coding standards, decisions, etc. One thing that is interesting during my work is that Codex and OpenCode using OpenAI models are REALLY good at using the tool, whereas new models and changes in Claude code keep making it difficult to stay on top of it's usability there. It seems like instructions and/or models are changing…

New claude models, at least in the context of Claude code, are broadly lobotomized. Move extra slow, write loads tooling scripts you didnt’t ask for, and don’t actually complete the task at hand. They’re like rain man.

Idk though it ebbs and flows. Rn latest OpenAI models are capable of long focused decent work. Surely it’ll flip at some point in the near future /sigh

Re: Show HN: MCP Memory – Fast Agent Memory Using Google's OKF and SQLite FTS5

#39

What I do currently is having a markdown file named MEMORY.md at the root folder. Then, whenever I create a new conversation with an agent, I refer to that file. That file becomes the initial source of context and knowledge. At the end of an task, before I leave the conversation, I ask the agent to update MEMORY.md with lessons and new knowledge it has gathered from our conversation, it also removes stale or outdated…

Sounds like AGENTS.md with a different name.
Post reply on HN