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.

• cstrahan

  today at 5:12 PM

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

• agentifysh

  today at 4:33 PM

  im asking the same thing myself for personal projects seems markdown files is best.

  i can see for public facing deployments agent memory like this could result in faster roundtrips.

• rgbrgb

  today at 4:09 PM

  for one, the mcp-server architecture makes it usable from claude.ai and other surfaces where you have mcp but no filesystem. there are claude-specific workarounds (workspaces) but you lose portability across systems.

  • jrflo

    today at 4:29 PM

    Hmm, ok. I guess I rarely use the web interface and everything that I have agents record as "memory" in markdown is always accessible locally. If I'm accessing something remotely, I use the ChatGPT app with remote which connects directly to the host computer.

• Natalia724

  today at 5:03 PM

  [dead]

For those looking for similar tools, there is also https://markbase.cloud/ as a hosted service. (Disclaimer: we built it for internal use first and would like to open source with the community help as we don’t have much experience in OSS maintenance)

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.

• ejp

  today at 2:49 PM

  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?

• dofm

  today at 2:49 PM

  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 themselves seem like they'd be even more useful for open weights models with shorter working contexts.

• esafak

  today at 2:58 PM

  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?

  • sho

    today at 3:10 PM

    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.

    • esafak

      today at 5:59 PM

      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

How is this any different from all the other Memory stuff we have? mem0 etc etc that do the same thing?

• rgbrgb

  today at 4:18 PM

  agree there are a lot of these but they're all pretty simple (including mine [0]) so I think building your own and playing around with architecture is useful and fun.

  [0]: https://setoku.com

Looks very interesting. Can you explain for noobs why using Google's OKF format and not plain MD files?

• pcbmaker20

  today at 3:01 PM

  OKF is basically md files with front-matter for meta data

did you test if that actually outperforms local claude code memory by any metric?

• rgbrgb

  today at 4:05 PM

  that's a good idea. how might you test this? could also include a codex memory test.

  I'm guessing having a portable memory that's comparable with first party memory is the goal.

How is this different from what's built into Claude?

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

• cstrahan

  today at 5:15 PM

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

Using SQLite FTS5 for fast agent memory is such a pragmatic architectural choice. Great Show HN project.