Refactoring the WordPress Publishing Pipeline: From Single Prompt to Three-Agent Newsroom
Some links in this article are affiliate links to products I actually use. If you sign up through them, I may earn a small commission — at no extra cost to you.
The shift to a multi-agent WordPress publishing automation workflow (available for free from the official n8n template library via the link at the bottom of this page), came out of curiosity – I’m trying a writers room approach for another experiment and the WordPress publishing pipeline seemed like a good candidate to try a variation of this idea; treating content generation like a newsroom, with a different agent for each role.
When you ask an LLM to research a topic, write compelling copy, and fact-check its own work simultaneously, you’re creating competing cognitive demands. The model has to switch between gathering information, maintaining narrative flow, and critical analysis. So I separated these concerns into distinct agents. A researcher to focus on finding credible sources and structuring information without worrying about prose quality. The writer transforms that research into readable content. The reviewer applies a critical eye on the result without the bias of having created the content.
In terms of the output quality, given that this workflow is a helper to generate the skeleton of an article using multiple LLM calls tailored with a custom tone and style guide, I was curious to see how different AI models would perform at the different tasks. The result – from a Claude generated report on the results of a Claude-orchestrated benchmark using different agents for each role 😉 – Claude tends to produce more thoughtful research analysis, whilst Gemini handles structured data extraction well.
How the Original Pipeline Worked
The initial design of the n8n pipeline bundled a tone guide, style guide, and content brief into a single prompt sent to the Anthropic API. Claude returned one JSON object containing the full article and all its metadata:
{
"title": "How to Configure n8n Webhooks for Webflow",
"content": "<p>Webhooks are essential for real-time data sync...</p>",
"excerpt": "A practical guide to setting up webhooks in n8n.",
"tags": ["n8n", "Webflow", "Automation"],
"seo_title": "n8n Webhooks for Webflow: A Step-by-Step Guide",
"seo_description": "Learn how to configure n8n webhooks to automate your Webflow site.",
"focus_keyword": "n8n webhooks Webflow",
"image_subject": "A clean desk with a laptop showing a node-based workflow diagram",
"affiliate_flag": false
}
This content was then used in the creation of a draft WordPress post with optional attributes for Rank Math SEO, along with an optional featured image and Slack notification.
What Prompted the Refactor
In addition to switching to the newsroom pattern, and introducing a few improvements – for example failure handling, length validation on SEO fields, enriching the Slack notification and affiliate flag message, I also wanted a way to override the image generation default on a per-run basis, and ensure an input prompt was provided before doing anything. The Anthropic vendor lock-in was another constraint worth fixing, especially since some tasks are better suited to different AI models.
The Three-Agent Architecture
The monolithic prompt is now split across three sequential agents: a Researcher, Writer, and Reviewer.
The backbone of this is a custom sub-workflow that normalises requests across different LLM providers. Whether I’m calling Anthropic’s Claude, Google’s Gemini, Mistral, or OpenAI’s models, a consistent response field structure is returned, including token and cost estimates. This abstraction means I can swap models per agent without rewriting the workflow logic.
Error handling between stages is added so If the writer agent fails, the WordPress publishing automation workflow waits 3 seconds and tries again with the same research input. After 2 failures, it routes to a Slack notification rather than crashing silently. I’d also recommend setting a global timeout for the workflow.
Each agent receives both the cumulative work product and the original parameters. The tone guide, target audience, and style requirements flow through every stage, allowing later agents to course-correct earlier work that drifted from the brief.
| Agent | Primary Responsibility | Output Type |
|---|---|---|
| Researcher | Gathers data, defines structure, generates metadata | Structured JSON (metadata, tags, keywords) |
| Writer | Drafts the article body from the research brief | Raw HTML prose |
| Reviewer | Enforces style guidelines, performs final quality checks | Polished HTML and validated metadata |
The Researcher Agent
The Researcher’s sole job is to produce the structural blueprint and metadata before any prose is written. It identifies the focus keyword, drafts the tags, outlines the article structure, and describes potential affiliate opportunities in plain English. Separating structured data generation from prose generation means the metadata is clean and available before the Writer touches anything.
The Writer Agent
The Writer takes the Researcher’s brief and turns the outline into formatted HTML prose. Because it is not simultaneously doing keyword research or generating image prompts, the focus is on writing quality, sentence variety, and pacing.
The Reviewer Agent
The Reviewer acts as an automated editor. It evaluates the Writer’s draft against a voice checklist with specific, enforceable rules, so the model has something concrete to act on rather than a vague instruction to “write well.” A sample of some of the instructions from my checklist (you can customise this to whatever you like):
- British English spelling throughout
- No hyperbolic marketing language or corporate filler phrases
- Sentence structure variety – short punchy sentences balanced with longer explanatory ones
- Clean HTML with no broken or improperly nested tags
Provider Routing Abstraction
A sub-workflow handles provider routing with a standardised response structure. The main workflow passes the prompt, system instructions, provider, and model name to this helper. Swapping a model is a one-field change. The routing pattern is documented in more detail in the guide on simplifying n8n LLM routing with a provider abstraction layer.
This architecture also enables easy A/B testing. E.g. I can configure the researcher to use Gemini, the writer to use Mistral, and the reviewer to use Claude, then compare results against different combinations. Implementing token and cost tracking is also made straightforward because all usage flows through the same monitoring point.
Other Changes Worth Documenting
The rest of the workflow is the same as the original, with the resulting content used to create a draft WordPress post, set an optional featured image, optionally set attributes for Rank Math SEO, and send optional Slack notifications.
Original version of the WordPress publishing automation workflow
However, the additional tweaks below were included based on suggestions by Mistral and Gemini following their review of the original WordPress publishing automation workflow. I focused on identifying quick wins to improve the usefulness, security and stability of the pipeline:
Surfacing Relevant Internal Links
After the Researcher produces its outline, the pipeline now also optionally fetches the most recent published posts from the site and scores each one for relevance against the article’s focus keyword, title, and tags – stripping stop-words and matching on significant tokens. The top five matches are passed to the Writer as internal linking candidates.
This allows the Writer to reference existing content without me hunting for it manually. It won’t always be right – the token matching is a rough signal, not a semantic one – but it surfaces obvious candidates and helps automate another part of the pre-publication process.
HTML Sanitisation
The Writer outputs raw HTML that goes directly into the WordPress database. A sanitisation step strips script, iframe, style, object, embed, and form tags, along with any inline event handler attributes like onload or onerror as a guard against the injection of executable markup.
SEO Field Enforcement
The pipeline now ensures the values for the SEO fields respect recommended length requirements – the title is capped at 60 characters, meta description at 155. Truncation happens at the nearest word boundary with an ellipsis appended to avoid half-cut words.
Parallel Image Generation and Error Resilience
Two changes here. First, image generation now triggers immediately after the Researcher finishes, running in parallel while the Writer and Reviewer are still processing. This saves some execution time per run that will vary depending on model response times.
Second, the image generation node now uses continueErrorOutput. If the image API fails, the workflow routes to a node that sets the media ID to 0 and continues rather than halting. Downstream nodes use continueRegularOutput so the rest of the pipeline is unaffected. An override flag in the incoming webhook payload allow image generation to be skipped per run.
Metadata and Slack Reporting
The Researcher outputs a plain-English description of specific affiliate opportunities relevant to the article – something like “Originality.ai affiliate programme — link to pricing page” rather than true. The Slack notification was redesigned around the additional output available and include focus keyword, image generation status (generated or skipped/failed), affiliate opportunities as a readable string, as well as estimated token costs and spend per run for better transparency.
The Plagiarism Check: A Process Change Instead of a Pipeline Change
Automated plagiarism checking was on the original refactor list using an external API from a service like Originality.ai. The plan was to scan the finished draft before saving to WordPress, however it is now triggered in the WordPress dashboard as part of my pre-publication checks. I’ve been testing Originality.ai for this purpose, and this validation approach works well for my needs.
Try It Yourself
Three agents means three API calls, three prompts to maintain, and roughly three times the cost per run. You have to decide if the result is worth that additional overhead for your particular use case. This version of the WordPress publishing automation workflow still won’t write better than you can. But it might help give a better starting point, and sometimes that’s exactly what you need.
