Testei orquestração multi-agente num projeto real — o que vale e o que é hype

Comecei a tarde querendo só importar um repositório de notas de system design pro meu vault do Obsidian. Terminei com 28 sub-agentes do Claude Code rodando em paralelo ao mesmo tempo, traduzindo o conteúdo inteiro pra português. Não foi planejado — foi o tipo de decisão que só faz sentido quando você já está no meio da tarefa e percebe o formato do problema. Registro aqui enquanto a opinião ainda está fresca, antes de virar “óbvio” com o tempo.

O problema que apareceu no meio do caminho

O plano original era simples: clonar o repo liquidslr/system-design-notes (28 capítulos do livro System Design Interview, com ~392 diagramas), converter a sintaxe HTML de imagem (<img src="./images/x.png">) pro formato de embed do Obsidian (!x.png) e organizar tudo dentro de Studies/. Isso eu fiz com um script Python direto — não tem graça nenhuma paralelizar conversão de sintaxe, é trabalho determinístico, um regex resolve.

O pedido de tradução veio depois, no meio da execução: “traduza para português”. Foi aí que o formato do problema mudou. Traduzir 28 capítulos técnicos, cada um com estrutura Markdown, embeds de imagem e blocos de código que não podem ser tocados, não é mais regex — precisa de julgamento de linguagem natural. E os 28 arquivos são completamente independentes entre si: nenhum depende do resultado do outro, cada um mexe no seu próprio arquivo.

Isso bate exatamente com a regra que eu mesmo escrevi no meu CLAUDE.md pra decidir entre dispatch paralelo e sequencial: 3+ tasks independentes, sem estado compartilhado, cada uma tocando um arquivo diferente → paralelo. Não teve dúvida na hora de decidir.

Como isso difere do Maestri

Vale separar uma coisa antes de continuar, porque confundem fácil: isso não foi Maestri. Maestri é a minha squad de terminais especializados (Morpheus, Atlas, Iris, Argos, Themis) que já expliquei em outro post — cada um é um agente fixo com papel definido, vivendo num terminal separado.

O que rodou aqui foi diferente: o próprio Claude Code, dentro da mesma sessão, disparando sub-agentes genéricos e efêmeros — cada um nasce só pra uma tarefa, recebe um prompt auto-contido, executa, devolve o resultado e morre. Não tem papel fixo, não tem “personalidade”, não sobra estado entre eles. Pra tradução em lote de arquivo independente, é exatamente o formato certo: eu não precisava de um “tradutor” com identidade e memória, precisava de 28 execuções idênticas do mesmo prompt, cada uma num arquivo diferente.

O prompt que eu repeti 28 vezes

A parte que realmente importa não foi “mandar traduzir”. Foi escrever um prompt restritivo o bastante pra que a mesma instrução, repetida 28 vezes por agentes que não se comunicam entre si, produzisse resultado consistente. As regras que entraram em todos os 28:

• Não tocar frontmatter YAML.
• Não tocar embeds !... nem wikilinks ... — copiar exatamente.
• Não tocar blocos de código, JSON de exemplo, URLs.
• Manter termos técnicos consolidados em inglês (cache, load balancer, sharding, Redis, Kafka…) em vez de forçar tradução.
• Traduzir a prosa, os títulos de seção e os itens de lista.
• Sobrescrever o próprio arquivo no final, sem criar arquivo novo.

Sem essa lista, cada um dos 28 agentes teria tomado uma decisão diferente sobre o que é “termo técnico que fica em inglês” e o que não é — e eu teria 28 arquivos com critério de tradução inconsistente entre si, o que é pior do que não traduzir nada.

O que quase deu errado (e não foi por causa dos agentes)

Antes mesmo de chegar na tradução, o script de conversão HTML → Obsidian deixou dois problemas que só apareceram numa checagem posterior:

1. O Markdown original tinha um typo — ./images//message-queue.png, com barra dupla — que virou um embed quebrado: !01_/message-queue.png. O arquivo de imagem existia, o nome no embed é que estava errado.
2. Cinco arquivos sobraram com <div> residual: o regex de conversão assumia <div>...</div> fechando certinho, mas o repositório original tinha pelo menos um <div> de abertura fechado com <div> de novo, em vez de </div> — erro do material fonte, não meu.

Nenhum desses dois eu peguei “confiando” no processo. Peguei rodando um script depois, em cima de todos os arquivos, procurando por <img, <div> e por todo embed !... que não apontasse pra um arquivo de fato existente em attachments/. É chato, é anticlimático, mas é a etapa que separa “parece que funcionou” de “funcionou”.

Os números reais

Cada um dos 28 agentes de tradução gastou entre ~52 mil e ~70 mil tokens, com duração individual entre 37 segundos e quase 2 minutos — mas como rodaram concorrentes, o tempo de parede pra traduzir os 28 capítulos inteiros ficou perto de 2 minutos, não a soma de tudo isso. Se eu tivesse feito um por um, na mesma sessão principal, ia levar a tarde toda e ainda ia perder a paciência no capítulo 15.

Isso é o ganho real. Mas tem um custo que ninguém fala quando vende “orquestração multi-agente” como bala de prata: são ~1.6 milhão de tokens gastos só nessa etapa, somando os 28. Multi-agente não é grátis, é trocar tempo de parede por tokens. Vale a pena quando o trabalho é genuinamente paralelizável e o tempo economizado importa mais que o custo — não vale a pena disparar 10 agentes pra revisar um arquivo de 20 linhas.

Onde a consistência quebrou (mesmo com o mesmo prompt)

Um detalhe que só vi por ter lido o retorno de cada um dos 28 agentes: mesmo recebendo instrução idêntica, cada agente tomou decisões de julgamento ligeiramente diferentes quando encontrou algo ambíguo no texto original. Um manteve um erro de sintaxe de fórmula do material original porque “é conteúdo de código, não deveria corrigir”. Outro encontrou uma frase redundante no texto- fonte em inglês e decidiu remover a duplicação por conta própria, saindo da instrução literal. Nenhum dos dois estava errado — mas são 28 pessoas diferentes tomando 28 decisões diferentes em cima da mesma regra escrita.

Isso é o ponto que eu realmente queria registrar: paralelizar com LLM não é paralelizar com uma função pura. Cada instância interpreta a mesma instrução com uma margem de julgamento própria. Pra tarefa de tradução isso foi inofensivo — na pior hipótese, uma nota ficou levemente diferente da outra em como tratou uma ambiguidade pontual. Mas se a tarefa fosse, por exemplo, aplicar uma regra de negócio em 28 arquivos de configuração, essa mesma variância vira bug sutil, espalhado, e sem log central pra rastrear qual dos 28 agentes decidiu diferente.

Minha conclusão

Orquestração multi-agente vale a pena quando três coisas são verdade ao mesmo tempo: o trabalho é genuinamente paralelizável (arquivos/tarefas independentes, sem estado compartilhado), o prompt consegue ser restritivo o bastante pra não depender de julgamento subjetivo importante, e existe uma etapa de verificação determinística depois — não humana, não “parece bom”, um script que confirma. Tirando qualquer uma dessas três pernas, “multi-agente” vira só um jeito mais caro e mais difícil de auditar de fazer a mesma coisa que uma sessão sequencial faria — só que mais rápido no relógio e mais devagar na sua cabeça quando algo der errado.