Why I Ditched Complex Memory Systems for Git

Why I Ditched Complex Memory Systems for Git

I’ve been building an agent called Anna for over two years, and my goal was to give her persistent memory that evolves over time. Not just remembering the last 10 messages, but actual long-term memory that changes and adapts.

I’ve tried everything: vector databases, knowledge graphs, embeddings, and more. But they all fell short in one key area: showing how knowledge evolved over time.

Then, it hit me: Git is already amazing at tracking changes and evolution. So, I built a proof-of-concept where Anna’s memories are stored as markdown files in a Git repository. Each conversation commits changes, and suddenly, Anna can:

* See how her understanding of entities evolved (git diff)
* Know exactly when she learned something (git blame)
* Reconstruct what she knew at any point in time (git checkout)
* Track relationship dynamics over months and years

The use cases are incredible. Imagine agents that track project evolution with perfect history of decisions, client relationships showing every interaction’s impact, personal development with actual progress tracking, and health conditions with temporal progression.

Anna can now answer questions like ‘how has my relationship with X changed?’ by literally diffing the relationship memory blocks. Or ‘what did you know about my project in January?’ by checking out that commit.

Search is simple but effective, using BM25 (keyword matching) with a large language model generating the queries. And the entire memory for two years fits in a Git repository that can be read with Notepad.

It’s still rough around the edges, but this approach feels fundamentally right. We’ve been trying to reinvent version control instead of just… using version control.

Anyone else frustrated with current memory approaches? What are you using for persistent agent state?

Leave a Comment

Your email address will not be published. Required fields are marked *