Automated blog production

Role

I designed the workflow, wrote the step instructions and the knowledgebase behind them, and rebuilt the whole thing after the first architecture failed.

Trigger

A keyword added to a Notion database. Nobody opens the AI tool to start a run.

Built on

One Relevance AI workflow, with a knowledgebase holding tone of voice and audience personas.

Sources

Semrush for volume and difficulty, Google for the pages already ranking on the term.

Publishes to

WordPress, through the REST API. The article lands in the CMS, not in a document someone then has to move.

Quality gate

An AI-detectability check on the draft before it goes out.

The strategy was not the bottleneck. The production line was.

1. Three roles for one article

   A writer drafted it, an SEO specialist checked it against the target keyword, a publisher cleaned it and put it live. None of that work is hard. All of it is sequential, and each step waits for a person with other priorities, so the cost of an article was set by coordination rather than by writing.

2. Standards existed as a document, not as a constraint

   Tone of voice, article structure, and how a keyword should be treated were all written down. Whether any of it made it into a given article depended on who happened to pick the brief up. Consistency was a matter of individual diligence, which means it was not consistent.

3. Scaling meant hiring

   The list of keywords worth ranking for was far longer than the team could ever work through. Any plan to publish more was a plan to add headcount, and the return on a single article does not justify that.

The first build was a team of agents. It was worse than one.

The obvious way to model a content team in software is to copy the content team. So the first version had specialists: an agent that researched, an agent that outlined, an agent that wrote, an agent that formatted and published. Each one had a clear job and each one, tested on its own, did that job well.

1. The handoffs were where it broke

   Every boundary between agents was a point where context had to be restated, and something was lost each time. The research agent knew why a particular competitor page mattered; by the time the writing agent had it, that had flattened into a list of headings.

2. The same keyword produced different articles

   Not different in wording, which is fine, but different in structure and depth. Output was unpredictable run to run, and unpredictable output is unusable in a publishing process, because someone has to read every article closely to find out what they got.

3. Writing an article is not parallel work

   The case for multiple agents is independent work that can happen at once, or genuinely different reasoning problems. Producing one blog post is neither. It is a single job with an order to it, where each step depends on the full context of the last. The architecture was solving a problem the task did not have.

Version two collapsed all of it into one workflow that runs the same steps linearly, holding the whole brief the entire way through. The inconsistency went away. It is a less impressive diagram and a much better system.

Most of what makes it work is restraint about where the automation stops.

1. One workflow, not a team of agents

   The rule that came out of version one: use multiple agents when the work is genuinely independent, and a single ordered workflow when it is one job with steps. Copying an org chart into an architecture is not a design principle.

2. Brand standards live in a knowledgebase, not in a prompt

   Tone of voice and audience personas sit in one place the workflow reads on every run. Changing how the blog sounds is an edit in one file, not a rewrite of eight step instructions, and consistency stops depending on who picked up the brief.

3. Research before writing, always in that order

   Keyword data, the pages already ranking, the search intent behind the term, and the internal and external links available are all resolved before a single sentence is drafted. The writing steps are not allowed to invent their own angle, because that is where an article stops being about the keyword it was commissioned for.

4. The trigger is a row in a tool people already use

   A keyword goes into Notion, which the team was already using to plan content. There is no new interface to learn and no adoption problem, because from the outside the automation looks like the planning step they were doing anyway.

5. Measure the thing you are worried about

   The fear with automated content is that it reads like automated content. Rather than argue about that, every draft gets an AI-detectability score and the number gets recorded. It currently sits around 80 percent, against a target of 20 percent or below. Naming the number is what makes it something to fix instead of something to defend.

I owned this end to end, including the version of it that did not work.

1. Set the objectives before choosing the tools

   Four of them: cut the manual effort out of SEO content, enforce brand and SEO standards rather than document them, scale output without adding headcount, and improve visibility on target keywords. Each one is testable, which is what made it possible to say later that version one had failed.

2. Wrote the step sequence

   The eight steps, their order, and what each one is allowed to assume from the step before it. This is most of the actual product. The model is doing ordinary work at each step; the sequence is what makes the output an article rather than eight pieces of text.

3. Built the knowledgebase

   Tone of voice and audience personas, written as something a workflow can apply on every run rather than as brand guidelines a person is meant to have internalised.

4. Threw the first architecture away

   Diagnosed the inconsistency as a handoff problem rather than a prompt problem, and rebuilt as a single linear workflow instead of trying to patch the seams between specialists. That was the decision that made the system usable.

5. Connected it to the tools either side

   Notion as the trigger, Zapier carrying the request, and the WordPress REST API at the far end, so the pipeline runs from planning to published without a manual copy-paste anywhere in it.

6. Explored feeding it from other data sources

   Two research spikes tested whether the same workflow could originate content beyond keyword research: pulling Google Maps reviews to seed geo-dependent articles for individual locations, and scraping job boards to seed job-related overview articles. Both confirmed the pipeline's shape — research first, one linear draft — generalizes past SEO keywords into other article categories.