This is the whole thing. The system we run to publish content for ourselves and for clients, laid out step by step, with the actual files to download at each stage. Take them. We wrote separately about why the files were never the moat, the judgment sitting on top of them is, and this piece is us putting our money where that argument is. If a twenty-dollar tool and a folder of our prompts could replace us, we would deserve to be replaced. They can’t, and showing you exactly why is more convincing than hiding the work.
One definition first, because the phrase gets used for two different things. We covered the distinction in full elsewhere: a content mill turns a keyword into a page while you get coffee, and a content engine is a system that produces specific, credible content on a schedule with a person checking its work. This is the second kind. Here is what it is made of.
The order is the point
The engine has a spine, and the sequence matters as much as the parts. Foundation first, because everything downstream inherits it. Then a scanner that decides what is worth writing. Then drafting, held to a hard gate. Then a human. Then publishing. Then a loop that feeds what got published back in, so the whole thing sharpens over time. Skip the foundation or the human and you have a mill with extra steps.
Two parts of our engine are left out of this piece on purpose: the SEO brief and the content roadmap, the system that decides which specific searches a post should answer. That is its own machine and its own teardown, and it gets its own post. What follows is everything else.
Start with the voice, not the topic
Before the engine writes a word, it needs to know how you sound and how you must never sound. Those are two separate documents, and they carry more of the load than anything else in the system.
The first is a voice profile: a structured description of the register, the vocabulary, the sentence rhythm, the things this brand believes, and the reader it is talking to. Ours runs to sixteen sections. It is what makes the writing sound like a person who actually knows the subject.
We built it this way because the usual version is worthless. Ask most brands for their voice and you get the same five words: empathetic, informative, educational, professional, thought leader. That describes every company, so it guides none of them, and a model handed those words produces exactly the beige content the phrase predicts. A voice profile earns its keep only when it is specific enough that it could not belong to anyone else.
Download the voice-profile template and fill it in for your own business. The template is empty scaffolding, and the fastest way to fill it is with the model, not despite it: give it samples of how you actually write, let it draft each section, and correct what does not sound like you. You bring the writing and the judgment; it brings the first draft. But you are free to point your AI Assistant at the template and conversationally fill it in. That’s how we do it.
The second is an anti-patterns document: the hard list of everything the content must never do. Generic openers, hype, the negative-parallelism habit that makes writing read machine-generated, keyword stuffing, anything glib about the people a client serves. Ours is a gate, not a guideline. A draft does not ship until it clears the checklist, and the countable tells get counted, not eyeballed. Download our anti-patterns document. A fair bit of it is general - the AI tells, the hype bans, the formatting rules - and you can use those as written. Some of it is specific to the behavioral-health work we do, like the rule never to be glib about mental illness, addiction, or the people a clinician serves. Keep the general structure and swap those domain-specific rules for whatever would be careless or off-brand in your own field. This one file is most of what keeps an AI-assisted engine honest, because it names the exact failure modes a model falls into and forces a pass against them every single time. We adapt this for every client.
The radar: deciding what is worth writing
Most content programs die because nobody knows what to write next, so they write whatever is handy, and whatever is handy reads like filler. The radar fixes the input side.
Once a week it reads the brand context and the content roadmap, scans a defined set of sources, and pulls out signals: a shift in the field, a question that keeps coming up, a piece of news a specific audience would care about. Then it scores each signal separately for each channel, blog and newsletter and social, because a thing worth a newsletter mention does not always earn a blog post. It rates each one from zero to one with a one-line reason. It writes the week’s findings to a dated briefing, and it remembers: every signal carries a stable ID, so the system can see when something keeps recurring and has earned a real piece rather than a passing mention.
The output is not content. It is a ranked, sourced list of what to make, with the reasons attached, which is the thing a human is good at judging and a blank page is not. Download the radar prompt, point it at your own sources and roadmap, and it does the same job for your business.
Drafting, held to the gate
Now the model writes, and this is the step everyone assumes is the whole engine. It is the least important part.
The drafter takes one signal, the brief for it, the voice profile, and the anti-patterns doc, and produces a draft in the brand’s voice. Then it does the thing a mill skips: it runs its own output back through the anti-patterns gate before a human ever sees it. It counts the tells, checks the openers, flags anything that reads assembled, and rewrites a draft that fails before it reaches the review step. So the human is proofing a piece that already cleared the mechanical checks, and can spend their attention on the part only they can judge, which is whether the thing is true, whether it is ours, and whether it has a point.
The tooling here is commodity. A capable model with the right context does this. What makes the output good is the context you feed it, the two foundation files, and the gate you make it clear. Download the blog-writer prompt; the quality gate it runs against is the anti-patterns file above. We made the fuller case for why the tool is the cheap part.
The human is not a formality
Here is where the engine stops being automatic, permanently and on purpose. A person reads the draft and owns it. They check it against what they actually know, cut the paragraph the model was too confident about, catch the claim that needs a source, and decide whether it earns publication at all. In behavioral health, that reviewer is often a clinician, because a page about care has to survive a clinician’s read and not only a marketer’s.
Correctness is only half of the job. The bigger thing the human adds is the part a model cannot invent: color, depth, and the specific. A model can assemble a competent, true paragraph about intake or discharge planning. It cannot tell you about the Tuesday a bed opened at four in the afternoon and who made the call to fill it. The reviewer ties the topic to real experiences - a situation they lived through, a detail only someone who was in the room would know, the offhand thing a client once said that reframes the whole piece. That is what carries a draft from accurate to worth reading, and it is why the person at this step is usually an operator, not a proofreader.
This is the step that decides which of the two kinds of system you are running, and it is the one step that cannot be automated without turning the engine into the thing we are telling you not to build. Remove it and you have a mill. Everything upstream exists to make this person’s fifteen minutes count.
Publishing: plain files, no CMS
The approved draft is markdown, and it stays markdown. It goes into the site as a file in version control rather than a CMS database. That keeps the whole history reviewable, keeps the site fast, and means the same clean text that renders for a human can be served to an AI assistant without a second, mangled copy. The publishing stack is a choice we made for our own reasons, and it is not the point of the engine. Any reliable way to get the approved words live works. If a CMS is where your team already lives, the engine can hand off there instead: it can push the finished draft into Webflow through its MCP, or into WordPress through the REST API, landing as an unpublished draft you review and publish inside the tool you already know. The pipeline is identical right up to this last step; only the destination changes. We use static markdown for speed and for how cleanly AI reads it, because the review-and-publish gate matters more than where it lives.
The newsletter, and how it reaches people
The same engine feeds a newsletter, and the wiring is worth showing, because this is where most setups get needlessly complicated.
A newsletter has its own voice, shorter and more direct, written for an inbox instead of a search result, so it gets its own voice file, a channel overlay on the main profile. The radar already scored this week’s signals for the newsletter, so the writer has its material. It emits the issue as a markdown draft, the same format as everything else in the engine.
Then a small script turns that markdown into a sendable email. It renders the markdown, wraps it in a fixed plain shell, the wordmark at the top and the unsubscribe line the law requires at the bottom, and creates the issue in Resend as a draft broadcast. It does not send. A person opens Resend, proofs the rendered email, and sends it themselves. The layout lives in code so a model never redraws it and it never drifts, the words come from the engine, and the send is a human’s finger on the button. Subscribers arrive through the signup form on the site, which adds them to the Resend audience the broadcast goes to. Download the newsletter-writer prompt and the push script; the only things the script needs are your Resend key, kept out of the file, and a small config with your audience and from-address.
The loop that makes it better
A mill produces the same quality forever. An engine improves, because it watches what happened to the last thing it made and adjusts.
After a piece is live, one part of the system reads the published version back off the site and compares it to what the engine originally drafted. Where a human changed something in review, softened a line, cut a claim, rewrote an opener, that edit is a signal. When the same kind of edit keeps showing up, the voice profile or the anti-patterns doc is missing a rule, and the system proposes adding it, so next week’s drafts stop repeating the mistake. A small fix, like catching the same tired phrase three weeks running, becomes a permanent gate instead of something a human re-catches forever. Two skills run this loop: the voice-learner diffs each draft against the published version and proposes the new rule, and site-sync reads the published pages back off the site to feed it. Both are yours to download.
This is the part that compounds. Each engagement sharpens the profile, each correction closes a gap, and the drafts arrive needing less editing over time. The human judgment is not replaced by the loop. It is recorded by it, and reused.
How to tell a real engine from a mill when someone sells you one
Everything above is also the buyer’s test. Ask whoever is pitching you an AI content system four questions. Where does the voice come from, and can they show you the profile? What stops a bad draft from shipping, and is it a real checklist or a vibe? Who reads a piece before it goes live, and what are they equipped to judge? And does the system learn from its own published work, or does it produce the same quality at the same level every week forever? A real engine answers all four by showing you a file. If the answers stay vague, you are looking at a mill.
How to actually use these files
You do not have to read all of them cover to cover before you start. The fastest way in is to let an assistant read them for you. Grab just the files you want, or download the whole bundle as a zip and unzip it into a folder (open the START-HERE file inside first). Then open an AI assistant that can read that folder, point it at the files, and say something like:
Explain these files. Tell me whether they are relevant to my situation and project, what I need to know about them, and how we would start setting them up and adapting them for my use case.
From there you work through it together. The assistant will tell you which pieces fit, walk you through filling in the voice profile and the profile config for your business, and help you wire the output to wherever you publish. These are meant to be operated by an assistant inside a project folder - they reference each other and your own context files - so handing them over and adapting together is exactly how they are built to be used. Skim them yourself too, so you know what the machine is doing, but the prompt above is the practical starting move.
What we left out, and why
The SEO brief and the content roadmap are missing from this walkthrough on purpose. They are the part that decides which specific searches each post should answer and in what order, and they turn “write something good” into “write the thing a real person is searching for.” That deserves its own teardown, and we will give it away too, in its own post.
If you would rather have this pointed at your business than assemble a folder of files yourself, that is the thing we actually do. Book a 20-minute conversation and we will tell you honestly whether you need us or just need the files above. No deck, no pitch.
Common questions
What is the difference between a content engine and a content mill?
A mill turns a keyword into a page with no human judgment and no memory, and it produces the same generic quality every time. An engine is a system with a voice profile, a hard quality gate, a person who owns each piece, and a loop that learns from what got published. The same tools can power either one. The difference is the judgment and the checks around them. We go deeper in what a content engine actually is.
Do I need AI to build a content engine?
No, but AI is what makes the economics work. The engine is a set of steps and standards, voice and selection and drafting and review and publishing and learning, that existed before AI. AI removes the grind from the drafting step, which lets a small team run the whole thing at a cadence that used to take a department. The judgment steps stay human either way.
Isn’t giving away your whole system bad for business?
Only if the system was the product, and it is not. The files are a starting point. Making them work for a specific business, week after week, with the judgment to know what to keep and what to throw out, is the part worth paying for. Handing over the files proves that instead of hiding it.
Which files can I download?
The voice-profile template, the anti-patterns document, the radar prompt, and the newsletter push script, all linked in the sections above. They are the engagement-agnostic versions, the skeleton rather than a client’s filled-in copy. Take them as a starting point and make them yours.