Persistent Memory: What AI Engineering Tools Teach Us About Knowledge Management
Photo by Eve on Unsplash

Persistent Memory: What AI Engineering Tools Teach Us About Knowledge Management

Something interesting is happening in AI-assisted development tools.

Engineers are building systems where the AI doesn't just answer questions it accumulates knowledge over time. And the pattern has implications far beyond software engineering.


How It Works in AI Engineering

Modern AI coding assistants like Claude Code have a simple but powerful feature: a memory file.

In Claude Code, it's called CLAUDE.md. It sits in your project root and contains everything the assistant should know about your codebase: conventions, architecture decisions, common pitfalls, how to run tests.

The file persists between sessions. Every conversation starts with that context loaded. The assistant isn't starting from zero; it's starting from everything you've taught it.

Some teams take this further with explicit "compounding" workflows. Dan Shipper and Keiran Klassen published a great post in December, and the Claude Plugin, Compound (I've added both to the notes).

Once this is set-up after solving a tricky problem, you tag it:

/compound
        

The assistant extracts the key insight and writes it to the memory file. Next time anyone on the team hits a similar problem, the assistant already knows the answer.


From Codebase to Organisation

The same pattern applies beyond engineering. Every organisation has knowledge that's:

  • Trapped in people's heads
  • Buried in old Slack threads
  • Scattered across wikis that nobody updates
  • Lost when employees leave

Traditional solutions require deliberate documentation. Write it down. Update the wiki.

But documentation is a second job nobody signed up for. It requires context-switching from doing the work to describing the work.

What if capture happened in the flow of work instead?


Tag, Extract, Persist

Imagine an organisational assistant that works like the engineering tools.

When someone discovers something worth remembering, they tag it:

"@assistant — a few things about client X their procurement team restructured in March. Key decision maker is now Y, previous contact Z has moved on..."

Now everyone who asks about customer data handling gets that context automatically—not buried in a policy document nobody reads.

Or internal process discovery:

"@assistant — expenses over $500 need approval, but if you tag it as 'client reimbursable' it only needs manager sign-off. Learned this the hard way."

The knowledge compounds. Each insight makes the assistant more useful.


The Technical Pattern

Under the hood, this is straightforward:

  1. Memory files: Structured storage for captured knowledge, organised by category or domain
  2. Extraction: When tagged, the assistant pulls out the key insight from conversational context
  3. Relevance matching: In future conversations, surface memories that match the current topic
  4. Deduplication: Don't store the same thing twice; update existing entries with new information

The engineering tools have proven this works. The question is applying it more broadly.


What Gets Captured

Not everything needs remembering. The system works best for:

Tribal knowledge: Undocumented quirks that experienced people just know.

Decisions and context: What're important things you'd want all new starters to know. What did you learn on the job that you wish you were told?

Real processes: not just operating procedures, but ones that are up to date and still make sense.

Lessons from incidents: Things we've tried in the past, what's worked, what hasn't.


Is it worth the effort?

Traditional knowledge bases have a scaling problem. More content means harder search, more contradictions, more staleness. Nobody knows what's current but a learning assistant inverts this. More knowledge makes it more useful.

This creates a flywheel:

  1. Team captures knowledge
  2. Assistant becomes more helpful
  3. People use it more
  4. More capture opportunities arise
  5. Assistant becomes even more helpful

Engineers have seen this with their coding assistants. The more you teach them about your codebase, the more useful they become. The same dynamic can work for entire organisations.


Getting Started

The technical implementation exists engineering teams are using it today.

Extending it to broader knowledge management requires:

  1. Making capture effortless: A simple tag, not a form
  2. Making payoff visible: Show when captured knowledge helps someone
  3. Starting focused: One team, a few knowledge categories, expand from there
  4. Building the habit: Culture matters more than technology


Creating an organisation that learns.

The same lessons get discovered over and over. The same questions get answered repeatedly. The same mistakes get made by people who never heard about the last time.

AI engineering tools have stumbled onto a fix: persistent memory, explicit capture, compounding knowledge.

The building blocks are ready. It's something we're working on Cova but can be applied to any knowledge management product really, and an approach that can really level up any product where chat is the main interface.


What knowledge keeps getting lost in your organisation?

Acknowledgements: https://x.com/kieranklaassen

Original article: https://every.to/chain-of-thought/compound-engineering-how-every-codes-with-agents

X post that got me thinking about this from Kevin Rose. https://x.com/kevinrose/status/2013053880222031950

I haven't had the need for persistent memory in claude code, not worth the payoff - but I do use frameworks and skills that people have developed - massive improvement. But what you're saying here I get, it's what organised orgs use knowledge management for. A quick path would be to interface with this via tool calling. I do see graph solutions etc, with llm devs, which is more exciting, I can imagine a state where these hold the knowledge with all the good context and interrelations. As always, it's tricky to get llm systems to be aware of what they have access to/visibility with context window limitations. That and inaccuracy. But models are getting much better.

To view or add a comment, sign in

Others also viewed

Explore content categories