Pipeline editorial IA multi-agente em produção: 5 agentes, ~85% menos custo

Todo blog de produto SaaS técnico cai no mesmo dilema: você precisa publicar conteúdo de qualidade em volume razoável, mas contratar um time editorial custa caro e gerar com um LLM single-shot produz texto genérico que o Google reconhece e despreza. A resposta arquitetural para esse problema é um pipeline editorial multi-agente — vários LLMs especializados, cada um responsável por uma camada do trabalho, orquestrados em sequência com paralelização onde possível.

Este artigo descreve, sem dourar a pílula, como rodamos esse pipeline em produção na ZAP API. Os agentes geram os artigos que você está lendo. Não é feature do produto — é engenharia interna que decidimos abrir porque o pattern é replicável e a maioria dos blogs técnicos brasileiros ainda não tem nada parecido.

Importante: esses agentes são internos do painel super-admin. Não fazem parte da API que o cliente consome. O que você lê aqui é arquitetura — útil pra você aplicar no seu próprio sistema editorial ou de geração de conteúdo.

Por que multi-agente e não um único mega-prompt

A primeira tentativa de quase todo mundo é: "vou colocar tudo num prompt gigante, pedir o artigo pronto, e pronto." Funciona para um post. Para volume, quebra em três pontos:

• Janela de contexto desperdiçada — você cola pesquisa de keyword, brief SERP, exemplos de tom de voz, regras de SEO técnico e instrução de redação no mesmo prompt. O modelo dilui atenção.
• Sem checkpoints de qualidade — se a saída final estiver ruim, você refaz tudo. Não dá pra ajustar só a estrutura mantendo a pesquisa.
• Custo desbalanceado — usa um modelo caro (necessário para a redação) em tarefas que um modelo barato resolveria igual (extrair keywords, gerar outline estruturado).

Multi-agente resolve os três: cada agente tem prompt enxuto e específico, cada saída é validável independentemente, e você escolhe o modelo certo para cada tarefa. Na nossa arquitetura atual, 4 dos 5 agentes rodam em Claude Haiku (barato e estruturado) e só o redator usa Sonnet (caro mas com prosa boa). Resultado: custo por artigo cai ~85% sem perder qualidade — porque Haiku não é "Sonnet pior", é "Sonnet otimizado pra outra coisa".

Os 5 agentes especializados

1. KeywordAgent — pesquisa estruturada

Recebe um tópico ("api whatsapp para clínicas") e devolve um cluster: head terms (alto volume, alta competição), body terms (médio volume, médio competição) e long-tail (baixo volume, baixa competição). Cada termo vem com volume estimado em buscas/mês no Brasil, dificuldade (Baixa/Média/Alta) e intenção (informacional/comercial/transacional/navegacional). Plus: mapeia o cluster no funil TOFU/MOFU/BOFU para que o redator saiba qual fase do funil o artigo atende.

Detalhe crítico: o agente não inventa volumes. Antes da chamada LLM, fazemos enrichment via SerpAPI + Google Ads Keyword Planner. Os volumes reais entram no prompt como input. O LLM só faz scoring e priorização — não chuta números. Isso é diferença entre "blog que rankeia" e "blog que escreve sobre o que ele acha que rankeia".

2. ContentArchitectAgent — outline estruturado

Recebe a keyword recomendada + o cluster + um brief SERP rico (featured snippet atual do Google, lista de "People Also Ask", H2s comuns dos top concorrentes, gaps de cobertura — coisas que ninguém tá falando). Devolve a estrutura completa: título H1 (≤65 chars), meta description com CTA (≤155 chars), slug, lista de H2 sections com purpose explicado, 5 FAQ baseadas em perguntas reais do PAA, CTA text, schemaType (TechArticle/HowTo/FAQ), internalLinks sugeridos, targetLength.

O targetLength é importante: alvo é 15% acima da média dos top concorrentes. Não é arbitrário — Google premia conteúdo mais completo que o que já rankeia, mas não exponencialmente; 15% é o ponto onde valor adicional supera dispersão.

3. ContentWriterAgent — redator

O único agente em modelo caro (Claude Sonnet). Recebe outline + cluster + brief SERP. Escreve o HTML completo do artigo com regras explícitas: primeiro parágrafo responde à intenção de busca em ≤150 chars (otimização para AI Overviews/Featured Snippet), CTA no meio e no fim, exemplos de código reais quando relevante, distribuição natural de keywords semânticas (LSI), schema FAQ no final.

Aqui rola um truque que economiza muito: prompt caching. O system prompt do redator tem ~1500 tokens (regras de tom, contexto do produto, exemplos de E-E-A-T). Em providers que suportam (Anthropic é o mais maduro), você marca o system prompt como cacheável com cache_control: ephemeral. Custo de input cai 90% nas chamadas subsequentes dentro de 5 minutos. Em retry de artigo (quando validação falha e regeramos), economia é imediata.

4. SocialAgent — distribuição multi-rede

Pega o artigo pronto e gera, em uma única chamada LLM, posts adaptados para 5 redes: Instagram (script de Reel 30-60s + carrossel 5 slides + Story + 15 hashtags mix), YouTube (título + descrição com keyword nas 2 primeiras linhas + 20 tags + timestamps + 2 scripts de Shorts), LinkedIn (post de 150-300 palavras + intro para artigo nativo), X/Twitter (thread de 5 tweets com gancho forte), WhatsApp (mensagem informal para grupo/canal).

Por que tudo numa só chamada? Porque o conteúdo de origem é o mesmo. Várias chamadas com contexto repetido = desperdício de input cost. Uma chamada com instruções claras de output estruturado funciona bem em modelo barato.

5. TechnicalAgent — auditor SEO técnico

Independente do conteúdo — audita a infraestrutura SEO do site. Recebe contexto da stack (schemas implementados, sitemap, robots, canonical, framework). Devolve score 0-100, lista de passed (o que está OK), warnings (com fix sugerido), criticals (problemas urgentes), schemas adicionais recomendados para o tipo de produto, e top 5 priorityActions ordenadas por impacto.

O auditor não muda a cada artigo — a stack do site é a mesma. Mas roda no pipeline porque o admin que dispara o gerador também quer um relatório atualizado do estado SEO técnico geral. Roda em paralelo com o outline (próximo bloco) — não tem dependência entre eles.

Paralelização: onde economizar tempo de parede

A ordem natural do pipeline parece ser sequencial: keyword → outline → writer → social → audit. Mas vários passos não dependem um do outro. Implementação ingênua roda 5 chamadas em série e leva 3-4 minutos. Implementação otimizada roda em ~90 segundos.

// Pseudocódigo do orquestrador (TypeScript)
async function runPipeline(topic: string) {
  // 1. Keywords sempre primeiro (todo mundo depende)
  const keywords = await runKeywordAgent(topic);
  const { brief } = await enrichKeywordData(keywords.recommended);

  // 2. Outline + Audit em PARALELO — não dependem um do outro
  const [outline, audit] = await Promise.all([
    runContentArchitectAgent(keywords.recommended, keywords, brief),
    runTechnicalAgent(stackContext),
  ]);

  // 3. Writer depende do outline
  const article = await runContentWriterAgent(outline, keywords, brief);

  // 4. Social depende do artigo pronto
  const social = await runSocialAgent(article);

  // 5. Executive summary com tudo
  const summary = await runSummaryAgent({ keywords, article, audit });

  return { keywords, outline, article, social, audit, summary };
}

Esse Promise.all economiza ~30 segundos sozinho. Em volume de 30 artigos/mês, são 15 minutos. Pode parecer pouco — mas o ponto não é o tempo absoluto, é o feedback loop: admin clica "Gerar" e vê o resultado antes do café acabar, não depois.

Background job pattern: HTTP 202 + polling

Pipeline editorial leva 90-150 segundos. Isso destrói qualquer chamada HTTP síncrona — nginx default corta em 60s, Cloudflare free tier em ~100s, e mesmo aumentando timeouts, request HTTP de 2min é experiência ruim (cliente acha que travou, retenta, dobra a carga).

Padrão correto é background job assíncrono:

1. POST /seo/orchestrate cria um registro SeoJob com status pending, dispara o worker via setImmediate e retorna HTTP 202 Accepted com {jobId} em <1 segundo.
2. Worker processa em background, atualiza progress_stage a cada etapa (keywords → outline → writing → optimizing → done).
3. Frontend faz polling em GET /seo/jobs/:id a cada 4 segundos. Quando status=ready, lê result. Se status=failed, lê errorMessage e mostra retry.

Convenção REST: 202 (Accepted) sinaliza "aceitei, vou processar, volta pra perguntar". 200 (OK) implicaria que o recurso já está pronto — semanticamente errado para job assíncrono.

Defensive validation: cast TS é mentira em runtime

Cada agente parsea JSON da resposta do LLM:

const raw = await chat(profile, system, user);
const result = JSON.parse(raw) as ArticleContent;

Esse as ArticleContent é o ponto mais frágil de todo pipeline IA em produção. Cast TypeScript não valida nada em runtime — é só uma promessa para o compilador. Se o LLM responde JSON válido mas com shape parcial (faltando title, ou com contentHtml truncado por hit no max_tokens), o cast passa silenciosamente. O dado tóxico propaga até o frontend, que tenta renderizar result.article.title.split(" ") e crasha com Cannot read properties of undefined.

Solução: gate de validação runtime antes de persistir. No worker, depois do parse:

const result = JSON.parse(raw);
const missing: string[] = [];
if (!result.article) missing.push("article");
if (!result.article?.title) missing.push("article.title");
if (!result.article?.contentHtml) missing.push("article.contentHtml");
if (!result.article?.slug) missing.push("article.slug");

if (missing.length > 0) {
  await job.update({
    status: "failed",
    errorMessage: `Pipeline retornou resposta incompleta (campos faltando: ${missing.join(", ")}). Tente novamente — geralmente é falha transitória do provider.`,
  });
  return;
}

// Só agora persiste como ready
await job.update({ status: "ready", result });

Esse gate aceitar é negociável; o que NÃO é negociável é a defesa em camadas: validar no worker (perto da fronteira externa), validar no frontend antes de renderizar, e ter guard JSX explícito ({result && result.article && ...}). Em 3 camadas, render nunca quebra com mensagem técnica para o usuário.

Para profundidade nessa parte, vale ler também nosso artigo sobre LLM Adapter multi-provider — o padrão de validação é o mesmo independente do provider.

Quanto custa de verdade

Sem revelar valores absolutos por motivos óbvios, a ordem de grandeza:

• Pré-refator (tudo em GPT-4 / GPT-4o single-shot): custo X por artigo
• Pós-refator (multi-agente Claude Sonnet + Haiku com prompt caching): custo ~0.15X por artigo

Economia de ~85%, qualidade igual ou superior (Sonnet escreve prosa melhor que GPT-4 em pt-BR, na nossa avaliação manual de saída). Adicione SerpAPI (~$50/mês para o plano que usamos) e Google Ads Keyword Planner (gratuito mas exige conta de Google Ads ativa), e você tem o stack completo por uma fração do que um redator humano custaria.

Importante: esse cálculo só fecha se o conteúdo for bom de verdade. Conteúdo IA mediano não rankeia mais — Google E-E-A-T penaliza com força. O pipeline multi-agente só faz sentido se cada agente é genuinamente bom no que faz, e se a saída passa por validação editorial humana antes de publicar. Não é mágica de "press button, get article".

Curioso para ver o pipeline rodando ao vivo? Crie uma conta grátis na ZAP API — o painel é onde construímos tudo isso. Começar trial de 7 dias (sem cartão, sem aprovação).

O que escolher como engenheiro

Se você está pensando em montar algo parecido no seu produto, três decisões importam mais que o resto:

1. Adapter multi-provider desde o dia 1 — não acople ao SDK de um provider único. Migrações forçadas (deprecation, mudança de pricing, geopolítica de IA) custam refactor em N pontos do código se você foi single-vendor.
2. Profile lógico por tarefa, não por preferência — Sonnet para prosa, Haiku para JSON estruturado, Flash para volume com contexto grande. Cada tarefa tem o modelo certo; usar Sonnet em tudo é desperdício de dinheiro.
3. Background job com polling — qualquer tarefa que passa de 30s vira async. Frontend faz polling, backend tem retry idempotente, worker tem lock distribuído (Redis) para não duplicar em deploys com replicas.

FAQ — Pipeline editorial IA em produção

Vocês geram os artigos automaticamente sem revisão humana?

Não. O pipeline gera um rascunho de altíssima qualidade, mas todo artigo passa por revisão editorial antes de virar produção. O LLM é redator parceiro, não substituto. A revisão checa: fatos técnicos, tom de voz, exemplos de código (sempre testamos antes de publicar), links internos válidos, e se a recomendação faz sentido para o leitor real do nosso ICP.

Por que Claude e não GPT?

Decisão técnica, não ideológica. Em testes blind side-by-side, Claude Sonnet 4.5 produziu prosa em português brasileiro melhor que GPT-4o (menos americanismos, melhor controle de tom). Claude Haiku 4.5 acerta JSON estruturado com mais consistência que GPT-4o-mini. E Anthropic tem prompt caching maduro, que reduz custo dramático em retry. Nada impede você de fazer o oposto — o LlmAdapter abstrai a escolha.

Quanto tempo levou para construir esse pipeline?

Da primeira chamada LLM ao pipeline orquestrado em produção: ~3 semanas de trabalho focado, distribuído ao longo de 6-8 semanas reais (intercalado com features do produto). Estimativa pessimista: planeje 4-6 semanas se você já tem experiência com APIs LLM, 8-12 semanas se for sua primeira integração séria.

Posso usar esse pipeline para gerar conteúdo em outro nicho?

O esqueleto é replicável. O que muda é: (1) system prompt de cada agente — específico do seu nicho/produto/voz; (2) seed keywords e categorias do funil; (3) regras de E-E-A-T específicas (compliance médico exige fontes diferentes de e-commerce). Os agentes em si (keyword/architect/writer/social/audit) são padrão de qualquer pipeline editorial sério.

Dá para rodar sem SerpAPI / Google Ads Keyword Planner?

Dá, mas a qualidade despenca. SerpAPI traz featured snippet atual, People Also Ask, headings dos concorrentes, related searches. Google Ads KP traz volumes reais. Sem isso, o agente de keyword chuta (ou pior: o LLM alucina volumes que parecem reais mas são inventados). Se o orçamento é zero, dá para usar scraping manual + Ubersuggest/AnswerThePublic free tier, mas é dor de cabeça operacional grande.

O pipeline funciona para conteúdo curto também (LinkedIn post, e-mail marketing)?

Funciona, mas é overengineering. Para conteúdo de até 500 palavras, single-shot com prompt bem feito em Haiku resolve com qualidade. Multi-agente compensa a partir de ~1500 palavras, onde estrutura, pesquisa e tom precisam de fases distintas.

Vocês open-source esse pipeline?

Os agentes são internos do nosso painel super-admin, integrados com nosso DB e auth. Não faz sentido open-source o código tal como está. Mas o pattern arquitetural está descrito neste artigo — você pode aplicar em qualquer stack. O artigo sobre LlmAdapter detalha a abstração de provider; o artigo sobre Radar SEO mostra a camada de descoberta de oportunidades.

Construa em cima de uma API que já pensou nisso. A ZAP API foi desenhada com a mesma engenharia que descrevemos aqui — defensive validation, background jobs com retry idempotente, multi-provider para serviços críticos. Comece grátis, 7 dias de trial sem cartão.