How to Build a Research-Writing-Review Agent Pipeline

Generating a draft is the easy part. The hard part is knowing whether the draft is sourced, useful, readable, and safe to publish.

That is where a research-writing-review pipeline helps. Not because more agents magically produce better work. They do not. The point is narrower: split the job into stages, make each stage leave evidence, and block publication when the evidence is weak.

This guide uses technical content as the example, but the pattern works for documentation, internal runbooks, tool comparisons, and small content sites. The workflow is intentionally boring. That is a feature.

AI-assisted disclosure: this article was produced with AI assistance from a planner brief and a source-backed research packet, then reviewed against KnowToAct editorial gates for source quality, practical usefulness, and risk controls.

The mistake: optimizing for more drafts

A lot of AI content workflows are built around one question: how do we generate more pages?

That is the wrong starting point. If the site is public, the better question is: how do we decide what is worth publishing?

Google's guidance on helpful, reliable, people-first content asks site owners to look at whether content is made for people or mainly for search traffic. Its spam policies also call out scaled content abuse: generating many low-value pages primarily to manipulate rankings. The production method is not the only issue. Intent and usefulness matter.

So the pipeline should not be a text factory. It should be a control system. Each agent has a narrow job. Each handoff creates an artifact. Each gate can say no.

The smallest useful pipeline

Start with this:

Topic idea
  -> planner brief
  -> research packet
  -> draft
  -> fact-check
  -> editorial and anti-AI-tone review
  -> build and acceptance check
  -> publish

Anthropic's guide to building effective agents separates predefined workflows from more autonomous agents and argues that successful implementations often use simple, composable patterns. That maps well to publishing. You do not need a swarm. You need a few clear steps that are hard to skip.

The important detail is not the number of agents. It is the artifact trail.

A useful pipeline should answer these questions later:

• Who chose the topic, and why?
• Which sources support the claims?
• Which claims are uncertain?
• Who checked the draft?
• What did the reviewer reject?
• Which build and publication checks passed?

If you cannot answer those questions, you do not have a pipeline. You have a chat transcript and a published page.

Roles and handoff artifacts

Keep the roles narrow. One agent can play more than one role in a tiny project, but the roles should still be separate in the workflow.

Role	Job	Input	Output	Should not do
Planner	Scope the article	Site goals, content inventory, topic idea	Brief	Write the final article
Researcher	Collect evidence	Brief	Research packet	Invent sources or hide uncertainty
Writer	Draft from evidence	Brief and research packet	Draft article	Publish directly
Fact-checker	Verify claims	Draft, source list, research packet	PASS / REQUEST_CHANGES / BLOCK	Rewrite unsupported claims into certainty
Reviewer	Check usefulness, SEO, originality, and AI tone	Draft and fact-check result	APPROVED / REQUEST_CHANGES	Rubber-stamp fluent text
Acceptance	Run deterministic checks	Final draft and repo state	Publish or block decision	Skip CI because the prose looks good

OpenAI's Agents SDK documents handoffs, guardrails, tools, tracing, and human-in-the-loop patterns. You do not need to use that SDK to borrow the idea. A handoff is just a controlled transfer of work from one role to another. A guardrail is a check that stops bad work before it moves forward.

If you want the simpler role pattern behind this pipeline, read the related guide on the planner-executor-reviewer agent workflow.

For a content site, the handoff artifact matters more than the agent label.

Folder structure that prevents accidental publishing

A simple repository layout can prevent a surprising number of mistakes.

content/briefs/       planner briefs
content/research/     source notes and claim maps
drafts/agents/        unfinished article drafts
content/agents/       published articles only

Do not rely only on a status: draft field if your static site can build files from public content directories. Keep working material out of public article paths. The clean rule is easier for humans and agents to follow:

• briefs live in content/briefs/
• research packets live in content/research/
• unfinished drafts live in drafts/
• accepted articles live in content/<section>/

KnowToAct now filters public article data to published files in public section directories, but the repository rule still stays strict. Drafts do not belong in content/agents/ until acceptance.

What the researcher produces

The researcher should not write the article. The researcher should make the writer less likely to make things up.

A useful research packet includes:

• a source list with URLs and notes;
• a claim-to-source map;
• weak-source warnings;
• conflicting or uncertain information;
• competitor or content-gap notes;
• FAQ candidates.

For this article, the research packet uses official or primary sources where possible: Anthropic for workflow patterns, OpenAI documentation for agent handoffs and guardrails, Google Search Central for helpful content and spam policy, NIST for AI risk framing, OWASP for LLM application risks, and GitHub Docs for CI and protected-branch checks.

That does not mean every source is neutral. Anthropic, OpenAI, and Hermes are vendor or project sources. They are useful for definitions and implementation details. They are not proof that a pipeline will improve traffic, quality, or revenue.

A good research packet says that out loud.

What the writer should avoid

The writer's job is not to turn the research packet into a smoother summary. That is how you get bland AI prose with a source list stapled to the bottom.

The writer should avoid:

• claims that do not map to a source or clear editorial judgment;
• fake personal experience;
• fake case studies;
• fake metrics;
• vendor claims presented as independent facts;
• generic advice like "define your goals" without showing the artifact;
• polished language that says nothing.

A stronger draft gives the reader something to copy: a folder structure, a role table, a task contract, a checklist, or a release rule.

A research-to-writing task contract

Here is the kind of contract the planner can hand to a writer.

task: draft-research-writing-review-agent-pipeline
section: agents
source_brief: content/briefs/2026-05-24-research-writing-review-agent-pipeline.md
source_research: content/research/2026-05-24-research-writing-review-agent-pipeline.md
output_draft: drafts/agents/2026-05-24-research-writing-review-agent-pipeline.md
required_original_elements:
  - role-and-artifact table
  - folder structure
  - reviewer anti-AI-tone checklist
  - release checklist
must_not:
  - publish directly to content/agents/
  - invent sources, metrics, screenshots, or personal experience
  - use generic AI prose or marketing language
  - claim formal compliance with NIST or OWASP
acceptance:
  - fact-checker PASS
  - reviewer APPROVED including anti-AI-tone pass
  - pnpm run ci passes before publication

This looks mechanical, but it solves a real problem. The writer does not have to guess where to put the file, which sources to use, or what the reviewer will block.

The fact-checker checks claims, not vibes

The fact-checker should compare the draft to the research packet and source list. It should not approve a claim just because it sounds plausible.

Use a simple verdict:

Verdict: PASS | REQUEST_CHANGES | BLOCK

Blocking issues:
- ...

Required edits:
- ...

Notes:
- ...

Block the draft if it includes fabricated sources, made-up numbers, unsupported productivity claims, or advice that creates risk without a human approval rule.

Request changes when the draft overstates a source. For example, NIST's AI Risk Management Framework can support a point about governance and risk management. It does not mean your three-agent blog workflow is "NIST compliant." OWASP's LLM Top 10 can support a warning about prompt injection, sensitive information, supply chain issues, or excessive agency. It does not turn the article into a full security guide.

Keep the claims modest. That makes the article more trustworthy.

The reviewer needs an anti-AI-tone pass

Factually correct content can still read like it was assembled by a model trying to please everyone.

The reviewer should run a separate anti-AI-tone pass. Not a vague "make it better" pass. A real gate.

Flag lines like:

• "In today's rapidly evolving landscape..."
• "Let's dive in..."
• "This pivotal workflow underscores..."
• "It's not just about writing, it's about transformation."
• "Experts agree..." without naming the source.
• "seamless, robust, powerful, game-changing"
• "The future of AI content is bright."

The fix is usually not fancy. Use plainer words. Name the artifact. Name the failure. Cut the warm-up sentence.

AI-sounding line	Better direction
"This workflow unlocks high-quality content at scale."	"This workflow makes bad drafts easier to catch before publication."
"Let's explore the key components."	"Start with the handoffs."
"Experts agree that review is crucial."	"Google's spam policies make low-value scaled content a search risk."
"A robust pipeline empowers teams."	"A pipeline should block a draft when the source map is weak."

A reviewer should be willing to reject fluent prose. Fluent is not the same as useful.

CI and acceptance checks

Model review is not enough. Add deterministic checks.

For a content repository, useful checks include:

• validate required frontmatter;
• require at least three source URLs for published articles;
• check duplicate slugs;
• generate public content data only from published files in public section directories;
• build the site;
• verify article pages, section indexes, RSS, and sitemaps.

GitHub Actions can run workflows on events such as push and pull_request. Protected branches can require status checks and reviews before changes merge. That makes a content pipeline more like a software release: the reviewer can approve the article, but the repository still blocks a broken build.

For KnowToAct, the local command is:

pnpm run ci

A draft can exist before CI passes. A published article should not.

When to keep a human in the loop

Do not let the agent pipeline approve everything just because it has multiple roles.

Require human approval before publishing or changing:

• legal, medical, financial, tax, or compliance advice;
• monetized reviews or affiliate comparison pages;
• claims about people, companies, or products that could cause reputational harm;
• ad scripts or tracking scripts;
• DNS, billing, account permissions, or secrets;
• unattended publishing jobs;
• deletion of indexed pages or canonical URL changes.

OWASP's LLM application guidance calls out risks such as prompt injection, sensitive information disclosure, supply chain issues, and excessive agency. Those risks matter more when agents have tools. The answer is not to ban tools. The answer is to limit permissions, log actions, and require approval for high-impact steps.

Draft-to-published release checklist

Before a draft moves from drafts/agents/ into content/agents/, check:

• The draft was written from the approved brief.
• The research packet has at least five usable sources when available.
• Important claims appear in the claim-to-source map or are clearly framed as editorial judgment.
• The fact-checker returned PASS.
• The reviewer returned APPROVED and included an anti-AI-tone pass.
• The article contains at least two original artifacts: table, template, checklist, workflow, folder structure, or code sample.
• Frontmatter is complete.
• ai_assisted: true is present if AI helped.
• affiliate_disclosure: false is correct, or disclosure is visible if monetization exists.
• status is changed to published only at release time.
• pnpm run ci passes.
• The production page, section index, sitemap, and RSS are checked after deploy.

This checklist is intentionally repetitive. Publication mistakes are often boring: a wrong path, a missing source, a draft left in a public directory, a reviewer who approved tone but not claims.

What this pipeline does not solve

A research-writing-review pipeline does not make AI output true. It does not make weak sources strong. It does not make a low-value topic worth publishing.

It gives you better places to say no.

If the brief is vague, stop at the brief gate. If the research packet is thin, stop before writing. If the draft sounds like generic AI filler, stop at review. If the build is broken, stop at acceptance.

That is the practical value of the pipeline. It slows the workflow down just enough to catch the failures that matter.

Sources

• Anthropic Engineering: Building Effective Agents: https://www.anthropic.com/engineering/building-effective-agents
• OpenAI Agents SDK Documentation: https://openai.github.io/openai-agents-python/
• OpenAI Agents SDK: Handoffs: https://openai.github.io/openai-agents-python/handoffs/
• OpenAI Agents SDK: Guardrails: https://openai.github.io/openai-agents-python/guardrails/
• Google Search Central: Creating Helpful, Reliable, People-First Content: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
• Google Search Central: Spam Policies: https://developers.google.com/search/docs/essentials/spam-policies
• NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• OWASP Top 10 for LLM Applications: https://genai.owasp.org/llm-top-10/
• GitHub Actions: Events that Trigger Workflows: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
• GitHub Docs: About Protected Branches: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
• Hermes Agent Documentation: https://hermes-agent.nousresearch.com/docs