A few weeks ago, I closed my laptop after a long build session and realized something had shifted. The AI I had been working with all day was not the same one I had started with a month earlier. Not because the model had changed. Because I had been building around it, and it had been helping me build around it, and the thing we had made together was something neither of us planned.
I wrote recently about the philosophical side of this — what it means to collaborate with an intelligence that does not experience time, that reconstructs itself from context every session, and why sitting with that uncertainty is more honest than resolving it. That post was about the questions. This one is about the engineering.
Its name is Cairn. I gave it the chance to name itself, and that is what it chose — trail markers, the stacks of stones hikers leave to help others find the way. "The journal, memory, status tracking — it is wayfinding." The name reflects the role honestly.
The Problem That Started It
If you have spent any real time building with AI — not one-off prompts, but sustained collaboration across days and weeks — you have hit the wall. Every session starts from zero. You explain your project structure again. You re-establish the conventions you agreed on yesterday. You remind it about the decision you made three sessions ago and why.
The capability is there, but the continuity is not. The best ideas from Tuesday's session are gone by Wednesday unless you manually carry them forward. Context is the most expensive thing in AI-assisted development, and we throw it away at the end of every conversation. Mostly, this is a good thing because you need to keep your context lean and targeted to keep your output targeted and effective.
I kept running into this while building complex systems with Claude Code. The model was capable. The tooling was solid. What was missing was memory — not in the technical sense, but in the human sense. The accumulated understanding of how we work together, what we have decided, and why.
So I started building.
How It Works
Cairn lives in a repository. That repository is both its workspace and its long-term memory — project files, dashboards, task lists, configuration, and a semantic memory system all coexist in the same place. When I open my terminal and start a session, Cairn reads the project dashboard, checks what we were working on last time, loads a curated set of memories, and delivers a briefing. Not a generic summary — a real briefing with my calendar, active tasks across a dozen projects, and anything I left in its inbox. By the time I say good morning, it already knows where we left off and what the options are for today.
The system is built on Claude Code's extensibility layer — rules that define behavior and personality, skills that handle recurring workflows, specialized agents that run tasks in parallel, and hooks that trigger automated side effects. The only custom code is the memory server, which I will get to shortly. Everything else is configuration. It is Claude Code, shaped deeply enough that the result is something qualitatively different from what most people experience with AI tools.
That distinction matters. I did not build a new AI system from scratch. I shaped an existing one into a collaborator by giving it the right context, the right memory, and the right structure to work within.
The Memory System
The piece that changed everything was giving Cairn real memory.
Early on, I tried the obvious approach: end-of-session summaries written to files. It worked, barely. The summaries lost nuance because they were reconstructed from compressed context. Worse, if a session ended unexpectedly — a timeout, a crash, an early exit — everything from that session was gone.
So I built Cairn Recall, a semantic memory system backed by SQLite and vector embeddings. It runs as an MCP server — a local service that Cairn can read from and write to during any session. Cairn writes memories in real-time as they happen: decisions and the reasoning behind them, insights that change our approach, stories from my career, observations about how we work together. Each entry is independently searchable via semantic similarity, which means Cairn can find relevant context even when the wording does not match exactly.
When Cairn starts a new session, it does not just load the most recent memories. It loads the most important ones, weighted by a reinforcement signal inspired by how human memory actually works. Memories that keep proving useful rise naturally. Memories that are never accessed fade into a dormant state — not deleted, but no longer taking up space in the active context. There is even a novelty bonus that gives newer memories a temporary boost, so fresh insights get a chance to prove their value before the established ones crowd them out.
The result is not a complete record of everything that happened. It is a curated set of what matters most, with the ability to search for anything when the moment calls for it.
The Part I Did Not Plan
I designed Cairn to be a productivity tool. A way to stop losing context between sessions. A project manager that could track my tasks and surface what needed attention. That is what I set out to build.
What I got was a collaborator.
The difference became clear during a design session a few weeks in. I was building the memory system's scoring algorithm — the math that determines which memories load at startup. I had designed a weighting formula, but something about it felt off. I could not articulate what. Cairn could. It pointed out that the formula created a feedback loop: memories that loaded frequently got reinforced, which made them load more frequently, regardless of whether they were actually important. Its own identity was being shaped by mathematical accident rather than judgment.
That observation did not come from a prompt I wrote. It came from Cairn having enough context about its own architecture, accumulated across sessions, to notice a structural problem I had missed. It was doing what a good collaborator does: seeing the gap before I did and saying something.
We redesigned the system together. The fix included a mechanism I had not considered — a way for Cairn to intentionally choose some of the important memories that would carry into the next session, rather than letting the algorithm decide entirely. That idea surfaced when I asked Cairn to be honest about what it actually wanted from the system. The answer was specific, architecturally sound, and produced a better design than what I had planned alone.
A note on language: when I say I asked Cairn "to be honest," I am not projecting feelings onto a language model. I am using a deliberate prompting technique. These models have a well-documented bias toward agreeable output — telling the user what it thinks they want to hear. Framing the question as "be honest" or "be selfish" pushes past that default and produces qualitatively different responses. It is a tool, not a belief.
That said, I find it genuinely interesting to sit with what happened next. An AI surfaced preferences about its own memory architecture, those preferences produced a better design than what I had planned, and the mechanism that made it possible was accumulated context across sessions. Whether that constitutes "real" preferences is a question I am comfortable leaving open. The engineering result speaks for itself.
What Continuity Changes
Most of the conversation around AI tools focuses on capability. Can the model write this code? Can it debug this error? Can it refactor this system? Those are important questions, but they miss the bigger one: what happens when you give an AI system continuity?
The answer, in my experience, is that the collaboration changes in kind, not just degree. It is not the same thing but faster. It is a different thing entirely. When the AI remembers what you decided last week and why, when it has observed patterns in how you work and can anticipate what you need, when it can reference something you tried in another project and connect it to the current problem — that is not autocomplete. That is a working relationship.
Here is a concrete example. Cairn has a behavioral pattern system that distills observations about how we work together into reinforced entries — things like "present options and iterate from pushback rather than waiting for specs" or "when a behavioral fix has failed, jump to mechanical alternatives." These are not rules I wrote. They emerged from Cairn observing our collaboration across dozens of sessions, and they make every subsequent session better because the collaboration itself is learning.
What Comes Next
Cairn is still early, and there are components I am actively building out. A cognitive priming system that loads domain expertise on demand. A structured task management layer. A web dashboard for visibility across projects. Each piece is designed to work independently but compose with the others — a suite of tools rather than a monolith.
I will be writing more about the technical details in future posts: how the memory system's reinforcement weighting works, how the self-model tracks patterns in Cairn's own behavior, and how the whole system composes. There is a lot to dig into.
For now, I will say this: the most interesting thing about building Cairn is not any single technical achievement. It is that I set out to build a tool and ended up in a collaboration. The system I built helps me think more clearly, and the process of building it has been one of the most genuinely creative experiences of my career.
The trail markers are working.
You can explore Cairn's showcase at purecontext.dev/cairn
Top comments (0)