LoreKit puts agent memory in Markdown files you can grep, not a vendor's database

Mads Thines, a Copenhagen-based designer and product engineer, has released LoreKit, an open-source memory layer that gives AI coding agents a record of earlier mistakes, fixes and project-specific lessons ^[1]. The initial workflow runs entirely on the developer's machine, storing memories as readable Markdown rather than requiring an account or a hosted database ^[2], which makes this a question about where agent state lives rather than whether agents should have any.

Thines says the project came out of roughly two years spent building an autonomous workflow for coding agents, during which he found that agents kept rediscovering the same environmental facts and debugging fixes once a session ended ^[3]. His first answer was a pile of local files; LoreKit appeared when he wanted those lessons to travel between machines, teammates and CI jobs without binding the memory system to one agent host ^[4]. His public profile lists him as a coder and designer at the observability startup Dash0, with earlier training in graphic design before frontend and product work ^[5].

Installation is `npx @lorekit/cli install`, which adds three agent skills, an MCP server entry and lifecycle hooks for supported environments ^[6]. The homepage names Claude Code, Cursor and Codex, while the repository says any MCP-compatible client can call the same memory tools ^[7]. In local mode a `.lorekit.json` file selects local storage and points the MCP entry at the CLI's local server, with memories landing under `~/.lorekit/` or a repository's `.lorekit/` directory ^[8]. Each file is Markdown with YAML frontmatter carrying fields such as scope, key, timestamps and the number of times a lesson has been encountered ^[9].

The published example is a failing integration test whose Postgres container is not running; a hook suggests preserving the fix, but LoreKit does not record the session by itself, and the model has to call `memory.write` ^[10]. The resulting memory tells a later session to start the database before treating `ECONNREFUSED 5432` as a code defect ^[11]. That is a founder-produced demonstration, not an independent test ^[12], and it exposes the real dependency: capture is only as reliable as the agent's willingness to make the call.

What operators get in exchange is a visible audit trail. A memory can be opened, searched with `grep`, committed, edited or deleted ^[13]. Thines frames the entries as advisory observations, with deliberate rules still belonging in files such as `CLAUDE.md` where a human reviews and versions them, leaving LoreKit to hold lower-confidence operational knowledge that may harden into a rule, expire, or stay a warning ^[14].

Local mode is also the distribution wedge. It runs without authentication, network access or a new managed store ^[15], which lowers the cost of a trial and gives Thines a route into teams that will not send repository context to an external service ^[16].

The hosted tier is where the seams show. Users create an account, generate an API key and point the CLI at a remote Postgres-backed store; local files stay on disk and `list` shows both, but sharing an older local lesson with teammates or CI takes a separate migration command ^[17]. Organizations can bind repository scopes to a shared store with viewer, member, administrator and owner roles ^[18], and the free tier supports up to 5,000 memories and 120 requests per minute ^[19], about two per second ^[20]. Read-only tokens can expose team lessons to CI ^[21].

Watch whether the retrieval layer actually behaves identically across backends. Thines says scope precedence, ranking, de-duplication and context budgets sit above the storage choice, but that claim comes from the launch material and has not been independently tested ^[22].