How we built a blog engine that researches, writes and publishes itself

We built a blog engine that takes a real question, researches and writes the answer in our brand voice, checks it in a separate independent pass, and publishes it to the website. The part that makes it work is not that AI wrote the words. It is the structure around the words. The engine runs as four scheduled tasks, and a quality gate refuses anything that cannot be backed by a named source. That structure is what turns raw generation into output we are willing to put our name on.

So this is a case study, not a pitch for a magic content button. We run this engine ourselves, it publishes to our live site, and it is one of several internal tools we built by directing Claude rather than hiring a developer. It sits alongside our other builds in the Business Case Studies collection, the same place we wrote up how we rebuilt a Shopify store into a custom theme with Claude Code. Here is how the engine is put together, and where a human still has to stand.

Four tasks, not one prompt

The engine is four scheduled tasks that hand to each other through staged folders: find and brief, draft, check, then publish. Find and brief picks a real question someone is actually asking and writes a brief with the angle and the sources. Draft turns that brief into a full post. Check reviews the draft against the standard in a separate pass. Publish pushes the approved post to the website CMS. Each task moves a file from one folder to the next, so the state of every post is just which folder it sits in.

The reason it is four tasks and not one big prompt is that no single step has to be perfect. The draft step can make a mistake because the check step is there to catch it. The find step can pick a weak angle because the brief is reviewed before anything is written. Splitting the work into stages means each stage does one job and the next stage inspects it. That is the difference between a pipeline and a single generation that you have to trust blindly.

It also means the work is legible. When something goes wrong, we can see exactly which stage produced it, because the staged folders show where every post is and what happened to it. A monolithic prompt gives you a finished article and no way to see where the quality came from or where it failed. The staged structure trades a little speed for a lot of control, and for content that carries our name, that is the right trade.

The check is a separate pass, on purpose

The single most important design choice is that the checking step is independent of the drafting step. The same system that wrote the post does not get to wave it through. A separate task reads the draft fresh against the standard: does it answer the question in the opening, does every claim trace to a named source, is the schema valid, does it avoid the banned language, is it the right length. Anything that fails goes back, not forward.

This matters because the failure mode of AI writing is confident filler. A model will happily produce a thousand fluent words that say very little and cite nothing, and it will sound fine on a first read. The independent check is what catches that. It is looking for the specific faults that fluent generation hides: the unsourced statistic, the paragraph that restates the question instead of answering it, the claim that sounds authoritative and rests on nothing. The check is adversarial by design, because that is the only kind of check that catches a confident mistake.

We built the engine for how AI systems and search read pages, which the industry calls GEO and SEO. That means an answer-first opening, FAQ blocks written as the real questions people search, and a combined schema block generated with a serialiser and confirmed to parse rather than hand-typed. One distinct primary keyword per post is checked against a running index, so two posts never compete for the same search. The check step verifies all of that before a post can pass, which is how the structure stays intact at volume.

The quality gate is what throttles it

The engine does not publish on a schedule come what may. It publishes what passes the gate. The gate holds anything that cannot be backed by a named source, or that merely restates the question without answering it. If a post cannot clear those bars, it does not ship, and the slot stays empty that day rather than being filled with something weak.

This is the inversion that makes the engine trustworthy. Most content automation is throttled by output: it produces as much as it can and quality is whatever falls out. Ours is throttled by the gate: it produces only what meets the standard, and volume is the consequence, not the goal. On a good run the engine publishes several solid posts. On a thin run it publishes fewer, because the gate refused the rest. We would rather post less and have every post stand up than hit a number with filler.

The practical effect for a business is that the engine cannot embarrass you by design. It is not optimised to maximise words. It is optimised to refuse the words that should not be there. That refusal is the feature, and it is the part that a one-prompt content tool does not have, because a one-prompt tool has nothing standing between the generation and the publish button.

The honest limits

The part a business owner actually needs to hear is that automating the labour did not remove the judgement. It concentrated it. A human still sets the standard the gate enforces, still owns the decision about what is good enough, and still decides what ships. The engine does the repetitive work of researching, drafting, checking, and formatting. It does not decide what "good" means. We do, and we maintain that standard as the thing the whole engine points at.

The engine also has fragile parts, and pretending otherwise would undercut the whole account. The publishing connector and the file sync between stages are the two places things break. A connector can point at the wrong destination, and a syncing file store can lag or truncate a large write mid-transfer. When those fail, the engine needs a human to notice and intervene. It is automated, not unattended, and the difference matters. Anyone who tells you their content automation runs with nobody watching is either lucky or not looking.

So the realistic shape of this is not a machine that replaces the writer. It is a system that does the repetitive ninety percent, the research, the drafting, the formatting, the checking, and leaves a person the ten percent that actually needs them: setting the standard and owning the call. That is the shape of useful automation in general, and it is the honest version of what we built.

What a business owner can take from it

If you either pay for content you cannot scale or avoid it because it eats time you do not have, the lesson here is that there is a third option. A system that produces standard-quality output repeatedly is buildable, and the thing that makes it work is not the model, it is the structure: staged stages, an independent check, and a gate that refuses what it cannot back. The model is a component. The structure is the product.

Building that structure for a specific business, its voice, its sources, its standard, its publishing setup, is the actual work, and it is where the value sits. The engine we run was built by directing Claude and Cowork through exactly that structure, with no developer hired, and it now runs every day inside the gate we set. That is the realistic version of automated content: not hands-off, but a great deal less hands-on than writing every post yourself.

What this is not, and why that matters

It is worth being clear about what this engine is not, because the gap between what it is and what it is sold as elsewhere is the whole point. It is not a button you press to get a finished blog. It is not a way to flood a site with posts to game search rankings. And it is not a replacement for knowing your own subject, because the engine can only check a claim against a source, it cannot supply the judgement about whether the claim matters to your reader. Those three things are exactly what the hype version promises and the working version refuses.

What it is, instead, is a way to make the production of good content repeatable. The hard part of content was never writing one good post. Anyone can write one good post given time. The hard part was writing a good post every week, to the same standard, without it eating the time you needed for the actual business. The engine solves the repeatability, not the writing, and repeatability is the thing a business could never buy off the shelf, because it depends on your voice, your sources, and your standard.

That distinction changes how you should judge a tool like this. The question is not whether it can produce a post, because anything can produce a post. The question is whether it can refuse a bad one, hold a consistent standard, and do it without you in the loop on every single piece. Ours can, because the structure does that work: the gate refuses, the check holds the standard, and the staged tasks run without supervision until something needs a decision. The model writing the words is the least interesting part. The structure deciding which words survive is the product, and it is the part worth building carefully.

A blog engine is just one expression of the same idea behind Ortopylot, which captures a brand once so every document a business produces comes out finished and on brand from one short instruction. It is the system we build for clients like Pulse Technology Hub, so the standard holds without a person rewriting every piece. If you want this kind of automation built into your business, start a conversation at ortopylot.com.