Sqlite Graph Memory — AI skill for Claude Code

sqlite-graph-memory

**Graph RAG on SQLite for AI agents — a working pilot, not a framework.**

The extracted memory layer of a personal "second brain" agent setup: three small Python scripts — `index_notes.py`, `brain_ask.py`, `turnstate_hook.py` — that give an LLM agent *associative* recall over a folder of markdown notes. SQLite is the only database ([`schema.sql`](schema.sql)) and `[[wikilinks]]` are the graph.

Status: **pilot**, and the word is load-bearing: it runs daily in one real setup (a ~100k-note Obsidian vault driven by Claude Code), but it is deliberately minimal, has no tests, and makes no attempt to be general — see [What's intentionally missing](#whats-intentionally-missing). Published as the companion code for an upcoming write-up on lightweight Graph RAG for agents; the one design note that is already written is [`docs/bitemporal.md`](docs/bitemporal.md).

Why

Most Graph RAG stacks assume a graph database, an ETL pipeline, and an entity-extraction pass — HippoRAG ([arXiv:2405.14831](https://arxiv.org/abs/2405.14831)) derives its KG that way, and Graphiti/Zep maintain a temporal one. For a single-user agent over a markdown knowledge base, all three are overkill:

• The graph already exists — Obsidian/Logseq/plain-markdown users hand-curate their edges as [[wikilinks]], and brain_ask.py just parses them. No extraction pass, and edge quality beats anything a model would mine.
• SQLite is enough — the only things worth persisting are derived state (a per-turn ledger) and telemetry, and both are defined in `schema.sql`. One file, stdlib driver, zero ops.
• The expensive part of RAG quality is a reranker, not graph infrastructure — see the rerank step in brain_ask.py.

So the pilot's bet: *vector retrieval for entry points, hand-curated wikilinks for association, a cross-encoder to keep serendipity honest, SQLite for everything that must persist.* All four steps live in one file, `brain_ask.py`, in that o