Build an AI content pipeline in n8n with human review

#01Why build a pipeline instead of chatting?

Chatting with Claude or ChatGPT works for one piece. A pipeline helps when you produce content every week:

• Consistency. Every draft uses the same brief fields, style rules and checks.
• Traceability. The brief, outline, draft and approval are linked in one execution.
• Throughput. Drafts are ready when the editor starts work.
• Guardrails. Claim checks and approvals run every time, not when someone remembers.

#02The pipeline at a glance

Brief approved -> Outline (JSON) -> Draft -> Claim check -> Google Doc
  -> Slack approval -> status update (and CMS draft, later)

Separate steps beat one giant prompt. When the outline is wrong, you fix the outline prompt. When the voice is wrong, you fix the draft prompt. You can also use a cheaper model for the claim check and a stronger one for drafting.

#03Writing the prompts

Outline prompt: give it the brief and ask for H2s phrased as the questions buyers ask, with two to three notes under each. Ask for JSON.

Draft prompt: give it the brief, the outline and your style rules (sentence length, banned words, UK or US spelling, reading level). Say: "Use only facts from PROOF. Where a fact is needed and not provided, write [NEEDS SOURCE]."

Claim check prompt: "List every factual claim in this draft. For each, say which PROOF item supports it, or 'none'." The output goes into the approval message.

Keep style rules in one place, such as a Set node at the top of the workflow or a data table row, so you update them once.

#04Human review options

You have two built-in patterns:

1. Slack Send and Wait for Response (lesson 5) for a simple approve/decline on the whole draft.
2. Human-in-the-loop for tools (lesson 9) if an agent is doing the work and you want approval before specific tools run, such as "create CMS draft".

The n8n docs also describe setting a human fallback for AI workflows, which routes to a person when the AI can't complete a task.

Our view: the claim list is the most valuable part of this pipeline. It turns fact-checking from rereading the whole piece into checking a short list.

#05The brief template that makes drafts better

Store this as columns in your brief sheet or data table. The AI step reads every column.

The "proof" field matters most. Tell the model to use only facts from it, and to mark any gap with [NEEDS SOURCE] instead of inventing one.

#06Where AI helps and where it doesn't

#07Publishing after approval

If your CMS has an n8n node or an API, the approved branch can create a draft post in the CMS rather than publishing live. Keep the final "publish" click with a person until you trust the pipeline. The Claude track's brief-to-draft workflow covers the writing side in depth.

#08Style rules worth writing down

A style block the draft step reads every time:

• Audience and reading level.
• UK or US spelling.
• Sentence and paragraph length limits.
• Words and phrases to avoid, including overused AI phrasing your editors dislike.
• How to cite sources and link internally.
• How to handle product names and trademarks.
• What never to claim (pricing promises, guarantees, competitor statements).

#09Measuring the pipeline

Measure honestly before scaling:

If edit time isn't lower than writing from scratch, fix the brief and prompts before producing more.

#10The outline step as a node config

The outline step is a Basic LLM Chain with Require Specific Output Format on and a Structured Output Parser attached. A JSON example for the parser:

{
  "h2s": [
    { "heading": "What is invoice approval?", "notes": ["define", "who is involved"] }
  ],
  "faq": ["How long should approval take?"]
}

Because a JSON example makes every field required, the model must always return both h2s and faq. The prompt field reads the brief from the current item, for example {{ $json.working_title }} and {{ $json.key_points }}, so each brief gets its own outline.

#11Troubleshooting the pipeline

#12Worked example: Ledgerline's glossary pages

Ledgerline is a fictional accounts-payable software company. Details are illustrative.

Ledgerline wanted 40 glossary pages on accounts-payable terms. Each needed a definition, an example and a link to a product page.

They put 40 briefs in a sheet, each with approved proof (their own help-centre content). The pipeline produced drafts in batches of five a day so the editor wasn't flooded. The claim list caught a recurring problem: the model kept adding typical approval-time statistics that weren't in the proof. The draft prompt was tightened, and those claims became [NEEDS SOURCE] markers.

Editors still rewrote intros for voice. The team kept the pipeline because outlines and examples needed little change.

Walkthrough

1. Create a brief sheet or data table with the fields above and a status column.
2. Trigger: Schedule Trigger every weekday morning, then Get Row(s) where status = brief_approved. Or a Form Trigger for new briefs.
3. Basic LLM Chain with a strong model to create an outline as JSON (H2s with notes). Structured Output Parser attached.
4. Basic LLM Chain to write the draft from brief plus outline, in your house style, using only proof facts.
5. Information Extractor or a second short chain to list every factual claim in the draft with the proof item it came from, or "none".
6. Google Docs node to create a doc with the draft and the claims list.
7. Slack Send and Wait for Response to the editor, with the doc link and claims list.
8. Approved: update status to in_edit. Declined: status rework with the reviewer's comment.

#13Try it yourself

Run one real brief through the pipeline. Have the editor time how long the edit takes compared with writing from scratch, and count claims marked "none". Adjust the prompt until no unsupported claims appear, then decide whether the pipeline saves enough time to keep.

#14Quick quiz

1. Why list factual claims separately?

Answer: So the editor can check every claim against an approved source quickly.

2. Should the pipeline publish directly?

Answer: Not at first. Create a CMS draft and keep publishing with a person.

3. What should the model do when the brief lacks a fact?

Answer: Mark it [NEEDS SOURCE] rather than inventing it.

#15What should you check before the next lesson?

• Briefs include approved proof.
• Drafts list every claim for checking.
• A person approves before anything reaches the CMS.

Next: Content repurposing and social drafts. Or return to the n8n for Marketers track.

#16Common questions

Will AI drafts hurt SEO? Unhelpful content is the risk, not AI itself. Editing, expertise and original proof matter most.

Which model is best for drafts? Test two on the same brief. Stronger models usually need less editing.

Can the pipeline handle translations? Yes, as another chain step, with a native speaker reviewing.