Toda ferramenta nova em inteligência artificial parece vir acompanhada de um nome novo para batizar. Prompt engineering, context engineering, harness engineering, loop engineering, e agora "graph engineering". Recentemente vi um vídeo de uma criadora de conteúdo que acompanho de perto apresentando o graph engineering como o próximo estágio de maturidade na forma de organizar agentes de inteligência artificial trabalhando juntos. Antes de incorporar qualquer coisa assim ao ecossistema de IA que já uso no dia a dia do escritório, pedi que se fizesse uma pesquisa séria sobre o assunto, em quatro frentes independentes: literatura acadêmica, doutrina histórica de ciência da computação, documentação dos próprios fabricantes das ferramentas, e a crítica prática de quem já roda esses sistemas em produção.
O resultado surpreendeu por dois motivos.
O primeiro é que o mecanismo em si não tem nada de novo. Representar unidades de trabalho como nós de um grafo, e as dependências entre elas como arestas condicionais, é doutrina formalizada em ciência da computação entre 1955 e 1973: as máquinas de estado de Mealy e Moore, as redes de Petri de Carl Adam Petri, o modelo de atores de Carl Hewitt, a programação dataflow do MIT. Como prática de engenharia de produção, motores como o BPMN (2004), o Apache Airflow (2014), o Temporal e o Argo Workflows já resolvem exatamente esse problema há décadas, para pipelines de dados e processos de negócio. Um artigo de divulgação da própria safra de 2026 reconhece isso sem rodeios: quem já usou o LangGraph já estava fazendo graph engineering sob outro nome. O que muda agora é o tipo de nó: em vez de uma tarefa determinística, o nó passa a ser um agente de modelo de linguagem, que raciocina e decide seu próprio próximo passo. É uma aplicação nova de uma ideia antiga, não uma invenção.
O segundo motivo é mais importante, e menos intuitivo. A evidência acadêmica mais recente e rigorosa que encontramos, um estudo de dezembro de 2025 que testou 260 configurações em 6 benchmarks e 5 arquiteturas diferentes, mostra que orquestrar múltiplos agentes como um grafo só supera um agente único quando a tarefa se decompõe em partes genuinamente paralelas, que não competem pela mesma decisão de escrita. Nessas tarefas, a arquitetura em grafo realmente ganha, e ganha bastante: a própria Anthropic mediu um ganho de 90,2% no seu sistema de pesquisa multiagente. Mas quando a tarefa exige raciocínio sequencial, com dependência forte entre os passos, a mesma arquitetura piora o resultado entre 39% e 70% frente a um agente único bem especificado, e ainda custa mais caro (a Anthropic relata cerca de 15 vezes mais tokens consumidos). Um post de crítica prática da Cognition, a empresa por trás do agente de codificação Devin, chega a documentar um caso real de dois subagentes construindo partes incompatíveis de um mesmo programa, cada um sem visibilidade da decisão do outro.
A conclusão prática que ficou, e que já apliquei ao protocolo interno que uso para decidir quando vale a pena acionar múltiplos agentes de IA em vez de um só: a pergunta certa nunca é quantas partes tem uma tarefa. A pergunta certa é se essas partes competem entre si pela mesma decisão, ou se dependem umas das outras em sequência. Cinco frentes de trabalho genuinamente paralelas e independentes justificam orquestração estruturada. Cinco frentes que na prática dependem umas das outras, mesmo que pareçam separadas no papel, não justificam, e um agente único, bem orientado, tende a produzir resultado igual ou melhor, a um custo bem menor. A única exceção que sobreviveu a toda a crítica que li, sem ressalva, é a verificação independente de um trabalho já pronto: um segundo agente, sem acesso ao raciocínio do primeiro, revisando ou auditando o que foi produzido. Isso é exatamente o que já fazíamos, antes mesmo dessa pesquisa, na auditoria mais crítica das peças que produzimos.
Vale reter uma coisa desse episódio inteiro, além da conclusão técnica. O termo novo quase nunca é o que importa. O que importa é a pergunta que ele força a fazer de novo, com mais cuidado. Graph engineering não vai substituir nada no meu vocabulário de trabalho, mas a pergunta que ele levantou, sobre quando vale a pena coordenar mais de um agente e a que custo, ficou mais afiada do que estava antes.
Fontes
- Kim et al. "Towards a Science of Scaling Agent Systems." arXiv:2512.08296, dezembro de 2025.
- Dennis, Diamond, Patil, Shabahang, Guo. "In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks." arXiv:2604.27891, 2026.
- Anthropic. "How we built our multi-agent research system." Anthropic Engineering, junho de 2025.
- Cognition. "Don't Build Multi-Agents." Cognition Blog, junho de 2025.
- Cemri, Pan, Yang et al. "Why Do Multi-Agent LLM Systems Fail?" arXiv:2503.13657. NeurIPS 2025.