Live data from Hacker News

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

github.com

21–30 of 47 posts

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

#21
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.

[dead]

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

#22
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.

The memories are stored as OKF (Open Knowledge Format), which is markdown + frontmatter (+ constraints/schema imposed thereon).

Having an inverted index (as with FTS5) is useful in that, for a basic single-term lookup, you reduce a sequential scan, O(N), down to O(log N). For small N, the performance difference might not be meaningful. Performance gap widens with more sophisticated queries (boolean operators, ranking, etc).

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

#23

Another week, another agent memory system that is about the same as grep in a memory/ directory.

I'm not sure I follow. Are you suggesting that full text search systems are ultimately a convoluted way of performing O(N) regex searches? If not, I don't see how you arrive at the conclusion that this is "the same as grep in a memory/ directory".

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

#24
post #9
post #5

Earlier quoted context omitted.

I have seen the value of recording past sessions but I am more skeptical of the value in recording facts, which may soon become stale, about a constantly changing code base. Got benchmarks?

Well, do you see the value of writing notes for yourself occasionally, even though they might soon become stale in your constantly changing environment? Yes, right? Same principle. It's a good idea to have a schedule to clean them up periodically - an idea you can also put into a note.

I'll write one off notes for myself, but I am not going to do that in the code base unless it is really high value; it does not scale. The only place I write myself now is AGENTS.md

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

#25
post #5
post #2

Nice to see more OKF-based approaches. My entry in this field is https://rcarmo.github.io/projects/memento/ , which I’ve been running for a few months now.

I have seen the value of recording past sessions but I am more skeptical of the value in recording facts, which may soon become stale, about a constantly changing code base. Got benchmarks?

This is not for code bases, that’s pointless. This is for durable facts like “this is the prod server” or “this is the skill for managing GitHub Actions cleanup policies”.

In short, this is for my agents to have a shared skill library, a shared fact library and durable information such as which projects run where.

The rest should be in your repo.

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

#26
post #4
post #2

Nice to see more OKF-based approaches. My entry in this field is https://rcarmo.github.io/projects/memento/ , which I’ve been running for a few months now.

Since you built something on OKF, how would you contrast it with knowledge graph implementations? How do you manage the ontology of what to keep knowledge about? Any cases where traversal would have helped?

I’m not using pure OKF. Mine has links (both explicit and semantic, based on embeddings), and I tap into both Needle for routing searches and a Qwen/Gemma or gpt-mini for doing the actual traversals on behalf of the client.

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

#27
post #3
post #2

Nice to see more OKF-based approaches. My entry in this field is https://rcarmo.github.io/projects/memento/ , which I’ve been running for a few months now.

Please excuse my noob-ish, naïve question, but to what extent is the business of getting the LLM to actually consult memory a model-dependent thing? Do you have to introduce the tool and guide models with different language for different model families? Looking at your tool descriptions (as wit the ones on the original post) I wonder if this something perhaps only current frontier models will do, but the systems them…

All SOTA models seem to work fine (including Sonnet and Gemini), as does Kimi and DeepSeek. But this is not for short-term memory.

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

#28
post #24
post #9

Earlier quoted context omitted.

Well, do you see the value of writing notes for yourself occasionally, even though they might soon become stale in your constantly changing environment? Yes, right? Same principle. It's a good idea to have a schedule to clean them up periodically - an idea you can also put into a note.

I'll write one off notes for myself, but I am not going to do that in the code base unless it is really high value; it does not scale. The only place I write myself now is AGENTS.md

Memento is for that kind of cross-project, long term notes.

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

#29
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.

The memories are stored as OKF (Open Knowledge Format), which is markdown + frontmatter (+ constraints/schema imposed thereon). Having an inverted index (as with FTS5) is useful in that, for a basic single-term lookup, you reduce a sequential scan, O(N), down to O(log N). For small N, the performance difference might not be meaningful. Performance gap widens with more sophisticated queries (boolean operators, ranking…

[dead]
Post reply on HN