Três padrões cobrem 90% dos casos reais: paralelo independente (todos ao mesmo tempo, sem dependências), pipeline (A entrega para B que entrega para C) e fan-out (um dispara muitos que convergem num resultado). Entender as diferenças entre eles — especialmente o custo escondido do agent teams — é o que separa quem projeta sistemas de quem apenas usa subagentes.
↑ Três topologias: cada uma tem casos de uso, custo e latência diferentes.
Conteúdo detalhado
⚡ Paralelo independente
O padrão mais simples e o mais poderoso quando os jobs não dependem um do outro. Você tem N tarefas que podem rodar ao mesmo tempo, cada uma em seu próprio subagente, e o maestro coleta os resultados no final. Nenhum subagente precisa esperar o outro — o tempo total é o do mais lento, não a soma de todos.
📐 A regra dos 10+ arquivos
Heurística prática: se o job exige ler 10 ou mais arquivos — ou revisar 10 ou mais capítulos, PDFs, ou qualquer unidade de trabalho — você provavelmente está olhando para um candidato a paralelo. Acima desse volume, o custo de sequenciar supera o overhead de orquestrar.
# vs
10 arquivos paralelo (sub por arquivo): ~4 min
Maestro identifica N jobs independentes
Ele verifica: "cada job pode rodar sem saber o resultado dos outros?" Se sim, é candidato.
Dispara todos de uma vez
Cada subagente abre sua própria janela. Todos rodam em simultâneo, sem fila.
Coleta os relatórios
O maestro espera todos terminarem e sintetiza. Você só vê o resultado final — limpo.
N jobs sem dependência entre si rodando ao mesmo tempo, cada um num subagente próprio.
É o padrão que dá saltos reais de velocidade — tempo total = mais lento, não soma. Saber identificar quando aplicar é a habilidade central deste módulo.
independência · disparo simultâneo · tempo do mais lento · regra dos 10+ arquivos.
🔗 Pipeline: A → B → C
Quando o resultado de um agente é a entrada do próximo, você tem um pipeline. Não há paralelismo aqui — o fluxo é sequencial por necessidade. O ganho não é velocidade: é especialização. Cada etapa tem um agente focado só naquilo, com ferramentas e instruções próprias. Pesquisar é diferente de redigir; redigir é diferente de revisar.
✓ Use pipeline quando
- ✓A saída de A é a entrada de B (dependência real)
- ✓Cada etapa precisa de ferramentas diferentes
- ✓A ordem importa (pesquisa → rascunho → revisão)
- ✓Você quer separar responsabilidades claramente
✗ Não use pipeline quando
- ✗Os jobs são independentes (desperdício de latência)
- ✗A dependência é falsa — você só quer serializar
- ✗A tarefa é simples o bastante para um único agente
📊 Exemplo canônico: pesquisa → rascunho → revisão
Cada agente pode usar Haiku, Sonnet ou Opus dependendo da complexidade da etapa.
Cadeia de agentes onde a saída de um vira entrada do próximo. Sequencial por dependência.
Especialização por etapa supera um único agente generalista. Separar responsabilidades reduz erros e facilita ajustes finos.
dependência real · especialização por etapa · pipeline ≠ paralelo · ordem importa.
📡 Fan-out: um dispara muitos, um coleta
Fan-out é paralelo com convergência explícita: o maestro dispara N subagentes e depois sintetiza os relatórios deles num único resultado. É o padrão da "demo das 5 personas" — cada subagente usa uma lente diferente, mas todos entregam ao mesmo maestro que compõe a visão final.
🎯 O que diferencia fan-out do paralelo puro
Paralelo puro
Jobs diferentes que não precisam ser combinados. Ex.: compilar 15 módulos.
Fan-out
Múltiplas perspectivas sobre o mesmo objeto, sintetizadas num relatório. Ex.: 5 personas revisam o mesmo livro.
💡 Fan-out x 15 capítulos
Precisa revisar um livro de 15 capítulos? Fan-out: 1 subagente por capítulo, todos rodando ao mesmo tempo. O maestro coleta 15 relatórios e produz o sumário editorial. Sem fan-out, você leria 15 capítulos em série no mesmo contexto — esgotando-o antes do capítulo 10.
Variante do paralelo onde o maestro explicitamente converge os resultados de N subagentes num único output.
É o padrão para diversidade de perspectivas (múltiplas lentes, revisão adversarial, cobertura completa). A síntese final é o que agrega valor.
convergência explícita · múltiplas perspectivas · síntese final · fan-out ≠ paralelo sem coordenação.
💬 Subagente × Agent Teams — o custo escondido
Agent teams são quando múltiplos agentes conversam entre si — cada mensagem de um agente para outro custa tokens. Um subagente normal não conversa: recebe um briefing, trabalha isolado e entrega um relatório. Em agent teams, a conversa em si tem custo — e esse custo pode superar o valor entregue se não for controlado.
✓ Subagente (padrão)
- ✓Recebe briefing, trabalha isolado
- ✓Custo: apenas o trabalho feito
- ✓Previsível: 1 tarefa → 1 custo
- ✓Contexto do maestro protegido
⚠️ Agent Teams — cuidado
- !Agentes conversam entre si: cada turno = custo
- !Custo pode crescer geometricamente
- !Difícil de auditar o que foi decidido onde
- !Valor justifica? Meça antes de adotar
⚠️ Custo ~15× — não por causa dos agentes, mas da conversa
Multiagente bem feito custa ~15× mais que single-agent. A maior parte desse custo não é o trabalho dos agentes — é o overhead de coordenação: prompts de briefing repetidos, contexto compartilhado, mensagens de status. Use agent teams só quando o resultado claramente justifica. Na dúvida, use subagentes normais.
A distinção entre subagentes que trabalham isolados (baratos) e agent teams onde os agentes conversam entre si (custo por turno).
A diferença afeta diretamente o custo da sessão. Mal entendida, leva a sessões 10× mais caras sem resultado proporcionalmente melhor.
turno de conversa = custo · isolamento vs. comunicação · ~15× overhead · medir antes de adotar.
🧱 A regra dos 10+ arquivos e a parede de contexto
Existe um ponto de virada onde continuar no mesmo contexto se torna contraproducente. Chamamos de parede de contexto: o ponto em que o modelo começa a perder informações anteriores, misturar dados de arquivos diferentes ou se confundir com referências cruzadas. A regra prática: ao cruzar os 10 arquivos, pense em dividir.
📏 Sinais da parede de contexto
- 1 O modelo "esquece" um arquivo que você mencionou 5 arquivos atrás.
- 2 A resposta mistura nomenclatura de arquivos diferentes.
- 3 O tempo de resposta aumenta sem que o trabalho seja mais complexo.
- 4 A barra de contexto do maestro passa de 60% — sinal de alerta.
💡 Jobs independentes por unidade de trabalho
Tradução prática: "15 capítulos de um livro" = 15 jobs independentes. "20 arquivos de código para auditar" = 20 jobs. "8 relatórios de vendas para analisar" = 8 jobs. Cada job vira um subagente. O maestro nunca lê os arquivos — só lê os relatórios dos subagentes.
O limiar prático (10+ arquivos) onde um único contexto começa a degradar e a divisão em subagentes torna-se necessária.
Sem essa heurística, você usa subagentes tarde demais — depois que o contexto já degradou. Com ela, você decide antes do problema aparecer.
parede de contexto · regra dos 10+ · jobs por unidade · maestro lê relatórios, não arquivos.
📚 Jobs independentes: o caso dos 15 capítulos
O exemplo dos 15 capítulos é a melhor ilustração prática do padrão. Você tem um livro com 15 capítulos e quer saber: "onde está o argumento mais fraco?". Fazer isso num único contexto significa ler 15 capítulos em série — o modelo começa a misturar os primeiros capítulos com os últimos. Com 15 subagentes em paralelo, cada um lê um capítulo e entrega um relatório de 1 página. O maestro lê 15 relatórios de 1 página e sintetiza.
1 subagente / capítulo
15 janelas abertas simultaneamente. Cada uma lê 1 capítulo com foco total.
15 relatórios de 1 pág.
Cada subagente devolve uma avaliação concisa do seu capítulo.
Maestro sintetiza
Lê 15 páginas (não 15 capítulos) e identifica o argumento mais fraco.
📊 O que muda no contexto do maestro
Sem subagentes
Contexto lotado, leitura degradada
Com 15 subagentes
Maestro livre para raciocinar
Aplicação concreta do paralelo independente: 1 subagente por unidade de trabalho (capítulo, arquivo, relatório), todos em paralelo.
Mostra o ganho real na prática: o maestro recebe 15 resumos de 1 página em vez de processar 15 capítulos diretamente. Qualidade e velocidade maiores.
1 sub por unidade · relatório = resumo destilado · maestro lê pouco · contexto protegido.
🗺️ Como escolher a topologia certa
Há uma sequência de três perguntas para chegar à topologia certa. Responda em ordem — a primeira resposta "sim" determina o padrão. Se nenhuma se aplica, um único agente é provavelmente suficiente.
Os jobs são independentes entre si?
Se sim → Paralelo independente (ou fan-out se precisar sintetizar).
A saída de um job é a entrada do próximo?
Se sim → Pipeline (cadeia A → B → C).
Os agentes precisariam conversar entre si?
Se sim → Agent Teams (custo +). Só se o valor justificar. Se não, rearquitetar como paralelo + síntese.
💡 A regra de ouro
Se você consegue dividir o problema em partes que não precisam conversar, use paralelo. Se a saída de uma parte é a entrada da próxima, use pipeline. Se as partes precisariam de um debate, pense muito bem antes de agent teams — e considere se um maestro bem instruído não resolve mais barato.
O framework de 3 perguntas para escolher entre paralelo, pipeline, fan-out ou agent teams.
Saber escolher a topologia certa é a diferença entre um sistema elegante e barato e um lento e caro. É a habilidade de design central da Trilha 3.
independência → paralelo · dependência → pipeline · conversa → agent teams (custo +) · maestro bem instruído como alternativa.
Exemplo real: tabela padrão → caso de uso
A tabela abaixo mapeia os quatro padrões para casos concretos. Use-a como referência rápida ao projetar um sistema. Para cada caso, a coluna "Por quê?" é o argumento decisivo.
| Padrão | Caso de uso | Por quê? | Custo relativo |
|---|---|---|---|
| Paralelo | Auditar 20 arquivos de código | Arquivos independentes, sem dependência entre si | Baixo ✓ |
| Pipeline | Pesquisa → rascunho → revisão de artigo | Saída de cada etapa vira entrada da próxima | Médio |
| Fan-out | 5 personas revisam o mesmo livro | Múltiplas perspectivas, convergência explícita | Médio |
| Fan-out | 15 capítulos analisados em paralelo | Cada capítulo é independente, síntese no fim | Médio |
| Agent Teams | Negociação entre agentes especialistas | Agentes precisam trocar informações entre si | Alto ⚠️ |
| Único agente | Responder 1 pergunta sobre 1 arquivo | Overhead de orquestração não se justifica | Mínimo ✓ |
---
name: chapter-auditor
description: Revisa um único capítulo de texto em busca
de argumentos fracos, inconsistências e lacunas.
Use quando o maestro precisar auditar um capítulo
isolado (padrão fan-out de N capítulos).
tools: Read # só lê o arquivo do capítulo
model: haiku # rápido e barato por capítulo
---
You are a critical editor. You receive ONE chapter.
Identify: weakest argument, factual gaps, unclear sections.
Return a structured report: 3 bullets max. Be blunt.Prompts prontos (copie e cole)
Três prompts para você identificar e usar topologias na prática. O padrão: descreva o problema, aponte a dependência (ou ausência dela) e peça a topologia certa.
Tenho 20 arquivos de código para auditar. Cada um é
independente dos outros. Qual topologia de subagentes
devo usar? Justifique e mostre como estruturar o briefing
do maestro para disparar todos em paralelo.Use fan-out: dispare 1 subagente por capítulo para revisar
os 15 capítulos em paralelo. Cada sub deve retornar um
relatório de no máximo 3 bullets: argumento mais fraco,
lacuna factual, seção confusa. Sintetize no final.Monte um pipeline de 3 agentes para criar um artigo:
Agente A: pesquisa e extrai 10 fontes sobre [tema].
Agente B: recebe as fontes de A e escreve o rascunho.
Agente C: recebe o rascunho de B e revisa para publicação.
Use Haiku em A, Sonnet em B e C.Tela simulada: fan-out de 5 capítulos
Aqui está o terminal com um fan-out de 5 capítulos em andamento. O maestro disparou 5 subagentes ao mesmo tempo; cada um lê 1 capítulo com Haiku. Note: o contexto do maestro está em 9% — todo o trabalho pesado de leitura está nas janelas dos subagentes.
↑ Recriação ilustrativa do terminal. 5 capítulos em paralelo com Haiku; maestro em Sonnet, contexto quase intacto.
Exercício
Três problemas abaixo. Para cada um, escolha a topologia correta (paralelo, pipeline, fan-out ou agente único) e justifique em 1 frase por que descartou as outras.
Problema 1
Você tem 30 relatórios de vendas mensais de filiais diferentes. Quer identificar qual filial teve a maior queda de margem nos últimos 3 meses. Cada relatório é um PDF independente de ~20 páginas.
Problema 2
Você quer criar um post de blog de alta qualidade sobre um tema técnico. O fluxo natural é: primeiro pesquisar fontes confiáveis, depois escrever o rascunho com base nas fontes, depois revisar o rascunho final.
Problema 3
Você criou uma landing page e quer feedback sob 4 perspectivas diferentes: conversão (copywriter), SEO (especialista de busca), acessibilidade (auditor WCAG) e design (UX designer).
✅ Critério de verificação
- →Problema 1: Fan-out (30 PDFs independentes → 30 subagentes → síntese). Paralelo puro se não precisasse convergir.
- →Problema 2: Pipeline (pesquisa → rascunho → revisão são dependências reais; a saída de cada etapa alimenta a próxima).
- →Problema 3: Fan-out (4 perspectivas independentes sobre o mesmo objeto → convergência num relatório de feedback).
Se você justificou por que NÃO usou agent teams em todos os três casos, você acertou em cheio.
Exemplo resolvido — Problema 1
Topologia: Fan-out. Por quê? 30 PDFs independentes — cada subagente lê 1 PDF e devolve "filial X, queda de Y% em mês Z". Maestro coleta 30 linhas e identifica a maior queda. Descartei pipeline porque não há dependência entre os PDFs. Descartei agent teams porque os agentes não precisam trocar informações entre si.
✅ Resumo do módulo
Fim da Trilha 3 — próximo passo:
Trilha 4 — Avançado & cross-ambiente: arquitetura multiagente em escala, comparação de modelos por papel, segurança e subagentes no Codex.