memweave: agent memory that git-diffs, no vector DB required

memweave, an open-source Python library from Sachin Sharma, showed up on Towards Data Science this week, pitching itself as zero-infra agent memory — no Pinecone, no Weaviate, no managed vector database. Just a folder of markdown files and a SQLite index. The timing is interesting: most agent-memory infrastructure on the market has been chasing scale — vector stores, graph databases, distributed embeddings — while most agents in practice don't need scale. They need persistence, inspectability, and a retrieval signal that doesn't embarrass itself on exact-match queries. memweave is betting the default has been wrong.

The architecture is three moving parts. Markdown files in a folder are the source of truth, readable and writable by both humans and agents. SQLite holds a derived index with FTS5 for BM25 keyword matching, the sqlite-vec extension for SIMD-accelerated embedding similarity, and an embedding cache keyed by SHA-256 of content so rewrites don't trigger redundant API calls. Retrieval is hybrid by default at 0.7 × vector plus 0.3 × BM25, followed by MMR re-ranking for diversity. Temporal decay down-weights older memories based on file age, with evergreen files (no date prefix) aging differently from dated ones like YYYY-MM-DD.md. Agent namespaces come from subdirectories. The readme links runnable notebooks — a book club demo and a meeting notes agent — but no published benchmarks, which is worth flagging: the library is new and unproven at scale.

Underneath the library is a real argument about what agent memory actually needs. Most agents operate over thousands of entries, not millions; SQLite plus sqlite-vec handles that with no network hop. The hybrid BM25+vector default is also probably correct: embeddings alone miss exact-match cases like "what is my API key for Service X" where the user literally wrote the string; BM25 alone misses semantic phrasing. But the operational wedge is the one to pay attention to: running git diff memory/ shows what the agent learned between runs, commit-by-commit. That is a debugging primitive no vector database gives you, and it is exactly what you want when you are trying to reconstruct why an agent made a specific decision at 3am. Version control as a first-class operation over memory, not an afterthought bolted on via database exports.

The pattern is copyable even if the library itself isn't the right fit. For any agent whose memory is not fundamentally at million-entry scale — which is most agents developers actually ship — the template worth stealing is: treat a folder of markdown as the source of truth, derive an index that can be rebuilt from scratch at any time, hybrid retrieval instead of pure vectors, and version-control the memory so you can audit what changed. The honest caveat: at the scale where vector DBs genuinely earn their keep — massive document corpora, multi-tenant production with millions of per-user memories — this approach probably breaks, and the author has not run the benchmarks to show the failure mode. For personal agents, research agents, internal tooling — the boring-but-real majority of what gets built — the lo-fi pattern is the right starting point. Read the two notebook demos, decide if it fits, and steal the idea regardless.