Engenharia de Grafos: Construa mais de 1000 loops de agentes a partir de um único prompt

O sucessor do Loop Engineering e o workflow que executa seus agentes 10x mais amplo...

A maioria das pessoas que constroem um agente multi-etapa 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 entram na fila, um trabalho de cada vez, até que a janela de contexto encha e o agente esqueça 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 -

Isso te dá um grafo funcional e nomeia as armadilhas que quebram os reais, e vou sinalizar onde as partes difíceis começam

antes do alpha - inscreva-se no meu substack para mais alpha fresco ↓

https://substack.com/@0xcodila

Capítulo 0 - O que é engenharia de grafos de fato

Há um mês, o campo falava 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 enxergar a própria métrica. Não consegue questionar se o alvo está certo, nem perceber que sua própria medição está se desviando.

A resposta não é um loop melhor. É um grafo de loops - uma rede onde ciclos se observam e se corrigem

Para agentes, isso significa uma coisa:

Pare de escrever um agente que faz tudo em uma linha - projete a

forma

do trabalho - o que executa antes do quê, o que executa 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 estão lá

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 então" como uma aresta.

"Resuma este arquivo

e então

me diga o clima"

O clima não lê o resumo.

Essas são duas tarefas independentes que um script linear encadeia sem motivo. Cada uma espera a anterior por nada

O hábito que inicia tudo:

Para cada "e então", pergunte - o próximo passo realmente lê a saída do passo 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 no resto deste guia

Seu agente simples "faça A, então B, então C" já é um grafo - apenas o mais triste: uma cadeia única 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 ativados por padrão. No Pro, ative a linha Workflows dinâmicos em /config

1. Abra um repositório que você conhece.

Um de verdade, para o resultado significar algo.

2. Cole este prompt (cortesia da 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 um
3verificador independente em cada achado antes de relatar.
4Analise um máximo de 20 arquivos para começar.

Substitua src/routes/ pelo local 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: "Workflow dinâmico solicitado." 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 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 permanece 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ê ouvirá

O script de coordenação é código

Então passar resultados entre agentes não gasta contexto novamente como uma transferência de chat faria.

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 é boa, pressione s.

Isso salva em ~/.claude/workflows, reexecutável 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 teto real do recurso

• E a escala é o ponto Mil agentes significam um trabalho que nenhum contexto único 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 por vez significa apenas que a frota se move em ondas, processando todos os mil sem você precisar supervisionar nenhum

Comece com 20 para ver como uma execução se comporta e quanto custa - depois expanda - 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 importam mais

• Falha um: o grafo concorda consigo mesmo

Quando um agente verifica o próprio trabalho, ele é brando consigo mesmo. Modelos preferem suas próprias saídas

Então você coloca um verificador na aresta - um nó separado que confirma um achado antes que ele flua adiante.

O problema 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. Está concordando consigo mesmo em uma fonte diferente

Um grafo de agentes compartilhando um contexto é um loop único fantasiado. Ele falha da mesma forma - mais tarde, mais caro, com mais luzes verdes no caminho para baixo

Então o verificador é um nó novo - Contexto próprio - Verificando um sinal real - não "o agente disse que terminou," mas "o teste realmente passa"

• Falha dois: agentes pisando uns nos outros

Isso não é hipotético

Quando a equipe do Bun primeiro expandiu uma grande portabilidade entre muitos agentes, a execução falhou operacionalmente e agentes usaram comandos git compartilhados em um workspace e sobrescreveram uns aos outros

A correção foi estrutural, não uma engenharia de prompt inteligente. 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 causam condição de corrida

Antes de expandir, responda a três perguntas:

• Onde cada agente trabalha?
• Como os resultados são mesclados?
• 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 é a mesma forma, voltada para um novo trabalho. Mude a linha da 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á integrado: divide sua pergunta em ângulos, busca em paralelo, agentes se refutam antes de escrever
• Portar um módulo - arquivo por arquivo, testes como porta, falhas retornadas em loop
• Revisão de diff adversarial - roteado por tamanho: mudança pequena → uma passagem; grande → auditoria paralela completa
• Varredura de ecossistema agendada - salve uma vez, reexecute pelo nome
• Descoberta de tamanho desconhecido - localizadores rodam em paralelo, cada resultado verificado contra tudo já visto, fazendo loop até que duas rodadas não encontrem nada novo

///

Como é o tetohttps://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/

A portabilidade do Bun de Zig para Rust 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 $165.000 em uso, Precisou de um humano projetando e monitorando tudo

E atraiu críticas públicas sobre se tanto código escrito 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

Topologia sozinha não compra verdade

Uma rede de agentes todos confirmando uns aos outros, nenhum deles tocando em nada real, falha exatamente como o loop único falhou - só que com mais partes móveis

O grafo precisa de âncoras: nós que não podem ser contestados

• Testes que realmente rodaram - não "deveriam passar," passaram
• Um verificador baseado em evidências, não em intuições
• Regras congeladas que os agentes nunca podem ajustar - porque são elas 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 você não precisa só queima dinheiro e adiciona maneiras de falhar.

Pule o grafo quando:

• A tarefa é pequena ou isolada. Adicionar uma função, corrigir um bug. Um workflow é pura sobrecarga aqui - um único agente é mais rápido e mais barato.
• Você precisa de supervisão rigorosa. Se você quer ler e aprovar cada etapa antes da próxima rodar, o objetivo principal do 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 cadeia 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 prompt engineer 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 detêm 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, executarão uma frota.

Desenhe o grafo. Permaneça o arquiteto.

Comece com o pré-requisito:

Loop Engineering

- o loop único no qual isso se baseia

@0xCodila