Trabalho paralelo
Paralelismo compra contexto novo por unidade e velocidade. Custa coordenação: um fan-in que deve esperar, um merge que não pode colidir, um juiz que não pode ser o mesmo que o criador. Use onde as unidades são genuinamente independentes e pague o custo da coordenação explicitamente.
Pré-condições
- As unidades são independentes: nenhuma precisa do resultado de outra para começar.
- Você sabe quais são as unidades. Causa desconhecida → primeiro um despacho de investigação.
- Escritas são isoladas: cada unidade escreve em arquivos diferentes, ou cada unidade roda em seu próprio worktree e commita apenas os arquivos que aquela unidade tocou (mecânica: seção Isolamento em delegate/references/harness-notes/claude-code.md).
Faltando qualquer uma → serialize, ou investigue primeiro.
Formas
Fan-out, fan-in. N despachos da mesma fase, um por unidade, enviados juntos. Um único despacho consolidante espera por todos — essa espera é a barreira — e mescla seus arquivos de entrega em um só. Mantenha a saída de cada unidade em um arquivo; o consolidador lê caminhos, não seu contexto.
Fan-out mecânico. Um despacho process decide a mudança exata uma vez. N despachos genéricos a aplicam textualmente, cada um em seus próprios alvos. Um despacho review verifica o conjunto todo. O orquestrador nunca aplica a edição por si mesmo, por menor que seja o conjunto.
Maker/checker. Quem produziu um resultado nunca o julga. Roteie review para um agente diferente — um agente tipado como revisor para o domínio onde existir um, senão um especialista em função diferente — com os critérios de sucesso e o caminho do artefato, e nada do raciocínio do criador.
Gerar e filtrar. Faça fan-out para produzir candidatos; um despacho deduplica e pontua contra uma rubrica escrita; apenas sobreviventes continuam. Escreva a rubrica antes de gerar.
Torneio. Para ranquear um conjunto grande demais para julgar em uma janela: despachos de comparação par a par, cada um segurando dois itens, com uma chave mantida em um arquivo. Julgamentos comparativos são mais confiáveis que pontuações absolutas.
Fan-out de hipóteses. Para causa raiz: um despacho por fonte de evidência disjunta (logs, código, dados) forma uma hipótese a partir de sua fonte sozinha. Então um despacho por hipótese tenta refutá-la. O que sobreviver à refutação é o achado.
Loop até parada. Para trabalho de tamanho desconhecido: repita um despacho até que uma condição observável seja satisfeita — nenhum novo achado, zero erros na saída do portão, o arquivo de checklist sem itens não marcados. Defina o limite antes da primeira iteração (padrão 5). Ao atingir o limite, reporte PARCIAL com o que restou.
Fan-out de checklist
Um arquivo markdown de itens - [ ] é uma lista de unidades pronta: um despacho por item não marcado, cada um instruído a marcar sua própria linha como CONCLUÍDO, depois loop-until-stop em "nenhum item não marcado permanece". Serialize itens que nomeiam o mesmo arquivo.
Limites e condições de parada
Todo loop e todo fan-in tem um número escrito antes de começar: iterações, redespatos ou unidades. Atingir o limite é um relatório PARCIAL ou BLOQUEADO para o usuário, nunca uma repetição silenciosa.
Equipes persistentes
Alguns harnesses oferecem equipes de agentes de longa duração com listas de tarefas e mensagens compartilhadas. Elas adicionam sobrecarga de instrução e comunicação que agentes seguem inconsistentemente, e não são portáveis entre harnesses. As formas acima não precisam de nada disso. Recorra a uma equipe apenas quando agentes precisam trocar mensagens no meio da tarefa, e então consulte as notas do harness.
Referências
- delegate — o template de prompt que cada unidade usa.
- delegate/references/harness-notes/claude-code.md — como enviar despachos concorrentes, isolar worktrees e mover um pipeline longo para um script de workflow no Claude Code.