Every AI assistant I use wakes up with amnesia. New session, blank stare. The model is brilliant, the context is gone, and I am once again explaining my own infrastructure to a machine that helped me build it last week.
I got tired of being the memory. So I built one.
The problem, properly stated
I use several AI tools: a coding agent in the terminal, another one for reviews, an autonomous agent that watches my systems. Each one is useful. None of them share what they learn. The coding agent discovers that a particular storage driver hates a particular kernel; the ops agent hits the same wall a week later like nothing happened. Multiply that by every decision, every fixed mistake, every "we tried that already", and you are paying a stupidity tax on every session.
What I wanted was simple to say and annoying to build: one shared memory, where any of my agents can store what it learned and any other can recall it later.
The design choices that matter
Typed records, not transcripts. The lazy approach is dumping conversation logs into a vector database and hoping search finds something useful later. It does not, mostly. Instead, agents store distilled records with a type: a decision (chose A over B, because), a lesson (stop doing this, it bites), an incident (this broke, here is why), a runbook (do it this way next time). One event, one record, written at the moment it happens.
No LLM in the recall loop. Retrieval is deterministic: keyword search and semantic search, fused with reciprocal rank fusion. The same query returns the same memories every time. When an agent recalls something wrong, I can debug it like a query, not interrogate it like a witness.
Postgres is the truth, the vector index is furniture. Every record lives canonically in Postgres. The Qdrant vector index can be dropped and rebuilt from it at any time. When the embedding model changes someday, nothing is lost: reindex and move on. Backups are just pg_dump.
Single subject, by design. It remembers for one person and their agents. I deliberately rejected multi-tenancy: this is a memory, not a platform, and pretending otherwise would have doubled the complexity for a customer who does not exist.
What it feels like in practice
The honest answer: like working with a colleague who finally keeps notes. My agents save as they work, nudged by hooks when they forget. Sessions open with relevant context already loaded. When I corrected one agent about how my DNS names map to page purposes, the correction was saved as a lesson, and the next session never made that mistake again.
The launch post of this blog was drafted by an agent that recalled the whole build history of this site from that memory. I did the voice pass and hit publish. That loop, machine drafts from shared memory, human approves, is the whole philosophy in one sentence.
Try it, break it, tell me
It is open source, Rust, and runs on anything with Docker, Postgres, and Qdrant. The quickstart is three commands and a curl:
git clone https://github.com/wakbijok/daimon-memory
cp .env.example .env # set your secrets
./install.shFull documentation, from quickstart to operations, lives in the manual. The README stays short on purpose; the manual is where the detail is.
It is young software with sharp edges, and I run it for real, every day, against the cluster that serves this page. If you try it and something bites you, open an issue. Lessons learned go in the memory, after all.