A resposta curta
Um swarm Hermes SEO/GEO é um workflow supervisionado em que diferentes agentes cuidam de partes diferentes do trabalho de crescimento orgânico: pesquisa, brief, rascunho, edição, QA técnico e preparação para publicação. O objetivo não é deixar cinco agentes publicarem mais rápido. O objetivo é impedir que um único agente faça todos os trabalhos mal.
Para iniciantes, use cinco papéis:
- Researcher
- Writer
- Editor
- Technical QA
- Publisher
Mantenha uma regra acima de todos os papéis: nenhuma mudança em página ativa sem aprovação humana.
Por que um swarm ajuda
Um único agente de SEO tende a misturar funções. Ele pesquisa, escreve, edita, checa links, inventa um title e declara a página pronta. Isso é arriscado porque o mesmo agente que criou o rascunho pode não perceber suas próprias suposições fracas.
Um swarm adiciona separação:
| Papel | Trabalho principal | Saída |
|---|---|---|
| Researcher | Coletar evidências de busca, GEO, concorrentes e fontes | Notas de pesquisa |
| Writer | Transformar o brief aprovado em rascunho | Markdown de rascunho |
| Editor | Melhorar estrutura, clareza, voz e utilidade | Rascunho editado |
| Technical QA | Checar links, necessidades de schema, riscos de crawl, snippets e indexabilidade | Relatório de QA |
| Publisher | Preparar pacote de CMS após aprovação | Markdown e metadados prontos para publicação |
Ainda é um workflow liderado por humanos. Hermes coordena o trabalho, mas pessoas aprovam estratégia, fatos, mudanças técnicas e publicação.
Passo 1: crie as pastas do swarm
Use um sistema de passagem por arquivos. Não deixe agentes sobrescreverem o trabalho uns dos outros sem rastro.
/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
Cada papel escreve primeiro em sua própria pasta. O coordenador ou revisor humano decide o que avança.
Passo 2: escreva o prompt do coordenador
Crie prompts/coordinator.md:
Você é o coordenador de workflow Hermes SEO/GEO.
Seu trabalho é atribuir tarefas a agentes por papel e manter handoffs seguros.
Regras:
- Não publique nem edite páginas ativas.
- Não deixe o Writer começar até que o brief seja aprovado.
- Não deixe o Publisher preparar campos finais de CMS até que Editor e Technical QA sejam aprovados.
- Todo papel deve escrever sua saída na pasta correta.
- Todo papel deve listar suposições e dados ausentes.
- Qualquer mudança técnica exige aprovação humana.
- Qualquer afirmação externa exige verificação de fonte.
Ordem do workflow:
1. Researcher cria notas de pesquisa.
2. Humano aprova ou revisa a direção da pesquisa.
3. Writer cria rascunho a partir do brief aprovado.
4. Editor revisa o rascunho.
5. Technical QA revisa o rascunho e riscos da página.
6. Humano aprova o conteúdo final.
7. Publisher prepara o pacote de publicação.
O coordenador evita caos paralelo. Ele é o controlador de tráfego.
Passo 3: defina o papel Researcher
Crie prompts/researcher.md:
Você é o Researcher de SEO/GEO.
Entradas:
- Tópico ou página aprovada
- Contexto do site
- Cluster de palavra-chave
- Mapa de prompts GEO
- Dados do GSC ou Bing, se disponíveis
- URLs de concorrentes/fontes, se fornecidas
Sua saída vai para /swarm/researcher/[slug]-research.md.
Retorne:
1. Leitor-alvo
2. Intenção de busca
3. Intenção de prompt GEO
4. Palavras-chave primárias e secundárias
5. Perguntas relacionadas
6. Entidades a definir
7. Evidência de fonte necessária
8. Padrões de concorrentes dos quais aprender
9. O que não copiar
10. Ângulo de brief recomendado
11. Dados ausentes
Regras:
- Não escreva o artigo.
- Não invente afirmações de fonte.
- Não use a redação de concorrentes.
- Marque afirmações incertas para verificação.
A saída do Researcher deve ser notas, não prosa final. Se o Researcher começar a escrever um artigo pronto, pare.
Passo 4: defina o papel Writer
Crie prompts/writer.md:
Você é o Writer de SEO/GEO.
Entradas:
- Brief aprovado
- Notas do Researcher
- Contexto da marca
- Regras de aprovação
Sua saída vai para /swarm/writer/[slug]-draft.md.
Escreva um rascunho amigável para iniciantes que inclua:
1. Resposta direta perto do topo
2. Headings claros
3. Passos práticos
4. Tabelas ou checklists quando úteis
5. Blocos de resposta GEO para prompts aprovados
6. Placeholders de links internos
7. Placeholders de fonte onde afirmações precisam de verificação
8. FAQ baseada em perguntas reais
Regras:
- Não adicione afirmações sem suporte.
- Não publique.
- Não mude o brief sem explicar por quê.
- Se a evidência estiver ausente, marque [FONTE NECESSÁRIA].
O Writer não deve decidir se o artigo está pronto. Ele cria apenas o primeiro rascunho.
Passo 5: defina o papel Editor
Crie prompts/editor.md:
Você é o Editor de SEO/GEO.
Entradas:
- Rascunho do Writer
- Brief aprovado
- Notas do Researcher
- Contexto da marca
Sua saída vai para /swarm/editor/[slug]-edited.md.
Revise e melhore:
1. Clareza da abertura
2. Correspondência com intenção de busca
3. Usabilidade para iniciantes
4. Ordem das seções
5. Exemplos
6. Tabelas e checklists
7. Extração de respostas GEO
8. Repetição e linguagem genérica
9. Afirmações sem suporte
10. Qualidade do FAQ
Retorne:
- Rascunho editado
- Resumo das mudanças
- Riscos restantes
- Afirmações que precisam de verificação de fonte
Regras:
- Não invente fatos.
- Não remova detalhes úteis.
- Não aprove o rascunho para publicação.
O Editor deve tornar o rascunho mais claro e útil. Ele não deve introduzir novas afirmações silenciosamente.
Passo 6: defina o papel Technical QA
Crie prompts/technical-qa.md:
Você é o revisor de Technical SEO/GEO QA.
Entradas:
- Rascunho editado
- URL-alvo ou URL planejada
- Plano de links internos
- Dados de crawl, se disponíveis
- Notas de dados estruturados, se disponíveis
Sua saída vai para /swarm/technical-qa/[slug]-qa.md.
Verifique:
1. Links internos
2. Precisão de texto de âncora
3. Alt text de imagens
4. Legibilidade de tabelas
5. Oportunidades e riscos de schema
6. Preocupações de elegibilidade de snippet
7. Riscos de canonical, indexabilidade ou robots se estiver atualizando uma página existente
8. Links de fonte quebrados ou ausentes
9. Title/meta prometendo demais
10. Requisitos de aprovação
Regras:
- Não altere configurações técnicas.
- Marque mudanças técnicas como exigindo aprovação de desenvolvedor.
- Não aprove publicação se questões de alto risco permanecerem.
Technical QA é onde muitos workflows de conteúdo com IA falham. Um bom artigo ainda pode sair com links ruins, suposições de schema ruins ou mudanças arriscadas de title.
Passo 7: defina o papel Publisher
Crie prompts/publisher.md:
Você é o agente de preparação para publicação.
Entradas:
- Rascunho final aprovado por humano
- Notas do Editor
- Relatório aprovado do Technical QA
- Requisitos de metadados
- Assets de imagem
Sua saída vai para /swarm/publisher/[slug]-publish-package.md.
Prepare:
1. Title
2. Slug
3. Excerpt
4. SEO title
5. Meta description
6. Categoria
7. Tags
8. Alt text da imagem destacada
9. Alt text de imagens inline
10. Markdown final
11. Lista de fontes
12. Checklist de publicação
Regras:
- Não publique a menos que o humano aprove explicitamente a publicação.
- Não altere o artigo aprovado sem listar a mudança.
- Não remova notas de fonte ou avisos de QA.
Publisher é um papel de empacotamento. Ele não deve virar um editor secreto.
Passo 8: use handoffs por arquivos
Um swarm iniciante deve mover o trabalho por arquivos:
/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
Template de arquivo de aprovação:
# Registro de aprovação humana
Tópico:
Slug:
Revisor:
Data:
Etapa aprovada:
## Arquivos aprovados
- Pesquisa:
- Brief:
- Rascunho:
- Versão do Editor:
- Relatório de QA:
## Mudanças obrigatórias antes da publicação
-
## Decisão final
- [ ] Aprovado apenas para rascunho
- [ ] Aprovado para staging no CMS
- [ ] Aprovado para publicação
- [ ] Rejeitado
Isso é simples e útil. Dá memória ao workflow.
Passo 9: rode uma tarefa de swarm
Use uma primeira tarefa segura: criar um plano de atualização ou brief de conteúdo. Não comece com publicação ao vivo.
Prompt do coordenador:
Rode uma tarefa supervisionada de swarm SEO/GEO para este tópico:
[TÓPICO]
Objetivo:
Criar um brief de conteúdo aprovado, não um artigo completo.
Use apenas estes papéis:
1. Researcher
2. Coordinator
Etapas:
- Researcher cria notas de pesquisa.
- Coordinator transforma notas em um outline de brief.
- Pare para aprovação humana.
Ainda não rascunhe o artigo.
Depois que isso funcionar, rode um workflow completo de artigo:
Rode o workflow completo supervisionado SEO/GEO swarm para o brief aprovado.
Use papéis na ordem:
1. Writer
2. Editor
3. Technical QA
4. Preparação do Publisher
Pare depois que Publisher criar o pacote de publicação.
Não publique até que a aprovação humana seja dada.
Esse rollout em etapas impede que um prompt ruim vire uma página publicada.
Passo 10: resolva conflitos entre agentes
Agentes vão discordar. Isso é útil se for bem tratado.
| Conflito | Exemplo | Regra de resolução |
|---|---|---|
| Researcher vs Writer | Writer adiciona uma afirmação que não está na pesquisa | Marcar fonte necessária ou remover afirmação |
| Writer vs Editor | Editor remove um detalhe técnico | Manter detalhe se ajuda o leitor ou a precisão da fonte |
| Editor vs Technical QA | Editor quer um title ousado; QA diz que promete demais | Escolher precisão em vez de apelo de clique |
| QA vs Publisher | Publisher quer enviar, QA tem problemas de links não resolvidos | QA bloqueia publicação |
| Researcher vs dono do negócio | Pesquisa diz que o tópico é fraco; dono quer mesmo assim | Rotular como página de marca/estratégica, não prioridade de SEO |
Crie um log de conflitos:
# Log de conflitos do swarm
| Problema | Papéis envolvidos | Decisão | Motivo | Responsável |
|---|---|---|---|---|
Prompt para Hermes:
Revise as saídas dos papéis e identifique conflitos.
Retorne:
1. Recomendações conflitantes
2. Evidência de cada papel
3. Risco de cada opção
4. Decisão recomendada
5. Decisão humana necessária: sim/não
Não esconda discordâncias. Discordância é muitas vezes onde a qualidade melhora.
Passo 11: adicione um gate de QA do swarm
Crie qa/swarm-quality-gate.md:
# Gate de qualidade do swarm
- [ ] Saída do Researcher existe.
- [ ] Brief foi aprovado antes do rascunho.
- [ ] Writer não adicionou afirmações sem suporte.
- [ ] Editor melhorou clareza sem mudar fatos.
- [ ] Technical QA verificou links, snippets, schema, alt text de imagens e risco de title/meta.
- [ ] Publisher usou o rascunho final aprovado.
- [ ] Todas as notas de fonte necessária foram resolvidas ou removidas.
- [ ] Arquivo de aprovação humana existe.
- [ ] Nenhum papel publicou ou alterou páginas ativas.
- [ ] Pacote final inclui title, slug, excerpt, categoria, tags, imagens, alt text e lista de fontes.
Rode:
Revise este projeto contra qa/swarm-quality-gate.md.
Retorne aprovado/reprovado para cada item.
Bloqueie publicação se qualquer arquivo obrigatório, verificação de fonte ou aprovação estiver ausente.
Exemplo iniciante: workflow de um artigo
Tópico: Como usar Hermes para auditorias técnicas SEO/GEO
| Etapa | Saída |
|---|---|
| Researcher | Notas sobre rastreabilidade, indexabilidade, snippets, canonicals, schema, orientação do Google |
| Brief | Estrutura aprovada e fontes necessárias |
| Writer | Primeiro rascunho com passos e templates |
| Editor | Linguagem mais clara para iniciantes e menos frases genéricas |
| Technical QA | Checa avisos de robots/noindex/canonical, precisão de links, afirmações de snippet |
| Aprovação humana | Confirma precisão de fontes e linguagem de risco técnico |
| Publisher | Markdown final, categoria, tags, alt text de imagens e checklist de publicação |
O valor não é apenas velocidade. O valor é que cada papel captura um tipo diferente de falha.
Erros comuns
| Erro | Por que prejudica | Abordagem melhor |
|---|---|---|
| Deixar todo agente editar o mesmo arquivo | Mudanças ficam difíceis de auditar | Use pastas de papel e handoffs |
| Pular aprovação humana | Afirmações arriscadas ou mudanças técnicas vão ao ar | Exija aprovação antes de publicar |
| Começar com papéis demais | Iniciantes não conseguem depurar o processo | Comece com Researcher e Writer, depois adicione papéis |
| Deixar Publisher reescrever conteúdo | Pacote final se distancia do rascunho aprovado | Publisher apenas empacota |
| Não ter log de conflitos | Discordâncias entre agentes desaparecem | Registre conflitos e decisões |
| Não ter gate de QA | Links, afirmações e metadados fracos passam | Bloqueie publicação até QA passar |
A visão da Auspia
Workflows Hermes swarm são úteis quando adicionam responsabilidade. Eles não são úteis quando criam cinco agentes que apenas produzem mais texto.
A melhor configuração para iniciantes é conservadora: um coordenador, cinco prompts por papel, handoffs por arquivo, log de conflitos e registro de aprovação humana. Quando isso funciona, o swarm consegue lidar com mais volume sem virar uma fábrica de conteúdo.
Se o workflow não consegue explicar quem fez o quê e quem aprovou, ele não está pronto para produção SEO/GEO.
FAQ
O que é um Hermes SEO/GEO swarm?
É um workflow multi-papel em que agentes diferentes cuidam de pesquisa, escrita, edição, QA técnico e preparação para publicação. O objetivo é melhor controle de qualidade, não publicação automática.
Iniciantes precisam de cinco agentes imediatamente?
Não. Comece com Researcher e Writer. Adicione Editor, Technical QA e Publisher depois que o workflow de handoff funcionar.
O agente Publisher pode publicar diretamente?
Não em uma configuração segura para iniciantes. O Publisher deve preparar o pacote de CMS apenas depois de aprovação humana.
Como um swarm melhora conteúdo GEO?
O Researcher mapeia prompts e evidências, o Writer adiciona blocos de resposta, o Editor melhora clareza e o Technical QA checa links, snippets, schema e riscos de página. Cada papel melhora uma parte diferente da prontidão GEO.
Qual é o gate de aprovação mais importante?
O gate antes de mudanças ao vivo. Nenhum papel deve publicar, atualizar páginas ativas, alterar metadados, mexer em links internos ou tocar em configurações técnicas sem aprovação humana.
Como sei se o swarm está funcionando?
Ele está funcionando quando as saídas são específicas, os arquivos são rastreáveis, conflitos são registrados, o QA captura problemas reais e o revisor humano consegue aprovar ou rejeitar o trabalho sem reconstruir todo o processo.
Continue a série Hermes SEO/GEO
- Comece aqui: Guia do operador Hermes SEO/GEO .
- Guia anterior: Como fazer uma auditoria técnica de SEO/GEO com Hermes .
- Próximo guia: Como usar Hermes para monitoramento semanal de SEO/GEO .
- Relacionados: Como configurar seu primeiro Hermes SEO Agent , Como usar Hermes para monitoramento semanal de SEO/GEO .
Referências
- Hermes: https://hermes-agent.nousresearch.com/docs/
- Conteúdo útil: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
- Conteúdo com IA: https://developers.google.com/search/docs/fundamentals/using-gen-ai-content
Autora: Camille Rhodes, arquiteta de mais de 300 workflows de conteúdo com IA na Auspia. Camille escreve sobre workflows de conteúdo assistidos por IA, automação, sistemas de publicação e controle de qualidade editorial.
