Build an AI Content System That Sounds Like You

A pile of AI tools isn’t a system. It’s a pile.

The system is the thin layer you put around the tools. A few files that hold how you sound. A rule about who’s allowed to press publish. Enough structure that the whole thing still produces something in a week where you’ve got ninety minutes and no energy. Swap the model, swap the app, swap the entire vendor, and the layer is the part you keep.

Most solo founders never build it, because from the outside it looks like the boring part. The tools demo well. A file describing your own voice demos terribly. So the tools get adopted, the layer never gets written, and the output stays competent and flat, forever.

Why every AI draft arrives sounding the same

A model that knows nothing about you writes for the average reader in the average voice. That’s the only brief it has. Given nothing, it returns the middle of everything it has seen, which is a real answer to a question nobody asked.

The usual fix is a better prompt. Better prompts work, and they evaporate. The good one from three weeks ago is somewhere in a chat history, scrolled past, half remembered, retyped slightly differently every time. Nothing accumulates. You’re not building anything. You’re re-explaining yourself daily to something with no memory of yesterday.

What accumulates is structure. The same instructions, in a file, loaded before the first word gets written, every session, whether or not you remember them. That’s not a prompting trick. It’s the difference between a tool you operate and a system that runs.

I drew the line for what AI should and shouldn’t touch in What AI Is Actually Good At for Solo Founders. This is about what holds that line in place when you’re tired.

The five layers

Five layers, in the order they matter. Each one is small on its own, and the order isn’t decorative, since each layer is what makes the next one safe to build.

Voice. Files that describe how you sound: who you write for, what you’re positioned against, the rules you write by, and the phrases you’ll never publish. Then a gate, which is a checklist every draft has to clear before it moves anywhere downstream. The files supply the voice. The gate catches the drift. Build the other four without this one and you’ve automated the production of generic text.

Draft-only. The machine drafts. You publish. AI gets a piece to roughly eighty percent, and the last twenty is where it stops being interchangeable, so that twenty stays in human hands. Everything upstream can be as automated as you like, once nothing reaches an audience without passing someone who’s read it.

Projects. Shared rules on top, per-project overrides underneath. Language, tone, palette, and destination change per project. The rules about voice and fabrication don’t. Claude Code implements this exact shape with its CLAUDE.md hierarchy, where a user-level file loads first and the project file loads after it, but the pattern ports to any tool that reads its instructions off disk.

Maintenance. Pinned versions, a check after every update, and automation restricted to reporting. Updates quietly restore defaults you deliberately changed, and they do it without an error message, so catching them takes a ritual rather than good intentions.

Cadence. What the system produces on a bad week, not what it produces on a good one. A cadence built for peak energy breaks the first time life gets heavy, which is what I worked through in What Consistent Actually Means for a Solo Publisher.

Between them they answer five questions you’d otherwise improvise an answer to, one draft at a time. Does this sound like me. Who ships it. How does it handle a second brand. Does it survive an update. Does it survive a bad Tuesday.

Four of the five have a piece of their own: the voice layer and the gate that enforces it, the draft-only rule, running several brands through one setup, and keeping a tool update from quietly undoing the whole thing.

What an operating layer is not

It isn’t a tool, and it isn’t a stack of tools. Adding a sixth app to the pile gives you a bigger pile.

It isn’t a prompt library either. Prompts are inputs. The layer is what supplies the right inputs every time without you remembering to. A library you have to open is a library you’ll stop opening around week three.

It isn’t automation. Automation runs things. The layer decides what’s allowed to run, which is why mine reports and never creates. A script that tells me something drifted is useful. A script that fixes the drift by publishing is a liability wearing a helpful face.

And it isn’t a process binder. Nobody reads those, including the person who wrote them. The layer earns its place by loading itself, which is the whole trick: it’s the instructions you’d otherwise retype, sitting where the tool reads them before it starts.

What it looks like on disk

Concretely: a rules file at the root, three shared voice files next to it, and a small handful more inside each project folder. Almost all of it is plain markdown. None of it is code. The one piece that’s structured data is that way so a checker can read it.

The property that matters is that nothing lives somewhere I have to remember to open. The tool reads the root file, then the project file, and the project file wins wherever the two disagree. By the time I’ve typed anything the rules are loaded, and I haven’t had to think about them once.

That’s the entire mechanism. Files, in the right places, read in the right order, before the work starts. Unglamorous in a way I’ve come to trust.

When it’s worth building

Skip it if you publish once a month and like what comes back. The layer solves a repetition problem, and without repetition there’s nothing to amortise.

It starts paying when at least one of these is true. You publish weekly or more. You run more than one brand, or more than one language. You use AI and you’ve stopped recognising your own archive. Or your output drops to zero in any week that turns out badly, which is most of the interesting weeks.

The first version doesn’t need to be good. It needs to exist and be editable. Mine started as one file of rules I’d caught myself repeating out loud, and everything since has been editing rather than inventing.

What changes when it holds

The draft arrives in your voice, so the review becomes a read instead of a rewrite. That one change is most of the return, since the rewrite was the part that used to eat the evening.

A bad week produces less instead of producing nothing, because the decisions were made upstream while you had the energy to make them. Separate brands in three languages stay separate, since what keeps them apart lives in files rather than in your attention. And the tool underneath turns into something you can replace on a Wednesday afternoon without rebuilding your practice, which is worth more than any single model’s quality.

None of this makes the writing effortless. It moves the effort to where it compounds.

The tools you’re using right now will be replaced inside a year. Claude Code is my current implementation, and it’s an implementation, not the point. The layer is the part you keep.

Build the layer first. Then pick the tools.


Build Your Content Machine. A free 5-part email course, one email per layer, ending with a starter template you drop into your own setup. Start the free course →

Did you like this article? Share it with a friend!