Até aqui você delegou tarefas isoladas. Agora imagine um pedido grande de verdade: "levante tudo o que existe sobre o tema X, confirme o que é mesmo verdade e me entregue um relatório fechado". Um único subagente não dá conta — e pior, se ele parar cedo demais ou acreditar no primeiro resultado, você recebe uma resposta bonita e errada. A arquitetura em escala resolve isso com três estágios encadeados: uma frota que busca até secar (find), um tribunal que refuta cada achado (verify) e um sintetizador que junta só o que sobreviveu (synthesize). Grave esse pipeline — ele é o esqueleto do módulo inteiro.
↑ O esqueleto do harness: find em laço → verify adversarial por maioria → synthesize só dos sobreviventes.
Conteúdo detalhado
🚢 A frota: de um subagente a muitos
Uma frota é um conjunto de subagentes do mesmo tipo trabalhando o mesmo problema ao mesmo tempo — não um, não dois, mas dez, quarenta, cem, cada um numa fatia. O maestro deixa de "delegar uma tarefa" e passa a comandar uma operação: dividir o espaço de busca, despachar a frota, recolher os pedaços e seguir para o próximo estágio. A unidade de raciocínio deixa de ser o subagente e vira o sistema inteiro.
⚓ A analogia da frota de exploração
Pense num oceano a mapear. Um único navio leva meses e ainda perde regiões inteiras. Uma frota divide o mar em setores, manda um navio para cada um, e a almirante (o maestro) consolida as cartas. Nenhum navio fala com o outro — todos reportam à almirante. Se uma região vier confusa, ela manda mais navios para lá. Escala não é tamanho do navio; é quantidade e coordenação.
- •Almirante = o maestro/harness, que particiona, despacha e consolida.
- •Navios = a frota de subagentes, cada um num setor do problema.
- •Cartas = os relatórios parciais que voltam para serem unidos.
um padrão em que muitos subagentes do mesmo papel atacam fatias do mesmo problema em paralelo, coordenados por um único orquestrador.
problemas de cobertura ampla (varrer um repositório gigante, levantar literatura, auditar centenas de arquivos) só ficam tratáveis quando você pensa em frota, não em "um agente esforçado".
particionamento · paralelismo de larga escala · orquestrador como hub · o sistema como unidade de raciocínio.
🔁 Loop-until-dry: repetir até secar
O maior erro de uma busca em escala é parar cedo demais. Um subagente acha cinco coisas, acha que "deu", e devolve — mas existiam quinze. A correção é o loop-until-dry: rode a frota em rodadas, e só pare quando K rodadas seguidas voltarem vazias (nada de novo). "Seco" não é "uma rodada sem novidade"; é K rodadas sem novidade — um amortecedor contra parar no primeiro respiro.
Rodada: despacha a frota
Cada subagente busca na sua fatia.
A rodada produz um lote de achados novos. Tudo que já apareceu antes é deduplicado contra o acumulado.
Mede o "ganho" da rodada
Quantos achados inéditos entraram?
Se entrou achado novo, o contador de rodadas-vazias volta a zero e abre nova rodada. A busca ainda está "molhada".
Rodada vazia → conta para K
Nada novo nesta rodada.
Incrementa o contador. Só quando ele chega a K (ex.: 2 ou 3 vazias seguidas) a busca é declarada seca e o estágio termina.
💡 Por que K e não 1
Uma rodada vazia pode ser azar (a frota foi olhar nos cantos errados naquela vez). Exigir K vazias seguidas evita declarar vitória cedo demais. Em troca, defina um teto de rodadas (ex.: máximo 8) para o loop não correr para sempre num caso patológico.
⚖️ Verificação adversarial: N céticos refutam
Achar não é confirmar. Cada achado da frota entra num tribunal: você dispara N subagentes céticos, e a tarefa de cada um não é concordar — é tentar derrubar a afirmação ("ache uma evidência de que isto está errado"). Se a maioria conseguir refutar, o achado morre. Sobrevive só o que aguentou o ataque. É o oposto de pedir confirmação — pedir confirmação só reforça o viés.
✓ Verificação adversarial (faça)
- ✓Instruir o cético a procurar o erro, não a confirmar
- ✓Usar N céticos independentes e decidir por maioria
- ✓Exigir que cada refutação aponte evidência, não opinião
- ✓Deixar passar só o que sobreviveu ao ataque
✗ Verificação ingênua (evite)
- ✗Perguntar "isto está certo?" (puxa concordância)
- ✗Um único verificador (vira ponto único de viés)
- ✗O mesmo agente que achou ser quem valida
- ✗Aceitar tudo que "parece plausível"
🔭 Perspectivas diversas: lentes diferentes
Uma frota de subagentes idênticos comete os mesmos erros em coro — todos olham para o mesmo lugar e ignoram o mesmo ponto cego. A correção é dar a cada subagente uma lente diferente: o mesmo material, papéis distintos. Um caça contradições, outro caça o que está faltando, outro lê pela ótica de custo, outro pela de segurança. Diversidade de lente = diversidade de erro encontrado. É a mesma ideia das 5 personas da Trilha 1, agora como peça de arquitetura.
Lente da contradição
"Onde dois achados se contradizem? Qual deles tem que estar errado?"
Lente da lacuna
"O que deveria existir e não apareceu? Que pergunta ninguém fez?"
Lente do custo
"Quanto isto custa na prática? O que muda quando o orçamento aperta?"
Lente do risco
"Onde isto quebra? Qual o pior caso? O que um adversário exploraria?"
Lente da escala
"Funciona com 10? E com 10 milhões? Onde a abordagem deixa de servir?"
Soma das lentes
Cada lente acha um defeito que as outras não veem. Juntas, cobrem o que uma frota uniforme deixaria escapar.
📊 Diversidade > quantidade
Dez subagentes com a mesma lente acham, na prática, quase o que um acharia — só mais rápido. Cinco com lentes diferentes acham coisas que nenhum dos dez veria. Ao escalar, varie a lente antes de aumentar o número.
🧮 Completeness critic: o que ainda falta?
Loop-until-dry te diz quando a frota parou de achar. Mas "parou de achar" não é "achou tudo o que importa" — pode ter ficado um buraco inteiro inexplorado. Entra o completeness critic: um subagente cuja única missão é olhar o conjunto reunido e perguntar "o que ainda falta?". Ele não busca; ele aponta os buracos. Cada buraco que ele aponta vira uma nova rodada de busca direcionada — fechando o ciclo entre verificar e buscar de novo.
# Pergunta única do crítico: "o que ainda falta?"
COBERTO ✓ definição do conceito
COBERTO ✓ 3 casos de uso confirmados
COBERTO ✓ limites conhecidos
LACUNA ✗ nenhuma fonte sobre custo em produção
LACUNA ✗ nada sobre o que muda fora do Claude Code
LACUNA ✗ zero contra-exemplos (só casos de sucesso)
# → o harness abre 3 buscas direcionadas para
# fechar exatamente estas lacunas e roda de novo.
💡 Buscar é diferente de criticar
Quem busca tende a parar satisfeito com o que achou. Por isso o crítico de completude é um subagente separado, com contexto fresco — ele chega sem o apego do buscador a "já achei bastante" e enxerga o vazio que o buscador normaliza. É o mesmo princípio do revisor imparcial, aplicado à cobertura.
📋 Sem cap silencioso: logar o que cortou
Todo sistema em escala tem limites — de tokens, de tempo, de número de itens. O problema não é cortar; é cortar em silêncio. Se a frota achou 500 itens e o sistema só processa 50 sem avisar, você recebe um relatório que parece completo e não é — e nunca vai saber. A regra de ouro: nenhum corte silencioso. Cortou? Loga: o que foi cortado, quanto, e por qual critério. O usuário precisa ver a borda do mapa.
✓ Corte honesto
- ✓"Processei 50 de 500 achados (top por relevância)"
- ✓Registra o critério do corte (relevância, data, escopo)
- ✓Guarda o que sobrou para uma rodada futura
- ✓Deixa o usuário decidir se quer ir além do teto
✗ Cap silencioso
- ✗Trunca em 50 e não avisa que havia mais
- ✗Relatório parece completo, mas é uma fatia
- ✗Descarta os outros 450 sem deixar rastro
- ✗Decisão de cobertura tomada por você sem você
⚠️ O erro mais perigoso da escala
É o único erro desta lista que não dá sinal. Uma busca rasa você percebe; um achado falso o tribunal mata; mas um cap silencioso entrega um relatório plausível e incompleto que ninguém questiona. Por isso a regra é dura: se cortou, apareça no log — sempre, mesmo quando o corte parece óbvio.
🧬 Sintetizar: o relatório que fecha o pipeline
No fim, alguém tem que juntar tudo — mas juntar não é colar. O sintetizador recebe só os achados que sobreviveram ao tribunal, depois das lacunas fechadas, com o log de cortes em mãos, e produz uma narrativa coesa: dedup, agrupa por tema, resolve conflitos restantes, cita a origem de cada afirmação e declara o que ficou de fora. O relatório final é a única coisa que volta para você — limpo, como manda o modelo do subagente.
# Síntese: <pergunta original>
## Conclusões (sobreviveram ao tribunal)
- <afirmação A> [fonte: f1, f7 · 4/4 céticos mantiveram]
- <afirmação B> [fonte: f3 · 3/4 mantiveram]
## Conflitos resolvidos
- A vs. C → C caiu (refutado por evidência em f9)
## O que ficou de fora (sem cap silencioso)
- 500 achados → 38 processados (top por relevância)
- lacuna ainda aberta: custo em produção (0 fontes)
## Confiança
- alta nos itens 4/4; média nos 3/4; baixa onde há 1 fonte
📊 Síntese carrega o rastro
Um bom relatório não esconde o processo: cada conclusão traz quantos céticos a mantiveram e de onde veio, e há uma seção honesta de "o que ficou de fora". É isso que transforma uma pilha de achados num documento em que dá para confiar — e auditar.
Exemplo: o esqueleto de um harness
Um harness é o código (ou a skill) que orquestra a frota — o "almirante" feito programa. Você não precisa escrever isto em nenhuma linguagem específica agora; o que importa é reconhecer a forma. Abaixo, o esqueleto em pseudocódigo: os sete tópicos deste módulo aparecem como passos de uma função. Leia como uma receita, não como código pronto.
função pesquisar_em_escala(pergunta, K=2, max_rodadas=8, N_ceticos=4):
achados = conjunto() # dedup automático
rodadas_vazias = 0
log_cortes = []
# ── 1+2 · FIND em loop-until-dry ──────────────────────
enquanto rodadas_vazias < K e rodada < max_rodadas:
fatias = particionar(pergunta, achados) # tópico 1: frota
novos = frota_paralela(BUSCADOR, fatias) # cada um, uma lente (tópico 4)
ineditos = novos - achados
se ineditos vazio: rodadas_vazias += 1
senão: rodadas_vazias = 0; achados |= ineditos
# ── 3 · VERIFY adversarial (mata por maioria) ─────────
para cada a em achados:
votos = frota_paralela(CETICO, repetir(a, N_ceticos)) # "ache o erro"
se maioria(votos) == "refuta": achados.remove(a)
# ── 5 · COMPLETENESS critic → realimenta o find ───────
lacunas = subagente(CRITICO_COMPLETUDE, achados) # "o que falta?"
se lacunas: retornar pesquisar_em_escala(focar(pergunta, lacunas), K, ...)
# ── 6 · SEM CAP SILENCIOSO ────────────────────────────
se tamanho(achados) > TETO:
log_cortes.append(f"processados {{TETO}} de {{tamanho(achados)}} (top relevância)")
achados = top(achados, TETO)
# ── 7 · SYNTHESIZE (única saída p/ o maestro) ─────────
retornar subagente(SINTETIZADOR, achados, log_cortes) # relatório citado
🧠 O que o harness garante
- Profundidade — o loop só sai quando seca (K vazias).
- Confiabilidade — todo achado passa pelo tribunal.
- Completude — o crítico realimenta o find com as lacunas.
- Honestidade — todo corte vira linha de log.
⚙️ Os parâmetros que você ajusta
- K — quantas rodadas vazias até declarar seco.
- max_rodadas — teto para o loop não correr para sempre.
- N_céticos — quantos refutam cada achado.
- TETO — limite explícito, sempre logado quando atingido.
Prompts prontos (copie e cole)
Três prompts para impor a doutrina deste módulo a uma frota — mesmo sem escrever um harness. Repare no padrão: peça exaustão, peça refutação e proíba o corte silencioso.
Dispare uma frota de subagentes para levantar TUDO sobre
<tema>. Rode em rodadas e só pare quando 2 rodadas
seguidas não trouxerem nada novo. No fim, diga quantas
rodadas rodou e por que considerou a busca esgotada.
Para cada achado, abra 4 subagentes céticos cuja missão
é TENTAR REFUTÁ-LO com evidência (não confirmar). Se a
maioria refutar, descarte o achado. Me entregue só os
que sobreviveram, com a contagem de votos de cada um.
Antes de fechar, rode um crítico que liste o que ainda
falta e abra buscas para as lacunas. Depois sintetize um
relatório citado. Se você cortar QUALQUER coisa por
limite, registre o que cortou, quanto e por qual critério.
Tela simulada: o harness rodando uma frota
É assim que a operação aparece no terminal: o harness está na rodada 3 do find, com uma frota de buscadores e céticos em paralelo. Note o contador de rodadas vazias (1/2 — ainda não secou), os céticos derrubando achados e, na base, a linha de log do corte — visível, nunca silenciosa.
↑ Recriação ilustrativa do terminal (não é screenshot real). A frota queima contexto nas janelas dela; a sua mal se move — e o corte de 214→50 está no log, à vista.
Exercício: desenhe um loop-until-dry
Escolha um problema real de cobertura ampla (ex.: "encontrar todos os lugares do meu código que tocam pagamentos" ou "levantar tudo o que sei sobre o concorrente X") e desenhe no papel o harness que o resolveria com a doutrina deste módulo. Não precisa rodar nada — o entregável é o desenho do laço e suas regras.
Como fazer
- Defina como particionar o problema entre a frota (por pasta? por fonte? por subtema?).
- Escolha o K (quantas rodadas vazias até secar) e um teto de rodadas.
- Escreva a regra de verificação adversarial: quantos céticos, e como a maioria decide.
- Defina o completeness critic: que pergunta ele faz e o que vira nova busca.
- Diga onde está o teto de corte e exatamente o que você vai logar quando cortar.
✅ Critério de verificação — como saber que acertou
Seu desenho está correto se um leitor consegue responder, só olhando para ele, às cinco perguntas:
- →Quando para? A condição de parada é "K rodadas vazias", não "uma rodada" nem "deu tempo".
- →Como confia? Há refutação por maioria, não "perguntar se está certo".
- →Como sabe que está completo? Existe um crítico de lacunas que realimenta a busca.
- →O que foi cortado? Há um ponto explícito de log — nenhum corte é silencioso.
- →O que volta? Uma síntese citada, não a pilha bruta de achados.
Se faltar qualquer um dos cinco, o desenho ainda não é uma arquitetura em escala — é só "vários subagentes soltos".
Exemplo resolvido (resumido)
Problema: achar tudo que toca pagamentos no repo. Partição: uma fatia por diretório de topo. K=2, teto 6 rodadas. Verify: 3 céticos por achado, maioria refuta → fora. Crítico: "que fluxo de pagamento não aparece em nenhum achado?" → vira busca dirigida. Corte: teto 80 trechos; se passar, log "processados 80 de N". Saída: lista citada por arquivo + seção "não coberto".
✅ Resumo do módulo
Próximo módulo:
4.2 — Subagentes no Codex e outros ambientes. O mesmo conceito fora do Claude Code: equivalências, cross-runtime e o que muda.