OKF Agent Memory – Git-native persistent memory for AI coding agents

Hey HN,

We built OKF Agent Memory because we were frustrated with how AI coding agents (Claude Code, Cursor, Windsurf, local models) handle long-term project context.

Every time a context window closes or a session resets, the agent forgets architectural decisions, domain discoveries, and operational rules. The existing solutions fall into two extremes: 1. Ad-hoc flat files (CLAUDE.md, AGENTS.md, .cursorrules) that inevitably balloon into 20k-token monoliths, degrade agent focus, and cause "lost-in-the-middle" attention failure. 2. Vector databases / background daemons (Mem0, Letta, Zep) that introduce heavy runtimes (Python/Node), docker containers, proprietary storage silos, and recurring embedding API costs (adding 200–800ms per retrieval call).

Our approach: The "LLM Wiki" in pure Go.

OKF Agent Memory (v0.1.0) is a single, zero-dependency Go binary that turns your Git repository into a structured, self-validating knowledge corpus based on Google's Open Knowledge Format (OKF) v0.2 specification:

• In-Memory BM25 Search (Try it in 30 seconds: $ brew install okf-memory/tap/okf $ cd your-project && okf bootstrap .

GitHub: https://github.com/okf-memory/okf-agent-memory Docs & Landing Page: https://okf-memory.dev

We'd love your feedback on the architecture, the Go implementation, and how your coding agents behave with progressive disclosure memory!

cool going to check it out, I've got an opensource project that might compliment it that I'm excited to try

https://github.com/ucsandman/declick

How well does the model adhere to using this in a harness like Codex where it may be directed to use the built in memory tooling? Maybe I'll need to try an experiment directing it to save to its native memory to use OKF instead

[dead]

I love the idea! OKF 0.2 solves for the problem of the AIs generating massive amounts of documentation (far more than humans ever created) and giving it equal-weight over what a human actually approved and committed to. I've been using it to attribute my decisions with specific directions on how to ensure that it takes strong direction from my explicit decisions and clarifies implicit / AI-driven decisioning.

Adding on progressive disclosure to this is brilliant, and I love the idea of a fast, in-memory, single-binary tool. This is a great way to approach the solution to this problem.

One thing I will say though - I would never be able to use this in my enterprise. It would just be too much of an uphill battle to purchase something that is so niche in utility - this tool is not a ton different than just having the md files locally and having it use ripgrep to search over them, and telling CLAUDE to write the OKF files as well as an index when it makes changes, is it? is the index generated dynamically / is anything about the progressive disclosure different than just having the agent manage it while it documents?

If you're going for smaller teams that can buy tools without a ton of approval / procedural overhead, I think that might have some success. another possible solution would be to make the cross-repo search something that you can handle with OSS but you have to self-host, and then pay for support. if you got enough usage and penetration within an enterprise from the teams just using OSS and self-hosting, they might consider buying support after-the-fact.