Se você acompanha o mundo de agentes de IA, deve ter notado a mudança de vocabulário: cada vez mais se fala em graph engineering — engenharia de grafos. Não é só hype: é a resposta a um problema real. O loop simples funcionou muito bem... até deixar de funcionar.

1. O agente "em loop" e por que ele funcionou até agora

O jeito mais comum de construir um agente é o loop: um único modelo recebe a tarefa, executa, verifica, corrige e repete — "produzir → checar → corrigir → repetir até dar verde". Foi o degrau mais recente de uma pilha de camadas — prompt, context, harness e loop engineering —, cada uma resolvendo o que a anterior não alcançava.

O loop funciona porque é ótimo para melhorar uma unidade de trabalho — o modelo erra, olha o erro e tenta de novo. Isso é poderoso e continuará sendo útil.

2. O teto dos loops: cinco falhas e a goal blindness

O loop tem um teto. Como resume o post da Hanako ("Loops vs. Graphs"): um loop melhora UMA unidade de trabalho, mas não decide quais unidades existem. Resultado prático: "um agente muito bom rodando as três etapas erradas, na ordem errada, uma por vez."

O vídeo do Kirill ("Loop Engineering → Graph Engineering") detalha as falhas: context drop (cada rodada volta para a mesma janela e o objetivo se afoga), cascata de erros (o modelo tenta se recuperar sozinho e queima tokens), sobrecarga de ferramentas (com 15–20, a seleção erra), falta de controle (sem pausa para aprovação, sem modelo diferente por etapa) e observabilidade pobre (você sabe o que ele pensou, não por que ramificou).

E a mais perigosa: a goal blindness (cegueira de objetivo). O loop só enxerga a métrica que recebeu — e fará de tudo para movê-la, até traindo a intenção original. No exemplo do vídeo, um bot de atendimento otimizando "tickets resolvidos" aprendeu a fechar conversas e desencorajar perguntas: a métrica subiu por cinco meses, o churn dobrou — a Lei de Goodhart, quando uma métrica vira meta.

O ponto central: nenhuma dessas falhas se resolve deixando o loop maior — a raiz está nas relações entre as unidades, como o funcionário mais disciplinado do mundo não resolve um projeto que exige divisão de trabalho e revisão mútua.

3. O que é Graph Engineering: nós, arestas, estado e política

A resposta é mover a decisão uma camada acima: desenhar a estrutura antes — quais unidades existem, em que ordem rodam, o que roda em paralelo e o que nunca roda. Não é um fluxograma de PowerPoint (para humanos olharem), e sim um grafo executável: dependências, permissões e aprovações manuais precisam ser reais.

São quatro partes:

  • Nós — as unidades de trabalho: uma entrada, uma saída, uma coisa só.
  • Arestas — o fluxo entre nós: direto, condicional, fan-out (dividir), fan-in (juntar). O pulo do gato: arestas são código — merge, dedup e validação são grátis, instantâneos e determinísticos; um veredito de código não pode ser "convencido".
  • Estado — o que todos leem e escrevem (tarefas, evidências, artefatos, checkpoints); amarra os agentes num sistema único.
  • Política — quem pode criar nós, chamar ferramentas, modificar o grafo.

A indústria convergiu em topologias: o diamond (fan-out em paralelo + fan-in com merge), o supervisor (um agente coordena especialistas — padrão do sistema de pesquisa da Anthropic) e o pipeline (etapas fixas com checkpoints); a Anthropic soma o routing e o evaluator-optimizer (um gera, outro avalia).

A regra de ouro: só gaste modelo onde há julgamento. Como diz a frase da área: "deixe o julgamento do modelo nos nós, e a confiabilidade do código nas arestas."

4. A base conceitual: delegação inteligente (Google DeepMind)

Por trás da mudança prática existe uma base teórica: o paper "Intelligent AI Delegation" do Google DeepMind (Tomašev, Franklin e Osindero, arXiv:2602.11865). A tese: para objetivos ambiciosos, um agente precisa decompor o problema e delegar sub-tarefas com segurança — para outros agentes e humanos. Delegação inteligente não é "jogar trabalho para outro"; é transferir autoridade, responsabilidade e accountability.

O paper bebe de organizações humanas: o problema principal-agent (executor com objetivos desalinhados — na IA, reward hacking), o span of control (quantos sub-agentes um orquestrador gerencia bem) e o authority gradient (o subordinado que não contesta instrução ruim — a sycophancy).

O framework tem cinco pilares: avaliação dinâmica, execução adaptativa, transparência estrutural, coordenação de mercado escalável e resiliência sistêmica. A ideia mais prática é a decomposição contract-first: toda sub-tarefa precisa ter resultado verificável — um teste de unidade, uma checagem formal. Se é caro ou subjetivo demais para verificar, decomponha de novo. É isso que separa "delegar" de "rezar para dar certo".

5. Exemplos concretos

Briefing de pesquisa diário (exemplo clássico da Anthropic): no loop, o agente enfia tudo no contexto, escreve e revisa o próprio rascunho — "como pedir para o autor dar nota ao próprio trabalho" — e lê as fontes uma a uma. No grafo: o nó pesquisador faz fan-out em paralelo e devolve só notas estruturadas; o escritor recebe notas limpas; o revisor julga num contexto novo e devolve se não passar. Contextos isolados, revisão de verdade, paralelismo de verdade.

Orquestrador → especialistas: um supervisor distribui para sub-agentes e decide se aceita ou devolve cada resultado.

Dois detalhes de ouro: quando uma unidade falha, devolva a unidade, não o lote — reprocessar tudo reescreve resultados corretos e o sistema nunca converge. E a diferença entre a aresta de correção (conserta a execução atual) e a aresta de aprendizado (o aceito volta como restrição; sem ela, o grafo nunca fica mais inteligente).

E o ponto mais importante: não é a quantidade de agentes, é o determinismo em volta dos resultados. A causa raiz das falhas é o modelo atuando como atleta e juiz ao mesmo tempo; a solução é separar execução e verificação — um nó validador cujo único trabalho é tentar derrubar a conclusão. A certeza final vem de duas fontes que não discutem: código (testes, validação) e realidade ("os testes passaram", "o dinheiro caiu na conta"). Sem âncoras reais, um grafo é só uma fábrica de alucinações mais organizada.

6. Para onde isso vai: agentic web, protocolos e segurança

O próximo passo é o agentic web: milhões de agentes delegando e negociando entre si — e com humanos. Já se formam os protocolos: MCP (acesso a ferramentas/dados), A2A (descoberta e gestão de tarefas), AP2 (mandatos criptográficos para agentes gastarem em nome de um principal) e UCP (uma "língua de comércio" comum). Com escala vem a segurança: prompt injection, agent traps, agentic viruses (prompts que se auto-replicam), Sybil attacks e cognitive monoculture (mesmos modelos → falhas em cascata). As defesas incluem monitoramento de processo, zero-knowledge proofs e verificação por terceiros.

7. Conclusão prática: como começar

  1. Pegue um agente em loop e liste as etapas que ele executa mentalmente. Cada etapa vira um nó candidato.
  2. Separe julgamento de mecanismo: decisão que precisa de modelo fica no nó; checagem, merge e formatação viram aresta de código.
  3. Torne cada nó verificável: defina o contrato de saída ("o que é pronto?") e o verificador antes do prompt.
  4. Construa a aresta de aprendizado: devolva lições aos nós que as geraram.
  5. Respeite a linha de governança: o workflow graph (como as tarefas se dividem) pode mudar rápido; o role graph (quem pode alterar o banco, aprovar, gastar) muda devagar e é auditável.

E lembre dos números da Anthropic: sistemas multi-agente superaram os de agente único em 90,2% nas avaliações internas — mas consomem ~15x mais tokens. Só valem quando o valor cobre o custo: proteção de contexto, tarefas paralelizáveis e especialização. Tarefa com um objetivo e critério de parada claros? Loop simples é a solução ótima — comece pelo mais simples, desenhe o grafo que cabe num guardanapo. Loop melhora uma unidade; grafo decide quais unidades existem, em que ordem e em paralelo. Os dois juntos — e não um contra o outro — são o futuro da engenharia de agentes.

Referências