Your rules should travel with you
Async Digital Ltd Cardiff, UK
Working with an AI assistant on a long-running project builds up a body of rules, observations, and small decisions that shape how the assistant behaves for the studio that taught it. That teaching is professional capital. In most setups it lives inside one product, in vendor-specific directories and formats, and would not travel if the studio switched assistants. Keeping the same rules in plain markdown files in a folder the studio owns makes the assistant the runtime, not the storage. The assistant becomes interchangeable; the teaching stays with the studio.
The most valuable thing built alongside the assistant is the body of teaching the studio has given it. That teaching belongs in plain files. This note is about why.
The capital builds up whether you name it or not
Every time the assistant is corrected on a phrasing, a file layout, or a naming convention, it learns something it didn’t know yesterday. Every time a lesson from a bug is captured into a rules file, that body of teaching widens. The teaching compounds. After a few months, the assistant behaves differently for the studio than it would for someone who started yesterday.
This is the part most people miss. The assistant feels like a tool. The teaching feels like a workflow tax. But the teaching is the asset.
The asset is trapped
In most setups, the teaching lives inside the product. Settings in a vendor-specific directory. Memory entries in a vendor-specific format. Skill definitions only one tool knows how to load. Even plain-prose rules end up phrased in that vendor’s terms.
Switching assistants tomorrow would mean starting from zero. Months of teaching, gone. Or rather, still on disk, but not legible to anything else.
This is the bit that ought to feel uncomfortable. The most valuable thing the studio is building is sitting in someone else’s filing cabinet.
Why this matters for an independent studio
Async Digital is an independent studio. The rules and reflexes taught to the assistant are what make a small studio capable of more than its size would suggest. They function the way an agreed working style functions inside a team. They have been built up over months, file by file.
If those rules are stuck inside one vendor’s product, what makes the studio effective is rented. If they travel with the studio, they belong to it.
The assistant as runtime, not storage
The setup is straightforward. The rules live in plain markdown files. The state lives in plain markdown files. The configuration lives in a plain git repo. If a different assistant could read those files, it could pick up where this one left off. The assistant becomes the runtime, not the storage.
It isn’t all the way there. The current setup still leaks vendor-specific shape in places. But the direction is settled, and most of the body is already in a portable shape.
The IDE analogy
The reason this matters isn’t fear of any one vendor. It’s the same reason a developer learns the language and not the IDE. The IDE comes and goes; the language stays. The teaching should be like the language. The assistant can be like the IDE.