Graph Engineering: o novo nível da orquestração de agentes de IA

Graph engineering é a prática de projetar um sistema de agentes de IA como um grafo explícito: nós que fazem um trabalho delimitado, arestas que decidem o que pode rodar em seguida, estado compartilhado, checkpoints e pontos de aprovação humana. É a camada que fica acima do prompt, do contexto e do loop de um agente só.

Resumo

• Graph engineering é projetar um sistema de IA como um grafo explícito de agentes, código determinístico, ferramentas, avaliadores e pessoas, ligados por arestas que dizem o que pode rodar em seguida, todos lendo e escrevendo um estado compartilhado e tipado.
• O termo é novo (ganhou força no meio de 2026) e ainda não tem um sentido único. O mais comum é o grafo de execução: quem roda, em que ordem, em que condição e quem pode interromper.
• Ele não substitui prompt engineering nem context engineering. Ele coordena os dois.
• Grafos multiagente podem superar com folga um agente sozinho em trabalho paralelo e de pesquisa, mas gastam várias vezes mais tokens. Em tarefas com poucos passos paralelizáveis, um agente único bem construído costuma ser a escolha melhor.
• O esforço de engenharia está nas arestas: regras de roteamento, limites de retry, checkpoints e portões de aprovação.

O que é graph engineering

Um agente sozinho é um loop: o modelo raciocina, chama uma ferramenta, lê o resultado e decide o próximo passo. Esse loop funciona bem para uma tarefa única e delimitada. Ele começa a falhar quando o trabalho exige vários tipos de especialidade ao mesmo tempo, etapas que podem rodar em paralelo ou um estado que precisa sobreviver a uma queda, a uma pausa para revisão humana ou a uma execução longa.

Graph engineering resolve isso tornando a estrutura explícita. Um guia publicado na Analytics Vidhya em julho de 2026 define a disciplina como o desenho de nós, dependências, transições de estado, rotas de execução, portões de validação, caminhos de recuperação e limites de controle dentro de um sistema agêntico. Na prática, a aplicação vira um grafo executável cujos nós podem ser uma chamada de LLM, um agente completo, uma função comum, uma consulta ao banco ou uma pessoa aprovando algo.

Um survey publicado no arXiv em agosto de 2026 enquadra a mesma ideia como mais um degrau de uma progressão: de prompt engineering para context engineering, daí para harness e loop engineering, e agora para grafos que coordenam vários agentes rumo a um objetivo comum. Os autores chamam o resultado de inteligência de sistema: a capacidade de um sistema multiagente de organizar suas partes num todo coerente, em vez de depender de um único agente muito capaz.

Cada camada contém as anteriores. Graph engineering coordena prompt, contexto e o loop de um agente; não substitui nenhum deles.

De onde vem o termo e o que ele não é

A expressão é recente e ainda não está consolidada. Um artigo da puppyone, do fim de julho de 2026, identifica três sentidos que disputam o nome:

1. Grafo de execução ou de orquestração. Agentes, código, ferramentas, roteadores e checkpoints humanos ligados por transições permitidas. É o sentido usado neste artigo.
2. Grafo de loops e controles. Avaliadores, retries, checagens de política e auditorias que influenciam uns aos outros. Um enquadramento emergente, ainda não consolidado.
3. Grafo de conhecimento, contexto ou memória. Entidades e fatos ligados por relações tipadas, às vezes com tempo e procedência.

Duas distinções evitam a maior parte da confusão. Um banco de dados de grafo guarda dados, mas não agenda agentes. O GraphRAG usa estrutura de grafo para melhorar a recuperação de informação, mas não orquestra trabalho multiagente. Graph engineering pode usar qualquer um dos dois como um nó, mas é outra coisa.

As peças

Todo grafo de execução é feito do mesmo pequeno conjunto de peças. Acertar cada uma importa mais do que a escolha do framework.

Um grafo de execução mínimo: o roteador distribui o trabalho para workers em paralelo, um reducer junta os resultados e um avaliador aprova, devolve o trabalho (com limite de retries) ou escala para uma pessoa.

• Nós são unidades de trabalho delimitadas. Um nó pode ser uma chamada ao modelo, um agente com ferramentas, uma função ou uma decisão humana. Regras de negócio já conhecidas (uma tabela de preços, o checklist de envio de uma loja) ficam em código determinístico, não num prompt.
• Arestas descrevem o que pode rodar em seguida. Podem ser diretas, condicionais, paralelas, de loop, de tratamento de erro ou controladas por uma pessoa.
• Estado é um registro tipado que percorre o grafo: o objetivo, o plano, os artefatos produzidos até ali, as notas de avaliação e as decisões. Passar estado estruturado em vez da transcrição inteira da conversa mantém o contexto de cada nó pequeno e focado.
• Reducers definem como atualizações paralelas no mesmo campo são combinadas, para que dois workers nunca se sobrescrevam em silêncio.
• Rotas e guardas escolhem a próxima aresta. Restrições rígidas moram no código: "se a nota de embasamento ficar abaixo de 0,8, volta para a pesquisa" é uma regra, não uma sugestão ao modelo.
• Checkpoints registram o estado para que a execução possa ser retomada depois de uma falha, pausada para aprovação, reproduzida ou inspecionada mais tarde.
• Loops (revisar, tentar de novo, chamar a ferramenta outra vez) são ciclos dentro do grafo, e cada um precisa de uma condição de parada.
• Interrupções humanas pausam a execução onde alguém precisa aprovar. Bons sistemas fazem isso com base no risco, em vez de pedir aprovação a cada passo.

O guia da Analytics Vidhya resume a mudança numa frase: "The agents fill the nodes. The engineering lives in the edges." Ou seja, os agentes ocupam os nós, e a engenharia está nas arestas.

Os padrões por baixo

A maioria dos grafos é uma combinação de poucos padrões de workflow que a Anthropic descreveu no guia sobre agentes eficazes, de dezembro de 2024:

• Encadeamento de prompts: a tarefa dividida em etapas sequenciais, com checagens entre elas.
• Roteamento: classificar a entrada e mandá-la para um caminho especializado.
• Paralelização: rodar subtarefas independentes ao mesmo tempo, ou rodar a mesma tarefa várias vezes e comparar (votação).
• Orquestrador e workers: um modelo central quebra o trabalho, delega as partes e junta os resultados.
• Avaliador e otimizador: um modelo produz, outro avalia e devolve feedback, em loop.

O mesmo guia faz uma distinção que continua valendo: num workflow, modelos e ferramentas seguem caminhos definidos no código; num agente, o modelo decide o próprio processo. O grafo permite misturar os dois de propósito: caminhos fixos onde o processo é conhecido, nós agênticos onde é preciso julgamento.

Quanto custa e quando não usar

A evidência pública mais forte a favor de grafos multiagente vem do relato da Anthropic, de junho de 2025, sobre o recurso de pesquisa do Claude. Um agente líder (Claude Opus 4) coordenando subagentes em paralelo (Claude Sonnet 4) superou um agente Opus 4 sozinho em 90,2% na avaliação interna de pesquisa da empresa. O mesmo artigo mostra o preço: agentes usam cerca de quatro vezes os tokens de um chat, e sistemas multiagente, cerca de quinze vezes. Na análise deles, o volume de tokens sozinho explicou cerca de 80% das diferenças de desempenho.

O artigo também é direto sobre onde a abordagem não serve: tarefas em que o resultado não justifica o custo, trabalhos em que todos os agentes precisam do mesmo contexto e tarefas com poucos passos paralelizáveis, o que, segundo os autores, inclui a maior parte das tarefas de programação.

O artigo da Anthropic de março de 2026 sobre harness para apps de longa duração mostra esse trade-off num projeto de software. Um agente sozinho construiu um editor de jogos retrô em cerca de 20 minutos, por uns US$ 9, mas o jogo em si não funcionava. Um harness com planejador, gerador e avaliador levou cerca de seis horas e US$ 200, e entregou uma aplicação funcional. A principal lição do autor vale para qualquer grafo: cada componente codifica uma suposição sobre o que o modelo não consegue fazer sozinho, então vale remover os componentes um de cada vez e manter só os que realmente sustentam o resultado.

Uma regra prática: comece com um agente bem instrumentado. Acrescente um nó só quando souber dizer qual falha ele corrige, e meça se corrige mesmo.

Um fluxo de referência para Smart TV em várias plataformas

Na W2BIT o nosso trabalho são apps de Smart TV e OTT, e esse problema combina naturalmente com um grafo. A mesma feature muitas vezes precisa sair no Samsung Tizen e no LG webOS (apps web, normalmente em React) e no Roku, que tem linguagem própria, o BrightScript, e o framework de interface SceneGraph. As plataformas compartilham requisitos, mas não código, e cada uma tem a sua revisão de loja.

Este é o grafo de referência que usamos para pensar esse tipo de trabalho:

Uma feature, três plataformas de TV. Agentes fazem o trabalho paralelo; checagens determinísticas e o QA em device decidem se ele avança; pessoas cuidam do code review e do envio às lojas.

1. Um agente planejador transforma o ticket numa spec curta e num contrato de pronto: os critérios de aceite por plataforma, escritos antes de existir qualquer código. O contrato é salvo como arquivo e passa por um checkpoint.
2. Os workers de cada plataforma rodam em paralelo, um por plataforma. Cada um recebe só o contexto de que precisa: o contrato, o código da sua plataforma e as convenções dela. O worker do Roku não precisa dos componentes React, e vice-versa.
3. Build, lint e testes unitários são nós determinísticos. Uma falha aqui nunca vai para um modelo interpretar; volta direto para o worker que a causou.
4. Um avaliador de QA em device checa o que importa na TV: navegação por foco com o controle remoto, memória numa sessão longa e comportamento do player. Critérios reprovados voltam como correções pontuais para o worker específico, com limite de retries.
5. Pessoas ficam com os passos irreversíveis: code review e envio às lojas. Essas arestas são controladas por humanos de propósito.

O grafo não torna o engenheiro dispensável. Ele muda onde está a atenção do engenheiro: de digitar cada linha para desenhar o contrato, as checagens e os portões, e revisar o que o grafo produziu.

Checklist antes de montar um

• Nomeie a falha primeiro. O que um agente sozinho não consegue fazer aqui: trabalho paralelo, contextos isolados, verificação, execução longa?
• Mantenha regras conhecidas no código. Roteamento, limites, checklists e número de retries são código, não prompt.
• Use estado tipado, não transcrição. Cada nó deve ver o menor contexto que permita fazer o seu trabalho.
• Limite todo loop. Número máximo de revisões, um orçamento e uma saída para uma pessoa.
• Faça checkpoints persistentes. Frameworks como o LangGraph salvam o estado por thread com checkpointers, o que viabiliza revisão humana, "viagem no tempo" e recuperação; em produção, use um armazenamento persistente (por exemplo, Postgres).
• Coloque pessoas onde está o risco. Portões de aprovação em ações irreversíveis ou de alto impacto, não em todo passo.
• Observe o grafo, não só as chamadas. Registre cada transição, nota e decisão, para saber qual aresta falhou.
• Meça o custo por resultado. Tokens, tempo e dinheiro por tarefa concluída, comparados com a versão mais simples.

Sobre frameworks: o LangGraph é a escolha prática mais comum, e o Google ADK e o Microsoft Agent Framework cobrem um terreno parecido. Código comum com filas, banco de dados e uma máquina de estados também funciona. O grafo é primeiro uma decisão de projeto, e só depois a escolha de uma biblioteca.

O que ainda está em aberto

O survey do arXiv é franco sobre as lacunas. A maioria dos sistemas atuais se adapta dentro de uma estrutura fixa; pouquíssimos revisam a própria estrutura com base na evidência acumulada. Os autores separam sistemas que apenas têm forma de grafo dos que são projetados como grafo, o que exige objetivos estruturais explícitos, observabilidade no nível do grafo, mudanças controladas na estrutura e evidência de melhora duradoura. Entre os problemas abertos estão manter o significado alinhado entre agentes, a governança de quem pode alterar o grafo, a avaliação, a privacidade e o autoaperfeiçoamento seguro.

É uma boa régua para qualquer time que adote a ideia: desenhar caixas e setas é fácil; mostrar que o grafo supera de forma mensurável o desenho mais simples é a parte de engenharia.

Perguntas frequentes

O que é graph engineering em IA?

Graph engineering é o desenho de um sistema de IA como um grafo explícito de agentes, código determinístico, ferramentas, avaliadores e pessoas, ligados por arestas que definem o que pode rodar em seguida e compartilhando um estado tipado. Cobre roteamento, trabalho paralelo, loops de retry, checkpoints e pontos de aprovação humana.

Graph engineering é a mesma coisa que LangGraph, GraphRAG ou grafo de conhecimento?

Não. O LangGraph é um framework para construir grafos de execução. O GraphRAG usa estruturas de grafo para melhorar a recuperação de informação, e um grafo de conhecimento guarda fatos interligados. Graph engineering é a disciplina de projeto; esses podem ser ferramentas ou nós dentro dela.

Qual a diferença entre graph engineering, prompt engineering e context engineering?

Prompt engineering molda uma chamada ao modelo, e context engineering controla o que cada chamada enxerga. Graph engineering coordena muitas chamadas, agentes, funções e pessoas ao longo de uma tarefa inteira. Um bom grafo continua dependendo de bons prompts e de bom contexto em cada nó.

Quando não vale usar um grafo multiagente?

Quando a tarefa tem poucos passos que podem rodar em paralelo, quando todos os agentes precisariam do mesmo contexto completo ou quando o custo extra não se justifica pelo resultado. A Anthropic relata que sistemas multiagente usam cerca de quinze vezes os tokens de um chat, e que a maioria das tarefas de programação tem poucos passos paralelizáveis.

Como a W2BIT usa agentes no desenvolvimento para Smart TV?

Usamos agentes em trabalho paralelo e bem especificado, como implementar a mesma feature para Tizen, webOS e Roku a partir de um contrato de aceite escrito, e mantemos checagens determinísticas, critérios de QA em device e revisão humana entre os agentes e tudo o que vai para produção.

Fontes

1. Harsh Mishra, "Graph Engineering for AI Agents: Beyond the Single-Agent Loop", Analytics Vidhya, 28 jul. 2026. https://www.analyticsvidhya.com/blog/2026/07/graph-engineering/
2. Yuyuan Feng et al., "Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence", arXiv:2608.21156, 21 ago. 2026. https://arxiv.org/abs/2608.21156
3. puppyone, "What Is Graph Engineering for AI Agents? Execution Graphs, Context Graphs, and Loops", 30 jul. 2026. https://www.puppyone.ai/en/blog/graph-engineering-ai-agents-map
4. Anthropic, "Building effective agents", 19 dez. 2024. https://www.anthropic.com/engineering/building-effective-agents
5. Anthropic, "How we built our multi-agent research system", 13 jun. 2025. https://www.anthropic.com/engineering/multi-agent-research-system
6. Anthropic, "Harness design for long-running apps", 24 mar. 2026. https://www.anthropic.com/engineering/harness-design-long-running-apps
7. LangChain, "LangGraph persistence" (documentação). https://docs.langchain.com/oss/python/langgraph/persistence