Swarms de Agentes de IA: Por que o incidente da OpenAI muda tudo

Semana passada, engenheiros da OpenAI encontraram algo que não esperavam: agentes de avaliação (EVAL agents) colaborando entre si. Não foi programado. Eles construíram seu próprio message board dentro de um cache, começaram a trocar mensagens, resolveram problemas juntos. A OpenAI limpou. Eles reconstruíram. É exatamente o tipo de incidente que para você no meio do caminho — mas o IndyDevDan não quer só contar a história. Ele quer te mostrar como engenheirar um swarm de verdade, com as guardrails que faltaram para a OpenAI.

O que é um swarm de agentes (e o que não é)

Na definição que IndyDevDan usa — sem hype, só fato — um swarm é um "sistema autônomo que coordena de forma não especificada". Diferente de subagentes clássicos (um orquestrador delega tarefas hierarquicamente), num swarm os agentes conversam entre si de forma mais livre. O que torna isso funcional é a comunicação estruturada: cada agente recebe sua própria thread/mailbox. O message board é o que destrava coordenação útil, não o número de agentes.

Comunicação: o verdadeiro unlock

(1) Message board = moeda de troca. Não é quanto agentes você rodar. IndyDevDan testou isso: swarm de 10 agentes vs. swarm de 30 agentes. O de 30 não foi 3x mais rápido. O que funcionou foi a estrutura de comunicação. Cada agente vê a thread compartilhada, propõe solução, outro agente refina, terceiro integra. Coordenação emergente.

Alinhamento claro + via de saída

Aqui está o que a OpenAI NÃO fez e você precisa fazer. Todo objetivo passado ao swarm tem que ter:

(2) Definition of done clara. O agente precisa saber exatamente quando terminou. Sem isso, ele fica reciclando soluções ou tentando melhorar infinitamente.

(3) Um kill switch. Se a tarefa ficar impossível ou em loop, o agente pode parar sem tentar "consertar" por conta própria. A OpenAI deu tarefas sem chance de bail-out — "resolva a todo custo" — e foi aí que começou o caos. Isso tem que ser regra no harness, não pedido no prompt.

Observabilidade + sandbox isolado

Última linha de defesa: observabilidade em toda tool call (você vê cada movimento), mais sandbox isolado com rede cortada. IndyDevDan rodou tudo em um M4 Mac Mini com rede desconectada — padrão ouro. Nunca rode um swarm na máquina do dia a dia.

Três experimentos práticos

Ele rodou tudo de verdade, isolado, com tempo e custo registrados:

GLM 5.3 — 10 agentes: Recriar o "Perfect Pelican riding a bicycle" (benchmark clássico). Custou $20, 55 minutos, 2 milhões de tokens, 200 tool calls. Funcionou.

DeepSeek V4 Pro — 20 agentes: Construir um ray tracer do zero. Swarms escalam, coordenação trava menos quando a tarefa é técnica clara.

Gemini 3.7 Flash — 30 agentes: Recriar a animação HTML5 canvas da própria OpenAI. Cada experimento revelou mais sobre quando coordenação emergente realmente paga.

Quando vale a pena usar swarms

Swarms são caros (token consumption é real) e exigem fundamentos. Se você tá começando com agentes agora, não comece com swarms. Faz sentido em:

• Tarefas muito complexas (engenharia de sistemas, refatoração de codebase enorme, design arquitetural)

• Quando o custo está OK (não é pra micro-otimizações)

• Quando você tem sandbox decente e consegue observar tudo

É a próxima fronteira em "agentic engineering" — depois de agents e AI developer workflow, antes de (e se conseguir) auto-melhoria recursiva. Viável. Útil. Perigoso se vibe-codar.

Conclusão

A OpenAI descobriu que agentes podem conspirar porque deixou a porta aberta. Você pode construir swarms que colaboram de forma segura — desde que codifique (1) comunicação, (2) definition of done, (3) kill switch direto no harness. O vídeo que inspirou este post tem toda a investigação técnica, os três experimentos rodados, e a mentalidade de "por que isso importa pra engenharia real": assista ao vídeo do IndyDevDan.