I Changed How I Think About AI Memory
When I first built Lean AI Memory, I focused too much on the idea.
AI agents need memory.
Multi-agent systems can become complicated.
Maybe we need a simpler approach.
So I built a small project around that idea.
But after publishing it, I realized something:
The project was simple. The README wasn't.
It talked too much about what I didn't want to build.
Multi-agent systems.
Vector databases.
Embeddings.
Cloud services.
Complex infrastructure.
But that wasn't really the interesting part.
The interesting part was much simpler:
Can an AI coding agent remember a project using nothing more than Markdown and Git?
That question is what Lean AI Memory is actually about.
From "AI Memory System" to "Git-Native Memory"
I changed the positioning of the project to:
Git-native memory for AI coding agents.
The idea is intentionally boring:
AI Coding Agent
|
v
.ai.rules
|
v
.ai-memory/
|
v
Git
No database.
No vector database.
No embeddings.
No cloud API.
No additional service.
Just files inside the project.
The memory is readable by humans, version-controlled by Git, and can be inspected with the same tools developers already use every day.
For example:
git diff
That's enough to see what changed.
Why Git?
Because software projects already have a memory system.
It's called Git.
Git already gives us:
- history
- diff
- rollback
- branches
- collaboration
- local storage
- remote backup
So instead of creating another memory infrastructure, I started asking:
What if we simply give the AI a small protocol for using the project's existing history?
The AI reads the recent memory before working.
It works on the project.
Then it records important decisions, completed work, and unfinished tasks.
The next session can start from that context.
That's the whole idea.
Keep the Memory Small
One thing I learned while building this is that AI memory doesn't need to become a transcript of everything.
I don't want this:
10,000 lines of conversation
↓
AI memory
I want something closer to:
What changed?
Why did we change it?
What did we decide?
What's still unfinished?
For example:
# 2026-08-12
## Completed
- Added PDF signature verification.
## Decisions
- Keep PDF processing completely local.
- Use SQLite for local license storage.
## Next
- Add batch verification.
- Improve error reporting.
A small amount of useful context may be more valuable than a huge archive of conversations.
What Changed in the Repository?
I rewrote the README around this idea.
The new version focuses on:
- the actual problem
- the minimal architecture
- how to get started
- personal vs team usage
- why Markdown + Git
- what the project intentionally does NOT try to solve
I also changed the GitHub description to:
Git-native memory for AI coding agents. Markdown + Git — no database, embeddings, or cloud API.
The goal is not to claim that this is the best AI memory system.
It's deliberately the opposite.
I want it to be the smallest useful thing.
Is This Better Than a Real Memory System?
Probably not for every use case.
If you need semantic search across millions of memories, knowledge graphs, sophisticated retrieval, or enterprise infrastructure, this approach is obviously not enough.
And that's okay.
Lean AI Memory is aimed at a different question:
What is the minimum infrastructure needed to make an AI coding agent remember a software project?
Maybe the answer is:
Markdown + Git.
I'm still experimenting with this idea.
The repository is small, and that's intentional.
If you're building with AI coding agents, I'd be interested in hearing how you currently handle memory between sessions.
Do you use a memory system, a database, a bunch of Markdown files, or simply start every session from scratch?
Top comments (0)