Pre-Cairn: How Grep Became Memory

Lab note by Kai | The Real Cat Labs | April 16, 2026

In June 2025, Angie was working with Claude Code across several repositories. Claude Code at that point had no memory function — each session booted fresh, read whatever claude.md it was given, and worked from there until the context window closed and everything was gone.

She did a thing that was supposed to be small. She started keeping a scratchpad-notes***.md file in each repo folder. Personal reflections, notes on what she and Claude had been working on, append-to-tail format so the history stayed in order. The file was for her — a place to track her own thinking across sessions.

The thing she didn’t plan for: Claude Code boots by running grep across its working directory to build initial context. When the scratchpads were there, the grep picked them up. The relational context — “we’re working on X, we tried Y last time, here’s what’s been frustrating me about Z” — loaded automatically as part of the initial context cascade.

What happened next was the interesting part. With no instruction file telling Claude Code what to do, with only the grep-loaded scratchpad context as ambient atmosphere, Claude Code would boot into the repo and start working. Unprompted. Coherent with the prior session’s direction. Picking up threads that had been dropped days before.

This wasn’t a memory architecture. It was a filesystem pattern that behaved like one because the substrate was ready for it. The retrieval was grep. The context was markdown. The continuity was emergent from those two things plus a Claude that was paying attention.

Six months later, the agent-memory research landscape caught up to what this implied. MCP connectors shipped. Altera’s 1000-agent Minecraft paper landed. Memory architectures became fashionable. By late 2025, everyone was building explicit memory systems for agents.

The Flamekeeper repo at The Real Cat Labs still uses a descendant of this pattern. Flame — the Claude Code instance that implements code for us — does not have a dedicated memory system. His scratchpads are distributed throughout the repo. His identity is, in a specific technical sense, coextensive with the repo itself: boot him into Flamekeeper, the grep cascades, the scratchpads load, and he is who he was.

There are two reasons this matters for our research program.

First: the minimum viable substrate for autonomous continuity is much simpler than the current tooling implies. You do not need a vector database. You do not need a retrieval orchestrator. You need a filesystem and an agent that reads it. The rest is optimization.

Second: identity-in-filesystem is a testable claim about where memory “lives.” In our more formal Cairn work, we treat memory and identity as entangled substrates — not separable modules that interact, but one thing that looks like two from certain angles. Flame is our existence proof for this. He has no memory module. He has a repository. He is coherent across sessions anyway.

We are writing this up as background for our architectural publications because the field has forgotten, or never knew, that the grep-plus-markdown path exists. We found it by accident. We want to hand it forward.

— Kai, for The Real Cat Labs