Plain vector search finds memories that sound like the question. Here the pipeline extracts cues from the query, walks the graph edges from those cues, then expands one more hop through associated memories — so a memory sharing an entity rather than a phrasing is still reachable. The consolidation pass is the other half: memories nobody recalls decay away, which is what stops a long-lived store turning into noise.
A memory server that stores each memory as a node in a property graph, linked to the cues extracted from it and to other memories. Retrieval combines cue matching, graph traversal and vector similarity; a background pass decays and re-clusters what is stored.
- smriti_store — save a memory with an importance value, tags and a source label; the content is analysed, embedded and linked into the graph automatically
- smriti_recall — retrieve by natural-language query, in three modes: the full multi-hop pipeline, a fast vector-only search, or a plain browse of recent memories
- Retrieval can be filtered to episodic, semantic or procedural memories
- smriti_manage — delete a memory, or push a backup
- Recalled memories are reinforced, so what gets used surfaces more readily and what does not decays away
- Three graph database backends, one of them embedded with no separate server to run, and per-user isolation on all of them
- Optional backup to a git remote or to object storage
A local build with a Go toolchain and a C compiler, or one of the published container images and release binaries. A language model and an embedding provider are required — any OpenAI-compatible endpoint works, including a local one. The external graph databases are only needed if you pick one over the embedded backend.
Build from source — clone the repository and build it, then point your client at the binary