My brand lived in one file. It should have lived in three.

Every AI Brain engagement I run hits the same moment. The founder has a Claude subscription, a handful of documents, and a business that has drifted ahead of what any of those documents say. The fix is never “write more documents.” It’s deciding which document owns which fact, so the next person, human or agent, knows where to look, and where to write.

I hit my own version of this problem last week, in my own practice.

The symptom

Role Factory, the tool that builds a personalised AI workspace for a role in minutes, lives at ai-role.ctoondemand.co.uk. It’s a CTO on Demand product. It should look like one.

It didn’t. Somewhere between shipping the first version and iterating on the wizard, it had drifted into default Tailwind: slate grey, a stock blue, a system sans-serif font, rounded-corner cards with an icon in a coloured square. Perfectly competent. Also the single most recognisable “AI generated this SaaS page” layout on the internet right now, sitting on my own domain.

Meanwhile, ctoondemand.co.uk has a real design system. Cream paper, not enterprise white. An editorial serif for headlines. A yellow highlighter under one phrase per heading. Pill-shaped buttons only. A written list of patterns it deliberately avoids, because AI-assisted design defaults toward them the moment nobody’s watching.

Two products, one company, two visual languages. Nobody planned that. It’s just what happens when a design system lives in one repo’s files and nothing tells the next repo it exists.

The instinct to resist

The obvious fix is a shared file. Put the brand in one BRAND.md, reference it from everywhere, done. I’ve watched this pattern fail before it’s watched it succeed, so I want to name why the obvious version doesn’t work.

One shared file assumes everything drifts at the same rate. Voice rules, don’t use em dashes, cut the corporate vocabulary, are close to universal. They’re true whether I’m writing a commit message or a landing page. Visual identity is true within a family of related products but wrong the moment you cross into an unrelated one. Audience-specific messaging is true for exactly one product’s exactly-defined customer and actively wrong for anyone else’s. Bolt all three into one document and you get a file that’s either too vague to be useful, or that quietly imposes one product’s audience on another product’s copy.

One shared file assumes one filesystem. I have a pointer pattern already running elsewhere in my setup, a supplement-tracking site with its own brand voice, pointing back at a canonical BRAND.md in a sibling repo. It works, until an agent runs in a sandboxed session that never mounted that sibling repo, and the pointer is a path to nothing. A brand system that only resolves on one laptop isn’t a system. It’s a habit.

What actually went in

Three tiers, matching three different drift rates, each pointing at exactly one place to update.

Brand-family identity, the actual colours, the actual typeface, the list of layouts I refuse to ship, lives in exactly one repo: the site where I tune it by hand. Every other property gets a short, named pointer: which repo, which file, and the instruction to port changes by hand rather than pull them live. I gave that pointer two addresses on purpose, a local path for same-machine work, and the repo name for anywhere that path doesn’t exist. Whichever environment an agent wakes up in, there’s a way to find the source.

Product-specific voice, who the product’s customer actually is, what they’re afraid of, what makes them buy, stays local to that product. This is the one I was tempted to centralise and didn’t. A supplement-tracking audience and a fractional-CTO audience have nothing useful to say to each other. Forcing them into one document produces copy that convinces no one.

The sync between tiers two and three is deliberately not automatic. No build step pulls the canonical file live. A brand change is a decision, and decisions get a human glance before they repaint a second product overnight. If keeping two files in step ever becomes genuinely painful, the next move is a small script that flags drift, not a pipeline that resolves it silently. Automating a problem you have twice a year is usually just moving the failure mode somewhere less visible.

Why this is the AI Brain problem, not a design problem

I sell “install a real system so the founder isn’t retyping context into a chat window every Monday.” What Role Factory’s drift actually showed me is that the same failure mode doesn’t stop existing once you have engineers and repos instead of a chat window. It just moves. The document sprawl is still there. It’s just sprawled across git repos instead of open tabs.

The fix wasn’t a smarter model or a longer prompt. It was deciding, in writing, which file owns which fact, and then making sure every consumer of that fact points at the owner instead of holding its own copy. That’s the whole trick, whether you’re running it for a client’s business or for your own.

If this sounds familiar

If you’re running more than one product, or more than one AI-assisted workflow, and you’ve noticed the voice or the visual identity quietly diverging between them, that’s the AI Brain Audit in one sentence: a half-day diagnostic that finds exactly this kind of drift and gives you a written roadmap for fixing it, before you’ve built a third inconsistent thing.

See how the AI Brain engagement works, or book a 30-minute call if you’d rather just talk it through.