okf-agent-memory: Git-Native AI Agent Memory Built on Google's Own Open Standard

A repository created on September 5, 2026 passed 590 stars a week later, still gaining daily. okf-agent-memory is a git-native AI agent memory system for coding agents, and what separates it from the growing pile of "agent memory" tools isn't the star count. It's that the format it stores memory in isn't invented by the maintainer. It implements version 0.2 of the Open Knowledge Format, a specification Google Cloud published for representing organizational knowledge as portable, linked Markdown files.

That distinction matters more than it sounds like it should. Most agent memory tools this site has covered pick their own storage shape: a custom JSONL index, an encrypted vector store, a hand-rolled context file format. okf-agent-memory instead builds git-native AI agent memory on top of a spec someone else already published and is maintaining independently of this one project, which changes the honest answer to "what happens to my memory files if this maintainer stops updating the tool."

What okf-agent-memory actually does

okf-agent-memory is a single Go binary with zero external dependencies, no database, no cloud account, and no API key required to run. Once built with make build, it stores an agent's accumulated project knowledge as plain Markdown files with YAML frontmatter, organized under a knowledge/ directory that lives directly inside your git repository. Every memory entry is a real file. It gets committed, diffed, branched, and reviewed the same way source code does, because as far as git is concerned, it is source code.

Retrieval runs on an in-memory BM25 index, the same ranking algorithm behind most traditional full-text search engines, rather than vector embeddings. The maker's stated benchmark is sub-300 microsecond query latency, and because BM25 is lexical rather than semantic, there's no embedding API to call, no per-query cost, and no network round trip standing between the agent and its own memory. That tradeoff cuts both ways: lexical search finds exact and near-exact term matches fast and cheaply, but it won't catch a conceptually related memory phrased in completely different words the way a semantic vector search sometimes can.

The mechanics: search-before-write and progressive disclosure

Two design choices in okf-agent-memory are worth understanding before adopting it, because they shape what using it day to day actually looks like.

The first is what the project calls the Search-Before-Write Principle: an agent is expected to query existing memory before authoring a new entry, specifically to prevent the same concept getting written down twice under slightly different names. This is enforced through the tool's own workflow rather than bolted on afterward, and it's a real answer to a failure mode that shows up in less disciplined memory systems, where an agent's knowledge base slowly fills with near-duplicate notes that all drift slightly out of sync with each other.

The second is progressive disclosure, implemented through hierarchical index.md files and a link graph between memory entries. Rather than an agent loading an entire knowledge base into context every time it needs one fact, it loads a top-level index, follows a link to the relevant section, and pulls only the specific concept it needs. The project's own framing is an 80% reduction in token usage compared to re-reading a full context dump, though that figure is the maintainer's own claim rather than an independently benchmarked one, and how much it actually saves will depend heavily on how large and how organized a given project's knowledge base gets.

Setup and what using it looks like

Installation currently requires building from source: cloning the repository and running make build, which produces a standalone okf binary. There's no packaged installer or one-line curl script yet, which is a real friction point for anyone who isn't comfortable with a Go toolchain, though the zero-dependency design means once it's built, it runs anywhere without further setup. The CLI exposes validate, search, create, update, and bootstrap commands for direct use, alongside an embedded MCP server that wires the same operations into Claude Code, Cursor, or any other MCP-capable agent as tool calls the agent invokes on its own mid-session.

In practice, a project adopting okf-agent-memory ends up with a knowledge/ folder sitting next to its source code, readable in a plain text editor, version-controlled the same way everything else in the repo is, and queryable by both a human running okf search from the terminal and an agent calling the same function through MCP without a human in the loop. That's the core pitch of git-native AI agent memory over other approaches: the memory isn't a separate system you have to back up, sync, or trust a third party's server with. It's just more files in your repo.

Who this fits and who it doesn't

okf-agent-memory is aimed at teams and solo operators running Claude Code or a similar agent daily on a real codebase, who want memory that survives a session ending without adopting a new piece of infrastructure to do it. Because everything lives as Markdown in the repo, it also fits teams that already review changes through pull requests: a new memory entry is a diff like any other, which means it can be reviewed, rejected, or corrected the same way a code change would be.

It's a worse fit for anyone wanting semantic recall across loosely related concepts phrased in very different language, since BM25's lexical matching won't bridge that gap the way an embeddings-based tool can. It's also a young project. One week old, MIT licensed, actively developed with 40 forks and open issues already accumulating, but without the track record or third-party scrutiny a tool needs before being trusted with genuinely sensitive project knowledge. And because setup currently requires compiling from source, it asks more of a first-time user than a tool with a packaged installer would.

The bigger signal here isn't really about this one project. It's that Google Cloud publishing an actual open specification for agent knowledge, and an independent maintainer shipping a working implementation of it within days, suggests agent memory is heading toward the same place file formats and protocols eventually go: a shared, boring standard everyone builds against, rather than a dozen incompatible proprietary formats competing for the same job.

Sources: okf-agent-memory on GitHub, Open Knowledge Format specification, Google Cloud Platform.