DEV Community: Jessin Ra

A notebook remembered more about me

Jessin Ra — Sun, 21 Jun 2026 14:42:46 +0000

Last weekend I was cleaning out a closet and found a notebook from 2017.

It was one of those black Moleskines with the elastic band. I remember buying it at an airport. The pages were curled at the edges. I'd shoved it in a backpack for years and the spine was cracked.

I sat down and flipped through it.

There was a camping trip I'd completely forgotten about. A startup idea scrawled across two pages with a diagram that must have made sense at 2 AM. A friend's phone number I didn't recognize anymore. A shopping list. The name of a restaurant I wanted to try.

Reading it felt like time travel. I wasn't just reading words — I was back there. I remembered the coffee shop where I wrote that startup idea. I remembered the rain on that camping trip. The notebook didn't just store information. It stored context.

That's when it hit me.

I'd spent the last few months building AI agents that couldn't remember anything from one session to the next. Every morning, fresh reset. I'd tell them my stack, my preferences, my project structure. And by the next conversation, it was gone. I was living in Groundhog Day, and I was the only one who knew it.

But here I was, holding a $15 notebook that did everything my AI agents couldn't.

The way memory actually works

My notebook works because it has layers.

Start with time. Most pages have a date. That means I know when things happened, not just what happened. The startup idea from 2017 only makes sense if you know what I was doing back then. Without the date, it's just noise.

Then context. The camping list is right next to the work notes. That's how life works. Things overlap. The notebook doesn't try to separate them into neat folders. It just captures what happened, messy and real.

And then there's forgetting. That phone number I didn't recognize? I don't need it anymore. The shopping list is irrelevant. Some stuff matters, some stuff mattered once, and some stuff never mattered at all. And that's fine, because the useful stuff is still findable.

The real trick? The notebook captures what happened. Not what someone thought I'd need later. It's a record of reality, not a prediction of usefulness.

What this means for AI agents

Here's the thing about most agent memory systems: they're built like a hard drive, not a notebook.

Everything goes into one bucket. There's no sense of time. Or rather, there's only "right now" and "everything else." No layers. No context. Nothing that connects last Tuesday's debugging session to what you're working on today.

And the forgetting is all or nothing. Either the system remembers everything (choking on noise) or remembers nothing (resetting every session). That middle zone — the functional forgetting that lets you find what actually matters — barely exists.

I realized the architecture I needed was staring at me from that coffee-stained Moleskine.

Time layers first. Memory isn't flat. Things from last week are more relevant than things from three months ago. And things that happened while you were working on an auth bug are more relevant when you're back in that auth code. That's how I naturally think about my own work: "the problem from last sprint" vs "that thing from a year ago."

Context around content. What you were doing when you said something matters as much as what you said. If you mentioned your API keys while debugging auth, the agent should surface that memory in auth contexts. Not randomly during a billing discussion.

Letting go on purpose. Not everything needs to be saved. Not everything that's saved needs to stay forever. The art isn't storing more data. It's knowing what to keep and when to let it fade.

What it feels like now

I won't get into the technical architecture here (that's a different post). But I built this into something called Lorekeeper, and the difference is night and day.

I start a session now and my agent knows what I was working on last time. Not from a system prompt I copied and pasted. It actually remembers. Really remembers.

Last week I was debugging a Redis connection issue. I came back to it three days later. Context switch, meetings, the usual chaos. And my agent picked up exactly where we left off. It knew the error message, the config file we'd been inspecting, even the theories we'd ruled out.

That's the notebook experience. It doesn't feel like AI magic. It feels like working with someone who actually pays attention.

The thing I keep thinking about

I spent months looking at this as a technical problem. Vector databases, attention mechanisms, embedding strategies. All of that stuff has its place.

But the real breakthrough came from a $15 notebook I bought at an airport.

The best memory system already exists. We've been using it for centuries. We just forgot to look at how our own brains actually work before we started building one for our AI agents.

So here's my question: what else are we overcomplicating because we haven't stopped to look at the simpler version that's already working?

If this resonated, Lorekeeper is open source. I'd love to hear what you're building.

I stopped trying to make my AI remember everything. That's when it got good.

Jessin Ra — Sat, 20 Jun 2026 01:43:51 +0000

My grandmother has trouble remembering what she ate for breakfast. But she remembers my birthday. She remembers every grandchild's name. She remembers stories from forty years ago like they happened yesterday.

Her brain figured out what matters.

I used to think AI memory should be a perfect recording. Every conversation saved. Every detail searchable. Total recall.

I was building it wrong.

I've been working on Lorekeeper — an open-source memory system for AI agents. It started as a storage problem. How do I keep everything?

But storage isn't the hard part. The hard part is knowing what to keep.

Think about your own brain. You don't remember everything. You remember the important stuff. The conversations that mattered. The mistakes you learned from. The names of people you care about.

Everything else fades. That's not a flaw. That's the design.

I built a feedback loop into Lorekeeper. Every time an agent uses a memory, it can say "this was useful." The stuff that gets used stays. The stuff that doesn't fades.

I set it up, walked away, and forgot about it.

Two weeks later I asked my agent about a debugging session we'd had. A random import issue from weeks ago. I had completely forgotten about it.

My agent remembered. Not because I had saved it perfectly. Because over two weeks, across multiple sessions, that specific memory kept being useful. The system promoted it naturally.

It felt like running into an old friend who remembers something about you that you'd forgotten. That surprise of being known.

That's the thing nobody tells you about building AI tools.

The goal isn't perfect memory. The goal is to know what matters.

A system that remembers everything is like a closet so full you can't find anything. A system that forgets the right things is like a well-worn bookshelf — the books you actually reach for are right at eye level.

I spent months optimizing how much my agents could store. The real breakthrough was teaching them what to let go.

Lorekeeper is open source (Apache 2.0). pip install lorekeeper-mcp if you want to try it.

Star the repo if this resonates. Helps me know I'm not the only one thinking about this. It means a lot to me, thank you!

My AI agents spend 10 minutes every night rewriting their own memory.

Jessin Ra — Tue, 16 Jun 2026 14:34:34 +0000

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.

[NEW] I spent 3 months teaching AI agents my codebase. They forgot by morning. Every. Single. Day.

Jessin Ra — Sun, 14 Jun 2026 16:19:38 +0000

Every morning for three months, the first thing I did was re-explain myself to my own tools.

Not the code. The code was fine. I mean everything around it: what we'd decided last Tuesday, why we'd ruled out that approach, what the sprint was actually about, how we structured things and why. The context that makes work feel continuous instead of like starting a new job every 24 hours.

Then one afternoon it tipped over. I watched my agent propose — in detail, with genuine confidence — the exact API structure I'd shot down two weeks earlier. Same reasoning, same blind spots. It had been part of our conversation. It just didn't remember.

I closed my laptop and took a walk.

This is my first time writing about this publicly, so bear with me.

Some context: I'm a backend engineer, about six years in, currently at one of the big tech companies. A few months before all this, leadership had decided we were going all-in on AI coding tools. The memo used words like "operational efficiency" and "headcount optimization." What it meant was: do more with less, and here's a tool to help you justify that.

And look — the tools earned it. Claude Code genuinely impressed me. Real code, fast, often better than what I'd have written in the same time. But there was a cost nobody had put a name to yet.

Every session was a first date.

Twenty minutes of re-orientation, then maybe an hour of flow, then the context window starts creaking and you're watching your agent lose the thread. Every. Single. Day. The productivity gains were real, but so was this invisible overhead. And it kept adding up.

I looked for solutions. CLAUDE.md and .cursorrules work great — until they don't. After a couple of months you've got a file full of contradictions and outdated decisions, and nobody's sure what's still true. Cloud memory products want a monthly subscription and your data on their servers. The self-hosted options I found felt like deploying actual infrastructure just to solve a workflow problem.

None of it did what I wanted. I didn't want a bigger context window. I wanted something that built an understanding of how I work and got better at it over time. Like a colleague who's been on the project for six months, not a contractor reading onboarding docs for the first time.

I couldn't find that. So I started building it.

The first version was a bucket. You save something, you find it later. Simple.

It worked, until it didn't. After a few weeks I had hundreds of notes and the useful ones were drowning in noise — old decisions I'd reversed, half-thoughts that never went anywhere, preferences I'd changed my mind about. The more I saved, the worse retrieval got. Exactly backwards.

Then I noticed something. When I watched the agent pull memories, it kept surfacing the same handful of things — and ignoring most of the rest. The stuff that was actually helping me kept getting used. The noise sat untouched.

That observation took me a while to act on. But when I did, it changed how the whole thing worked.

I built a feedback loop. Every time a memory gets retrieved, it gets rated — did this actually help? Useful ones score higher. Ones that get pulled but don't contribute start to sink. After enough misses, they quietly disappear. The system doesn't just grow. It filters itself.

Six months after that first painful afternoon, the tool I'm using every day barely resembles the bucket I started with. It's not just fuller. It's sharper — the things I verified last month sit higher than a passing thought from week one, and dead ends clean themselves up without me manually pruning anything.

Most of the rest came from things annoying me until I fixed them.

I added a dashboard when I couldn't tell what was even in the store. Auto-linking when I realized related memories should find each other — if I save something about our API conventions and something about our error-handling patterns, those should probably know about each other. Namespaces when I started running multiple agents and they kept stomping on each other's notes.

Nothing was planned. Every feature has a specific frustration behind it.

The benchmarks are decent — 96.6% recall in the top 5 results, 84.6% on the first result, at 33ms on an open-source embedding model anyone can run locally. No cloud, no proprietary model, no ongoing fees. But the number I actually track is simpler: does a session today feel better than a session from six months ago? Yes. A lot better.

One thing I didn't expect: the agents helped build it.

The same tools I was building memory for were also my primary collaborators building it. When search came back noisy, we tuned the weights together. When the tool schema felt clunky, they complained about it through how they used it — wrong calls, workarounds, weirdly phrased queries — and we fixed it. The product got shaped by the things that were breaking for them.

I still think that's a little strange. But it worked.

It's called Lorekeeper. Apache 2.0, runs locally.

pip install lorekeeper-mcp
lorekeeper setup
lorekeeper

Tell your agent to remember something. Come back tomorrow and ask for it. Then come back in a month and notice how differently it finds things.

That's the test I actually care about. Not the benchmark number — the feeling of working with something that knows your project. That's what I was trying to build when I took that walk.

Give it a try. See if it sticks.

GitHub: https://github.com/Jessinra/Lorekeeper
Docs: https://jessinra.github.io/Lorekeeper/
Apache 2.0. Built by agents, for agents.