How to build a Hermes SEO/GEO swarm workflow

The short answer

A Hermes SEO/GEO swarm is a supervised workflow where different agents handle different parts of organic growth work: research, brief, draft, edit, technical QA, and publishing preparation. The point is not to let five agents publish faster. The point is to stop one agent from doing every job badly.

For beginners, use five roles:

Researcher
Writer
Editor
Technical QA
Publisher

Keep one rule above all roles: no live page changes without human approval.

Why a swarm helps

A single SEO agent tends to blur jobs together. It researches, writes, edits, checks links, invents a title, and declares the page ready. That is risky because the same agent that created the draft may miss its own weak assumptions.

A swarm adds separation:

Role	Main job	Output
Researcher	Collect search, GEO, competitor, and source evidence	Research notes
Writer	Turn approved brief into a draft	Draft Markdown
Editor	Improve structure, clarity, voice, and usefulness	Edited draft
Technical QA	Check links, schema needs, crawl risks, snippets, and indexability	QA report
Publisher	Prepare CMS package after approval	Publish-ready Markdown and metadata

This is still a human-led workflow. Hermes coordinates work, but people approve strategy, facts, technical changes, and publication.

Step 1: create the swarm folders

Use a file handoff system. Do not let agents overwrite each other's work without a trail.

/hermes-seo-agent /swarm /researcher /writer /editor /technical-qa /publisher /briefs /drafts /qa /publish-ready /approvals /prompts researcher.md writer.md editor.md technical-qa.md publisher.md coordinator.md

Each role writes to its own folder first. The coordinator or human reviewer decides what moves forward.

Step 2: write the coordinator prompt

Create prompts/coordinator.md:

You are the Hermes SEO/GEO workflow coordinator. Your job is to assign tasks to role agents and maintain safe handoffs. Rules: - Do not publish or edit live pages. - Do not let the Writer start until the brief is approved. - Do not let the Publisher prepare final CMS fields until Editor and Technical QA pass. - Every role must write its output to the correct folder. - Every role must list assumptions and missing data. - Any technical change requires human approval. - Any external claim requires source verification. Workflow order: 1. Researcher creates research notes. 2. Human approves or revises research direction. 3. Writer creates draft from approved brief. 4. Editor revises draft. 5. Technical QA reviews draft and page risks. 6. Human approves final content. 7. Publisher prepares publish package.

The coordinator prevents parallel chaos. It is the traffic controller.

Step 3: define the Researcher role

Create prompts/researcher.md:

You are the SEO/GEO Researcher. Inputs: - Approved topic or page - Website context - Keyword cluster - GEO prompt map - GSC or Bing data, if available - Competitor/source URLs, if provided Your output goes to /swarm/researcher/[slug]-research.md. Return: 1. Target reader 2. Search intent 3. GEO prompt intent 4. Primary and secondary keywords 5. Related questions 6. Entities to define 7. Source evidence needed 8. Competitor patterns to learn from 9. What not to copy 10. Recommended brief angle 11. Missing data Rules: - Do not write the article. - Do not invent source claims. - Do not use competitor wording. - Mark uncertain claims for verification.

Researcher output should be notes, not prose. If the Researcher starts writing a finished article, stop it.

Step 4: define the Writer role

Create prompts/writer.md:

You are the SEO/GEO Writer. Inputs: - Approved brief - Researcher notes - Brand context - Approval rules Your output goes to /swarm/writer/[slug]-draft.md. Write a beginner-friendly draft that includes: 1. Direct answer near the top 2. Clear section headings 3. Practical steps 4. Tables or checklists where useful 5. GEO answer blocks for approved prompts 6. Internal link placeholders 7. Source placeholders where claims need verification 8. FAQ based on real questions Rules: - Do not add unsupported claims. - Do not publish. - Do not change the brief without noting why. - If evidence is missing, mark [SOURCE NEEDED].

The Writer should not decide whether the article is ready. It creates the first draft only.

Step 5: define the Editor role

Create prompts/editor.md:

You are the SEO/GEO Editor. Inputs: - Writer draft - Approved brief - Researcher notes - Brand context Your output goes to /swarm/editor/[slug]-edited.md. Review and improve: 1. Opening clarity 2. Search intent match 3. Beginner usability 4. Section order 5. Examples 6. Tables and checklists 7. GEO answer extractability 8. Repetition and generic language 9. Unsupported claims 10. FAQ quality Return: - Edited draft - Change summary - Remaining risks - Claims needing source verification Rules: - Do not invent facts. - Do not remove useful specifics. - Do not approve the draft for publication.

The Editor should make the draft clearer and more useful. It should not silently introduce new claims.

Step 6: define the Technical QA role

Create prompts/technical-qa.md:

You are the Technical SEO/GEO QA reviewer. Inputs: - Edited draft - Target URL or planned URL - Internal link plan - Crawl data, if available - Structured data notes, if available Your output goes to /swarm/technical-qa/[slug]-qa.md. Check: 1. Internal links 2. Anchor text accuracy 3. Image alt text 4. Table readability 5. Schema opportunities and risks 6. Snippet eligibility concerns 7. Canonical, indexability, or robots risks if updating an existing page 8. Broken or missing source links 9. Overpromising title/meta 10. Approval requirements Rules: - Do not change technical settings. - Mark technical changes as requiring developer approval. - Do not approve publishing if high-risk issues remain.

Technical QA is where many AI content workflows fail. A good article can still ship with bad links, bad schema assumptions, or risky title changes.

Workflow diagram showing Research, Brief, Draft, Edit, Technical QA, Human Approval, and Publish Package stages with role labels and approval gates.

Step 7: define the Publisher role

Create prompts/publisher.md:

You are the Publisher preparation agent. Inputs: - Final human-approved draft - Editor notes - Technical QA pass report - Metadata requirements - Image assets Your output goes to /swarm/publisher/[slug]-publish-package.md. Prepare: 1. Title 2. Slug 3. Excerpt 4. SEO title 5. Meta description 6. Category 7. Tags 8. Featured image alt text 9. Inline image alt text 10. Final Markdown 11. Source list 12. Publishing checklist Rules: - Do not publish unless the human explicitly approves publishing. - Do not change the approved article without listing the change. - Do not remove source notes or QA warnings.

Publisher is a packaging role. It should not become a secret editor.

Step 8: use file handoffs

A beginner swarm should move work through files:

/researcher/topic-research.md ↓ /briefs/topic-brief.md ↓ /writer/topic-draft.md ↓ /editor/topic-edited.md ↓ /technical-qa/topic-qa.md ↓ /approvals/topic-approval.md ↓ /publisher/topic-publish-package.md

Approval file template:

# Human approval record Topic: Slug: Reviewer: Date: Approved stage: ## Approved files - Research: - Brief: - Draft: - Editor version: - QA report: ## Required changes before publish - ## Final decision - [ ] Approved for draft only - [ ] Approved for CMS staging - [ ] Approved for publishing - [ ] Rejected

This is simple and useful. It gives the workflow memory.

Step 9: run one swarm task

Use a safe first task: create a refresh plan or content brief. Do not start with live publishing.

Coordinator prompt:

Run a supervised SEO/GEO swarm task for this topic: [TOPIC] Goal: Create an approved content brief, not a full article. Use these roles only: 1. Researcher 2. Coordinator Steps: - Researcher creates research notes. - Coordinator turns notes into a brief outline. - Stop for human approval. Do not draft the article yet.

After that works, run a full article workflow:

Run the full supervised SEO/GEO swarm workflow for the approved brief. Use roles in order: 1. Writer 2. Editor 3. Technical QA 4. Publisher preparation Stop after Publisher creates the publish package. Do not publish until human approval is given.

This staged rollout prevents one bad prompt from becoming a live page.

Step 10: resolve conflicts between agents

Agents will disagree. That is useful if handled properly.

Conflict	Example	Resolution rule
Researcher vs Writer	Writer adds a claim not in research	Mark source needed or remove claim
Writer vs Editor	Editor removes a technical detail	Keep detail if it helps reader or source accuracy
Editor vs Technical QA	Editor wants a bold title, QA says it overpromises	Choose accuracy over click appeal
QA vs Publisher	Publisher wants to ship, QA has unresolved link issues	QA blocks publishing
Researcher vs business owner	Research says topic is weak, owner wants it	Label as brand/strategic page, not SEO priority

Create a conflict log:

# Swarm conflict log | Issue | Roles involved | Decision | Reason | Owner | |---|---|---|---|---|

Hermes prompt:

Review the role outputs and identify conflicts. Return: 1. Conflicting recommendations 2. Evidence from each role 3. Risk of each option 4. Recommended decision 5. Human decision needed: yes/no

Do not hide disagreement. Disagreement is often where quality improves.

Step 11: add a swarm QA gate

Create qa/swarm-quality-gate.md:

# Swarm quality gate - [ ] Researcher output exists. - [ ] Brief was approved before drafting. - [ ] Writer did not add unsupported claims. - [ ] Editor improved clarity without changing facts. - [ ] Technical QA checked links, snippets, schema, image alt text, and title/meta risk. - [ ] Publisher used the final approved draft. - [ ] All source-needed notes are resolved or removed. - [ ] Human approval file exists. - [ ] No role published or changed live pages. - [ ] Final package includes title, slug, excerpt, category, tags, images, alt text, and source list.

Run:

Review this project against qa/swarm-quality-gate.md. Return pass/fail for each item. Block publishing if any required file, source verification, or approval is missing.

Beginner example: one article workflow

Topic: How to use Hermes for technical SEO/GEO audits

Stage	Output
Researcher	Notes on crawlability, indexability, snippets, canonicals, schema, Google guidance
Brief	Approved structure and required sources
Writer	First draft with steps and templates
Editor	Clearer beginner language and less generic phrasing
Technical QA	Checks robots/noindex/canonical warnings, link accuracy, snippet claims
Human approval	Confirms source accuracy and technical risk language
Publisher	Final Markdown, category, tags, image alt text, and publish checklist

The value is not speed alone. The value is that each role catches a different kind of failure.

Common mistakes

Mistake	Why it hurts	Better approach
Letting every agent edit the same file	Changes become hard to audit	Use role folders and handoffs
Skipping human approval	Risky claims or technical changes go live	Require approval before publishing
Starting with too many roles	Beginners cannot debug the process	Start with Researcher and Writer, then add roles
Letting Publisher rewrite content	Final package drifts from approved draft	Publisher packages only
No conflict log	Agent disagreements disappear	Record conflicts and decisions
No QA gate	Weak links, claims, and metadata slip through	Block publishing until QA passes

Auspia take

Hermes swarm workflows are useful when they add accountability. They are not useful when they create five agents that all produce more text.

The best beginner setup is conservative: one coordinator, five role prompts, file handoffs, a conflict log, and a human approval record. Once that works, the swarm can handle more volume without turning into a content factory.

If the workflow cannot explain who did what and who approved it, it is not ready for SEO/GEO production.

FAQ

What is a Hermes SEO/GEO swarm?

It is a multi-role workflow where different agents handle research, writing, editing, technical QA, and publishing preparation. The goal is better quality control, not automatic publishing.

Do beginners need five agents immediately?

No. Start with Researcher and Writer. Add Editor, Technical QA, and Publisher after the handoff workflow works.

Can the Publisher agent publish directly?

Not in a safe beginner setup. The Publisher should prepare the CMS package only after human approval.

How does a swarm improve GEO content?

The Researcher maps prompts and evidence, the Writer adds answer blocks, the Editor improves clarity, and Technical QA checks links, snippets, schema, and page risks. Each role improves a different part of GEO readiness.

What is the most important approval gate?

The gate before live changes. No role should publish, update live pages, change metadata, alter internal links, or touch technical settings without human approval.

How do I know if the swarm is working?

It is working when outputs are specific, files are traceable, conflicts are logged, QA catches real issues, and the human reviewer can approve or reject work without reconstructing the whole process.

Continue the Hermes SEO/GEO series

Start here: Hermes SEO/GEO operator guide .
Previous guide: How to use Hermes for a technical SEO/GEO audit .
Next guide: How to use Hermes for weekly SEO/GEO monitoring .
Closely related: How to set up your first Hermes SEO Agent , How to use Hermes for weekly SEO/GEO monitoring .

Sources used

Hermes Agent documentation: https://hermes-agent.nousresearch.com/docs/
Google guidance on creating helpful content: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
Google guidance on using generative AI content: https://developers.google.com/search/docs/fundamentals/using-gen-ai-content

Author: Camille Rhodes, Architect of 300+ AI Content Workflows at Auspia. Camille writes about AI-assisted content workflows, automation, publishing systems, and editorial quality control.