I keep running into the same problem when I make things with AI:
The model is usually capable enough. The context is not.
I might spend one evening working on a game, another designing a website feature, another thinking through architecture, and another doing something completely unrelated like writing a D&D campaign.
The individual conversations can be productive. The problem appears when I come back.
What did we decide?
Why did we decide it?
Which ideas were experiments and which became architecture?
What is actually true in the project now?
And perhaps most importantly:
How does the next tool know any of this?
That question eventually became Find Familiar.
Find Familiar
Find Familiar started as an attempt to give my AI tools durable memory and a shared project-management layer.
The idea grew into a system with projects, durable knowledge, plans, work slices, worker sessions, reviews, approvals, and a web interface I call the Demiplane.
Different AI workers could be summoned to do different jobs. A planner could reason about a change. An implementer could work on it. A reviewer could inspect what happened. The system could keep records of those interactions instead of depending entirely on whatever happened to still fit inside a chat window.
It works.
And building it has taught me an enormous amount about what AI-assisted development actually needs.
But Find Familiar also exposed an interesting possibility:
Maybe the most important part of the system isn't the orchestration. Maybe it is the architecture of the context itself.
The Context Accumulation Problem
Saving everything isn't memory.
It's storage.
If I dump every conversation, prompt, response, plan, log, and implementation result into a giant bucket, the next AI has technically been given more information.
It may actually understand the project less.
Useful context has structure.
Some things are durable:
- the purpose of the project
- architectural decisions
- important constraints
- dependencies
- current goals
Other things are temporary:
- today's experiment
- a debugging session
- implementation chatter
- an abandoned idea
- raw tool output
And some things matter mostly because they explain why the durable things changed.
That distinction became increasingly important while building Find Familiar.
The system began evolving from “store the AI history” toward something closer to:
Maintain a living body of project knowledge and compile the right context for the work being done.
That is a much more interesting problem.
Then I Realized Git Already Does Half the Job
I had been building infrastructure for durable knowledge while already using a tool specifically designed to maintain durable, inspectable, versioned information:
Git.
Every AI development tool I use already understands repositories.
Git gives me history.
It gives me diffs.
It gives me branches.
It gives me provenance.
It gives humans and machines a common filesystem full of boring text files.
And boring text files are remarkably good infrastructure.
That led to a smaller experiment.
I called it Grimoire.
Grimoire
The first version of Grimoire is deliberately much less ambitious than Find Familiar.
It is essentially a Git-native context routing protocol for human/AI work.
The basic shape is:
Public Grimoire
↓ fork or clone
Personal Grimoire
↓ routes tools to
Project Architecture Repositories
↓ optionally reference
Project Source or Content Repositories
The Grimoire doesn't need to contain every piece of knowledge itself.
It needs to tell an AI:
- what projects exist
- where their authoritative knowledge lives
- what their current state is
- how work should be recorded
- how one session should hand useful context to the next
A game can have an architecture repository and a source repository.
A writing project can have an architecture repository without any source code at all.
A website, D&D campaign, research project, home project, or ridiculous weekend experiment can all use essentially the same pattern.
That is important to me because I don't want a giant enterprise project-management system for my hobbies.
I already have those at work.
I want something a solo creator can understand.
Find Familiar Wasn't a Wrong Turn
Grimoire isn't replacing Find Familiar.
At least I don't think it is.
The relationship is becoming clearer.
Find Familiar is an experiment in active orchestration.
Grimoire is an experiment in durable context architecture.
One can summon workers, track execution, enforce approvals, compile context, and provide a management interface.
The other asks whether the underlying knowledge can remain simple enough to survive independently of any particular AI service.
That separation is useful.
A Grimoire repository doesn't care whether I open it with ChatGPT, Codex, Claude Code, some future local model, or a tool that doesn't exist yet.
The knowledge remains mine.
The protocol is readable without the software that created it.
That is a property I increasingly value.
The Current Experiment
So that is where the workshop is today.
Rather than immediately making Find Familiar larger, I am taking what it taught me about context and reducing those lessons to their simplest possible form.
The first public Grimoire is intentionally bare.
I have created a private personal Grimoire alongside it and am beginning to use it on real projects.
One of the first case studies will be a small Godot game project with separate architecture, source, and archive repositories.
That gives me somewhere to discover what the protocol actually needs instead of designing every possible feature in advance.
When something proves useful in daily work, it can move back into the public Grimoire.
When something proves unnecessary, it can disappear.
And if the experiment succeeds, Find Familiar eventually gets something extremely valuable:
a stable context substrate underneath all of its clever machinery.
That feels like a much stronger foundation than trying to make the machinery remember everything itself.
For now, Grimoire is just text files, conventions, Git history, and a few ideas about how humans and AI should leave the workshop ready for whoever walks in next.
That may be enough.
And finding out whether it is enough is the project.