Grafos de agentes: por que orquestração séria virou um problema de grafo

Toda vez que sai um modelo com janela de contexto maior, alguém me manda mensagem dizendo que orquestração de agentes virou problema resolvido. Joga o repositório inteiro no contexto, pede o resultado, pronto. Já vi esse filme em três gerações de tecnologia, e ele termina sempre igual.

Passei duas décadas construindo busca enterprise antes da Arvor — Solr, Lucene, índices com bilhões de documentos. A lição é chata e universal: capacidade bruta nunca consertou modelagem ruim. Índice maior não conserta esquema errado. Contexto maior não conserta trabalho mal decomposto.

Orquestração séria de agentes, em 2026, é um problema de grafo. E o time que enxerga isso primeiro para de brigar com o modelo e começa a brigar com o problema certo.

Um agente único é um grafo de um nó só

Quando você entrega tudo para um agente com contexto gigante, você não eliminou o grafo — você colapsou ele num nó só, e perdeu tudo que a estrutura te dava.

Um agente único não elimina o grafo — colapsa ele num nó só. O grafo devolve isolamento, paralelismo e um ponto de verificação explícito.

Perdeu isolamento: um passo que dá errado contamina todos os seguintes, porque o raciocínio ruim continua no contexto. Perdeu paralelismo: dez verificações independentes viram dez etapas em série. Perdeu retentativa granular: quando falha, você refaz tudo, não o pedaço que quebrou. E perdeu observabilidade: “o agente errou em algum lugar dessas 400 mil tokens” não é diagnóstico, é lamento.

Há um custo mais sutil ainda: dentro de uma janela grande, tudo compete por atenção, e essa disputa não se ganha no texto do prompt — se ganha decidindo o que entra em cada nó.

Nós, arestas e a parte chata que ninguém quer fazer

Um nó é uma unidade de trabalho com entrada declarada e saída verificável. Se você não consegue escrever o critério de aceite do nó em uma frase, não é um nó — é um desejo.

Uma aresta é uma dependência real: B só pode rodar depois de A porque B precisa da saída de A. E aqui está a parte chata, a que quase ninguém faz: a maioria das arestas que os times desenham não é dependência, é só a ordem em que a pessoa pensou nas tarefas. Sequência acidental virando arquitetura.

Separar dependência real de hábito de escrita é o que transforma uma lista de tarefas num grafo. É onde o ganho aparece: tudo que não depende de nada pode rodar junto.

Fan-out, fan-in, pipeline e barreira

Quatro padrões cobrem quase tudo:

Fan-out é o mesmo insumo indo para vários nós com objetivos diferentes, em paralelo. Cada um com contexto pequeno e missão estreita.

Fan-in é a agregação. É o padrão que os times mais fazem errado, porque tratam agregação como resumo. Um nó de fan-in precisa de regra de conflito: o que acontece quando dois verificadores discordam? Sem essa regra explícita, o agregador escolhe o texto mais bem escrito, não o mais correto.

Pipeline é a cadeia em série. Latência soma, e — pior — erro propaga. Faça a conta honesta: doze passos com 95% de acerto cada dão pouco mais de 54% de chance de sair inteiro do outro lado. Times constroem pipelines de doze passos porque é mais fácil de escrever, e depois culpam o modelo pelo cara-ou-coroa.

Barreira é o oposto: nada avança até que tudo chegue. Custa latência e compra consistência. É o que impede um merge de migração antes de build, testes, type check e lint terem todos voltado verdes.

No pipeline cada verificação segue assim que termina; na barreira, nada avança até que todas cheguem.

Verificação adversarial é um nó, não um adjetivo

“Revise seu trabalho antes de responder” no fim do prompt não é verificação. É o mesmo modelo, com o mesmo contexto e o mesmo viés, sendo perguntado se gostou de si mesmo. A resposta é sempre sim.

Verificação de verdade é um nó separado no grafo: contexto próprio, objetivo invertido (achar o erro, não confirmar o acerto), e acesso apenas ao artefato — nunca ao raciocínio de quem gerou. Se o verificador lê o raciocínio do gerador, ele é capturado por ele. Só sobe no grafo o que sobrevive à tentativa de derrubar.

E o melhor verificador quase nunca é um LLM. Compilador, teste, type checker, linter, validação de schema: são baratos, determinísticos e não têm opinião. Use o modelo para verificar o que máquina não verifica — intenção, regra de negócio, contrato implícito — e deixe o resto para ferramentas que não alucinam.

Três grafos que pagam o trabalho de desenhar

Revisão de código com verificadores em paralelo. Fan-out do diff para nós especializados: segurança, regressão, contrato de API, cobertura de teste. Cada um com contexto pequeno e um único critério. Fan-in num nó que deduplica e ordena por severidade, com regra de precedência definida. Um agente único lendo o diff inteiro acha o óbvio e cansa antes do resto.

Migração com worktrees isoladas. Cada módulo numa worktree git própria. O isolamento deixa de ser promessa e vira propriedade do sistema: dois nós não conseguem escrever no mesmo arquivo porque nem enxergam o mesmo diretório de trabalho. Barreira antes do merge, e rollback vira descartar uma worktree. É o padrão que rodamos com o Relentless.

Pesquisa multi-modal. Fan-out por fonte — documentação interna, código, web, planilha — com a ferramenta certa em cada nó, e fan-in com precedência explícita para quando as fontes discordarem. Sem essa regra, o agregador escolhe a fonte mais eloquente. É o que aprendemos construindo governança no BRAIN MAKER: proveniência não é enfeite, é critério de desempate.

Quando o grafo determinístico ganha — e quando perde

O grafo ganha quando o trabalho é decomponível, o critério de aceite é verificável por máquina, você precisa auditar o resultado, precisa repetir amanhã com a mesma saída, ou custo importa — porque nó pequeno roda com modelo menor.

O grafo perde quando o problema é exploratório e você ainda não sabe quais são as etapas. Desenhar grafo para um problema que você não entendeu é chute com diagrama. Aí um agente único, com boas ferramentas e liberdade, é o instrumento certo.

Minha regra prática: agente único para descobrir o grafo, grafo para rodar em produção. Confundir os dois é caro nas duas direções — grafo prematuro engessa a exploração, agente único em produção não escala nem audita.

Ferramentas, sem review de fachada

O ecossistema já convergiu para esse vocabulário. O LangGraph, da LangChain, é o exemplo mais explícito: nós, arestas estáticas e condicionais, estado central compartilhado, fan-out e fan-in como primitivas. Se você quer uma biblioteca que já pensa em grafo, é um lugar honesto para começar.

Não vou fingir que usamos a mesma biblioteca para tudo: boa parte do que rodamos é grafo em código próprio, com git como estado. O ponto não é a ferramenta. É que o grafo existe de qualquer jeito — se você não desenhar, ele fica implícito dentro de um prompt de duas mil palavras, sem dono e sem verificação.

Grafo é o mapa. O motor que percorre esse mapa é outro assunto — e é sobre isso que escrevi em loops de agentes. Se você quer parar de apostar em prompt e começar a desenhar arquitetura, fale com a gente ou conheça nossa consultoria agêntica.

Árvore não cresce em linha reta. Cresce em galho — e cada galho sabe de onde veio.