Every morning for three months, I re-explained myself to my coding agents.
The same preferences. The same project structure. The same "no, we already tried that" conversation. Fresh context window, zero memory of anything we'd discussed before.
Then I built Lorekeeper — an open-source memory layer for AI agents. Fixing the storage problem was the easy part. The hard part was making memory get better over time. Not just fuller. Sharper. Less noise.
The approach that surprised me: let the agent reflect on its own memory when it's not busy.
The bucket problem
The first version was dumb storage. You save a memory, you find it later.
memory.insert("user prefers snake_case for Python, camelCase for TypeScript")
memory.search("naming convention")
# → ["user prefers snake_case for Python, camelCase for TypeScript"]
After a few weeks you've got hundreds of memories — old decisions you reversed, half-thoughts that went nowhere, conventions that changed three refactors ago. The useful stuff drowns. The more you save, the worse retrieval gets.
We tested against other systems and found recall dropped from ~80% to ~40% after just 200 stored memories. Storage without maintenance isn't memory — it's a junk drawer.
Night shift
Lorekeeper uses a cron-based scheduler. Every few hours, when your agent isn't working, it runs a reflection cycle:
[03:15] lorekeeper: reviewing 347 active memories
[03:15] lorekeeper: 12 memories have low utility scores (≤ 3.0)
[03:15] lorekeeper: 3 memories are near-duplicates (similarity ≥ 0.92)
[03:15] lorekeeper: merging "prefers async/await" + "team uses async for I/O"
[03:15] lorekeeper: archiving "old approach used callbacks" (unused 47 days, score 1.2)
[03:15] lorekeeper: done — 12 pruned, 3 merged, 1 archived (331 active)
Each cycle scores every memory by usefulness, merges duplicates, archives dormant noise, and links related facts. All on your machine, using your API key, with your auth.
# ~/.config/lorekeeper/cron.yaml
schedule: "0 */6 * * *"
actions:
- score_memories
- merge_duplicates
- archive_dormant
- link_related
I call this local dreaming — the agent reflects and consolidates during idle time, the way your brain processes the day's experiences while you sleep.
What this looks like after six weeks
| Week | What happens |
|---|---|
| 1 | Sparse but accurate. Every retrieval hits. |
| 3 | Growing fast. Some noise creeping in. Retrieval less reliable. |
| 5 | Feedback loop has stabilized. Noisy memories pushed down. High-value ones float up. Better than week 3 with 3x the volume. |
The benchmarks: 84.6% Recall@1, 96.6% Recall@5, 32.9ms average latency on LongMemEval-S with a local 384-dim embedding model. Zero data leaves your machine.
The unexpected part
The dreaming cycles don't just prune noise. They surface connections I hadn't made. Last week it linked my error-handling middleware memory with an API versioning convention — 0.81 cosine similarity. I confirmed the link, and now pulling one surfaces the other.
A static memory store can't do this. A cloud service won't see the connections in your project. A local agent that reflects on its own memory can.
Services like Letta use server-side scheduling for dreaming — their infra, their LLM calls. Valid approach. We took a different path: local by default, cloud optional, always on your API key.
pip install lorekeeper-mcp
mcp-server setup
# dreaming starts automatically via cron
The repo is github.com/jessira/lorekeeper, Apache 2.0.
Have you noticed your coding agent repeating itself across sessions? The same approach it already tried, the same pattern you already rejected? Drop a comment — I'd love to hear how you handle it.