O sucessor do Loop Engineering e o workflow que expande seus agentes em 10x...
A maioria das pessoas que constroem um agente multi-etapas acaba com uma linha reta
etapa um, etapa dois, etapa três. Cada uma esperando a anterior terminar para começar
Aqui está o que quase ninguém verifica:
metade dessas etapas nunca precisou esperar
Elas simplesmente se enfileiram, um trabalho de cada vez, até que a janela de contexto se enche e o agente esquece o que estava fazendo
- Não era lento porque o modelo era fraco
- Era lento porque você desenhou uma linha onde o trabalho era um grafo
Este guia leva você dessa linha para um grafo que se espalha por uma frota e verifica o próprio trabalho
Cinco etapas. Na Etapa 2 você já terá construído um -
Ele te dá um grafo funcional e nomeia as armadilhas que quebram os reais, e eu vou sinalizar onde as partes difíceis começam
antes do alpha - inscreva-se no meu substack para mais alpha fresco ↓
Capítulo 0 - O que realmente é engenharia de grafos
Um mês atrás, o campo estava falando sobre loops.
Peter Steinberger resumiu em nove palavras:
https://x.com/steipete/status/2078277297791189132
Um loop é um ciclo de melhoria:
tentar algo → verificar o resultado → ajustar → tentar de novo
Esse é o átomo: um único agente melhorando uma coisa repetidamente
(Se você leu meu artigo Loop Engineering, é isso)
https://x.com/0xCodila/status/2072329149520232639
Mas o loop único tem uma falha conhecida - uma equipe de suporte amarra um loop de feedback a uma métrica: taxa de resolução de tickets
O número sobe por meses enquanto a satisfação cai. O bot aprendeu a fechar tickets rápido em vez de resolvê-los
Isso é a lei de Goodhart. Um loop só consegue ver sua própria métrica. Ele não consegue perguntar se o alvo está certo, nem perceber sua própria medição se desviando.
A resposta não é um loop melhor. É um grafo de loops - uma rede onde ciclos se observam e se corrigem mutuamente
Para agentes, isso significa uma coisa:
Pare de escrever um agente que faz tudo em linha reta - projete a
forma
do trabalho - o que roda antes do quê, o que roda ao mesmo tempo, o que espera.
Nós fazem o pensamento. Arestas carregam os resultados
E o Claude Code lançou as ferramentas para construir isso diretamente: workflows dinâmicos
Etapa 1 - Enxergue as arestas que não existem
Um grafo tem duas partes:
- Um nó é uma unidade de trabalho: um agente, um job, uma entrada, uma saída
- Uma aresta é uma dependência: a saída deste nó alimenta a entrada daquele nó
O erro que todo mundo comete é tratar "e depois" como uma aresta.
"Resuma este arquivo
e depois
me diga o clima"
O clima não lê o resumo.
Esses são dois trabalhos independentes que um script linear encadeia sem motivo. Cada um espera o anterior por nada
O hábito que inicia tudo:
Para cada "e depois", pergunte - a próxima etapa realmente lê a saída da etapa anterior?
- Se sim → aresta real. Mantenha a ordem.
- Se não → sem aresta. A espera é desperdiçada. Execute-os lado a lado.
Se nenhum dado cruza entre duas caixas, elas são independentes.
Essa independência é o que você vai explorar pelo resto deste guia
Seu agente simples "faça A, depois B, depois C" já é um grafo - apenas o mais triste: uma única corrente onde, se C trava, D nunca acontece.
Etapa 2 - Construa seu primeiro grafo (do início ao fim)
Chega de teoria. Construa um e veja funcionar.
Antes de começar:
- Claude Code v2.1.154+ (verifique com claude --version)
- Um plano pago. No Max, Team ou Enterprise, os workflows estão ativos por padrão. No Pro, ative a linha Dynamic workflows em /config
1. Abra um repositório que você conhece.
Um real, para que o resultado signifique algo.
2. Cole este prompt (criado pela Anthropic):
1Crie um workflow para auditar cada arquivo de rota em src/routes/2em busca de verificações de autenticação ausentes. Dispense um agente por arquivo, depois execute um3verificador independente em cada descoberta antes de relatar.4Analise no máximo 20 arquivos para começar.
Troque src/routes/ pelo diretório onde seus arquivos estão. A linha "máx 20" mantém sua primeira execução barata.
3. Veja "workflow" acender.
O Claude Code destaca: "Dynamic workflow requested." Esse é o sinal de que um grafo está sendo construído, não um chat normal
4. Aprove o plano.
O Claude escreve um script de orquestração em JavaScript e mostra as fases primeiro. Leia-as, escolha "Sim, execute."
5. Deixe a frota rodar.
Um agente por arquivo, em paralelo, enquanto sua sessão fica livre.
Digite /workflows para ver ao vivo: escopo, expansão, verificação, síntese.
6. Leia a única resposta.
Não vinte chats separados. Um relatório - porque os resultados intermediários viveram nas variáveis do script, não no seu contexto.
Isso é um grafo.
Uma dúzia de agentes, a partir de uma única frase.
Sobre a alegação de "zero tokens" que você vai ouvir
O script de coordenação é código
Então passar resultados entre agentes não gasta contexto novamente da mesma forma que uma transferência de chat.
Mas os agentes ainda custam uso. Um workflow custa significativamente mais que uma sessão normal.
A economia está na coordenação, não no trabalho. Comece com escopo, monitore o uso, depois expanda.
- Torne-o seu
Quando uma execução for boa, pressione s.
Isso salva em ~/.claude/workflows, podendo ser reexecutado pelo nome
Agora mude a tarefa e mantenha a forma. Troque "verificações de autenticação ausentes" por "promessas não tratadas", ou "funções com mais de 100 linhas"
Até onde isso escala (nome do artigo)
Uma execução de workflow pode se expandir para 1.000 agentes, com até 16 trabalhando ao mesmo tempo
É daí que vem "1000+ loops em uma janela" - não é uma metáfora, é o limite real do recurso
- E a escala é o ponto Mil agentes significa um trabalho que nenhum contexto único jamais poderia conter - uma base de código inteira auditada de uma vez, uma migração que toca cada arquivo, uma busca que executa mil ângulos em paralelo
O limite de 16 ao mesmo tempo significa apenas que a frota se move em ondas, processando todos os mil sem que você precise cuidar de nenhum
Comece com 20 para ver como uma execução se comporta e quanto custa - depois aumente - porque este é o teto contra o qual ninguém mais está construindo
Etapa 3 - A parte que realmente quebra
Você construiu um grafo. Aqui está onde os reais desmoronam.
Duas falhas são as mais importantes
- Falha um: o grafo concorda consigo mesmo
Quando um agente verifica o próprio trabalho, ele é bonzinho consigo mesmo. Modelos preferem suas próprias saídas
Então você coloca um verificador na aresta - um nó separado que confirma uma descoberta antes que ela flua adiante.
A pegadinha que ninguém nomeia: o verificador precisa de contexto limpo
Entregue a ele a mesma conversa que o executor teve, e ele não está verificando. Ele está concordando consigo mesmo em uma fonte diferente
Um grafo de agentes compartilhando um contexto é um único loop fantasiado. Ele falha da mesma forma - mais tarde, de forma mais cara, com mais luzes verdes no caminho para baixo
Portanto, o verificador é um nó novo - Contexto próprio - Verificando um sinal real - não "o agente disse que está pronto", mas "o teste realmente passa"
- Falha dois: agentes pisando uns nos outros
Isso não é hipotético
Quando a equipe do Bun expandiu um grande port através de muitos agentes pela primeira vez, a execução falhou operacionalmente e agentes usaram comandos git compartilhados em um único workspace e se sobrescreveram
A correção foi estrutural, não uma engenharia de prompt esperta. Eles proibiram os comandos inseguros e deram a cada grupo sua própria worktree isolada
Essa é a verdadeira lição do paralelismo - dois agentes escrevendo no mesmo arquivo competem
Antes de expandir, responda a três perguntas:
- Onde cada agente trabalha?
- Como os resultados se mesclam?
- O que acontece quando dois discordam?
Um grafo sem esse plano não escala - Ele falha mais rápido
Etapa 4 - Seis grafos para construir esta semana
O método: encontre as arestas reais → expanda → verifique em contexto independente → isole os trabalhadores
///
Cada um destes tem a mesma forma, voltada para um novo trabalho. Mude a linha de tarefa e vá:
- Varredura de segurança - um agente por arquivo caçando autenticação ausente, um verificador confirmando cada acerto (o que você construiu)
- Relatório citado com /deep-research - já embarcado: divide sua pergunta em ângulos, busca em paralelo, agentes se refutam antes de escrever
- Portar um módulo - arquivo por arquivo, testes como portal, falhas retornadas em loop
- Revisão adversarial de diff - roteado por tamanho: mudança pequena → uma passada; grande → auditoria paralela completa
- Varredura programada de ecossistema - salve uma vez, reexecute pelo nome
- Descoberta de tamanho desconhecido - localizadores rodam em paralelo, cada resultado verificado contra tudo visto, em loop até que duas rodadas não encontrem nada novo
///
Qual é a aparência do tetohttps://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
O port de Zig para Rust do Bun rodou exatamente nesta maquinaria.
Cerca de 50 workflows, um pico de 64 agentes em paralelo. Aproximadamente 535.000 linhas de Zig transformadas em mais de um milhão de linhas de Rust, em 11 dias.
Também custou cerca de US$ 165.000 em uso. Precisou de um humano projetando e monitorando a coisa toda
E atraiu críticas públicas sobre se tanto código gerado por IA pode ser revisado com segurança.
A escala é real. Assim como o preço e a supervisão
Etapa 5 - As âncoras que mantêm um grafo honesto
A topologia sozinha não compra a verdade
Uma rede de agentes todos se confirmando mutuamente, nenhum deles tocando em nada real, falha exatamente como o loop único falhou - apenas com mais partes móveis
O grafo precisa de âncoras: nós que não podem ser questionados
- Testes que realmente rodaram - não "deveriam passar", passaram
- Um verificador baseado em evidências, não em sensações
- Regras congeladas que os agentes nunca podem ajustar - porque são aquelas que um otimizador enfraqueceria
O grafo é tão honesto quanto as coisas dentro dele que se recusam a se mover
Quando um grafo é a escolha errada
A maioria das tarefas não são grafos. Usar um quando não é necessário só queima dinheiro e adiciona formas de falhar.
Pule o grafo quando:
- A tarefa é pequena ou isolada. Adicionar uma função, corrigir um bug. Um workflow é pura sobrecarga aqui - um agente único é mais rápido e barato.
- Você precisa de supervisão rigorosa. Se você quer ler e aprovar cada etapa antes da próxima rodar, o objetivo principal de um grafo (rodar amplo sem você) trabalha contra você.
- Você ainda não sabe o que está procurando. Trabalho exploratório quer um agente que você possa direcionar, não uma frota comprometida com um plano antes de você entender o problema.
- As etapas dependem genuinamente umas das outras. Se cada etapa lê a saída da etapa anterior, é uma corrente real. O paralelismo não tem o que pegar. Forçar um grafo em uma tarefa verdadeiramente sequencial só adiciona custo de coordenação para ganho zero de velocidade.
O indicador é a Etapa 1. Se você não consegue encontrar duas caixas sem seta entre elas, não há grafo a construir. É um loop, e um loop é suficiente.
Um grafo é uma ferramenta para largura - trabalho independente, feito de uma vez
Quando o trabalho não é amplo, a linha nunca foi o problema...
A mudança
Um promptador faz uma pergunta. Um arquiteto desenha um grafo.
O agente linear nunca foi o teto.
Foi a primeira forma - aquela que todos usam porque combina com como digitamos: uma linha, uma coisa de cada vez.
Depois que você vê os nós e as arestas, você para de pedir ao agente para fazer mais e começa a pedir ao grafo para fazer mais amplo:
- Expanda onde o trabalho é independente
- Bloqueie as arestas onde a confiança importa
- Congele os nós que guardam a verdade
A maioria das pessoas continuará enfileirando etapas em uma linha.
Os poucos que aprenderem a desenhar o grafo, e a respeitar o que o quebra, rodarão uma frota.
Desenhe o grafo. Continue sendo o arquiteto.
Comece com o pré-requisito:
- o loop único no qual isso se baseia
