Graph Engineering: a próxima evolução da engenharia de software com Agentes de IA
Durante os últimos anos, grande parte da evolução da IA generativa aplicada ao desenvolvimento de software foi apresentada como uma evolução na forma de escrever prompts.
Primeiro tivemos Prompt Engineering.
Depois percebemos que fornecer uma boa instrução não era suficiente. O modelo precisava receber documentação, código, histórico, regras e informações relevantes para executar uma tarefa corretamente. Surgiu então o conceito de Context Engineering.
Com a evolução dos agentes de IA, surge agora uma terceira camada:
Graph Engineering.
A ideia é relativamente simples, mas muda profundamente a maneira como podemos pensar o desenvolvimento de software assistido por IA.
Em vez de perguntar:
“Qual prompt devo enviar para o modelo?”
passamos a perguntar:
“Qual sistema de agentes, estados, verificações e loops deve executar esse trabalho?”
A unidade de engenharia deixa de ser apenas o prompt.
Passa a ser o grafo de execução.
De Prompt Engineering para Graph Engineering
Podemos representar essa evolução da seguinte maneira:
Prompt Engineering
Humano → Prompt → LLM → Resposta
O usuário fornece uma instrução e recebe uma resposta.
Context Engineering
Aqui o problema deixa de ser apenas escrever uma boa pergunta.
Precisamos selecionar e disponibilizar o contexto correto.
Graph Engineering
Agora não estamos mais simplesmente conversando com um modelo. Estamos construindo um sistema de trabalho executado por agentes.
Essa mudança é importante porque tarefas complexas raramente podem ser resolvidas adequadamente em uma única interação.
Desenvolver uma funcionalidade corporativa, por exemplo, pode envolver:
entender requisitos;
analisar arquitetura;
consultar documentação;
alterar código;
executar testes;
verificar segurança;
revisar a implementação;
corrigir problemas;
validar critérios de aceite;
gerar documentação;
preparar uma release.
Não existe necessariamente um único prompt capaz de executar tudo isso de forma confiável.
Existe, porém, a possibilidade de criar um grafo capaz de coordenar agentes especializados.
O que é Graph Engineering?
Graph Engineering é a disciplina de projetar explicitamente como agentes, ferramentas, estados, verificadores e humanos se relacionam durante a execução de um trabalho complexo.
Um grafo normalmente possui três elementos fundamentais:
Nodes — nós
Representam unidades de trabalho.
Um nó pode ser:
um agente;
uma chamada de API;
uma execução de teste;
uma consulta a banco;
um MCP Server;
uma aprovação humana;
um script;
um sistema externo.
Edges — conexões
Definem como o trabalho passa de um nó para outro.
Por exemplo:
Architect Agent → Backend Agent
ou:
QA Agent → Backend Agent
caso algum teste falhe.
State — estado
É a informação compartilhada ao longo da execução.
Pode incluir:
requisitos;
Agent Specs;
decisões arquiteturais;
código;
resultados de testes;
erros encontrados;
documentação;
evidências;
histórico das execuções.
O estado permite que diferentes agentes trabalhem sobre o mesmo problema, sem depender de reconstruir todo o contexto a cada interação.
O elemento mais importante: loops
Um dos maiores diferenciais dos grafos é que eles não precisam representar apenas pipelines lineares.
Eles podem conter loops.
Esse pequeno loop representa uma mudança importante.
O agente não simplesmente gera código e termina.
Ele pode:
implementar → testar → observar → corrigir → testar novamente
até atingir determinada condição.
É aqui que agentes começam a trabalhar por períodos maiores com menor necessidade de intervenção humana.
O objetivo deixa de ser obter uma boa resposta do modelo.
Passa a ser alcançar um estado verificável do sistema.
O papel dos agentes muda
Em uma arquitetura desse tipo, não precisamos necessariamente de um “superagente” tentando resolver tudo.
Podemos criar agentes especializados.
Cada agente possui:
responsabilidade;
ferramentas;
contexto;
permissões;
critérios de sucesso.
Essa especialização permite aplicar um princípio conhecido da engenharia de software:
separação de responsabilidades.
Só que agora aplicado também à força de trabalho digital.
O Judge Agent
Um componente particularmente importante é o agente avaliador.
Ele não necessariamente cria alguma coisa.
Sua função é julgar o resultado produzido por outros agentes.
Imagine três agentes:
Planner → Builder → Judge
O Planner define o plano.
O Builder executa.
O Judge verifica.
Se houver problema:
Judge → Planner ou Builder → nova execução.
Esse padrão cria um mecanismo de feedback.
Em vez de simplesmente confiar na primeira saída do modelo, construímos um sistema que tenta verificar sua própria execução.
Mas existe uma distinção crítica.
Sempre que possível, o Judge não deveria avaliar apenas subjetivamente.
Devemos fornecer evidências objetivas:
testes automatizados;
lint;
análise estática;
testes de segurança;
contratos de API;
testes Playwright;
métricas;
políticas;
evals.
Quanto mais verificável for o resultado, mais confiável pode ser o loop.
Graph Engineering não significa transformar tudo em grafo
Existe também um risco.
Criar dezenas de agentes, conexões e loops para um problema simples pode tornar o sistema:
mais caro;
mais lento;
mais difícil de observar;
mais difícil de depurar;
menos previsível.
Uma tarefa como:
“Resuma este documento”
provavelmente não precisa de cinco agentes.
Da mesma forma:
“Converta este JSON para outro formato”
pode ser resolvido por código determinístico.
Graph Engineering faz mais sentido quando existe:
complexidade + múltiplas competências + feedback + possibilidade de verificação.
Um princípio útil é:
Não transforme uma sequência simples em um grafo complexo apenas porque agentes estão disponíveis.
O Fake-Edge Test
Uma ideia interessante associada à discussão sobre Graph Engineering é verificar se as conexões entre agentes são realmente necessárias.
Pergunte:
B realmente depende do resultado produzido por A?
Se a resposta for não, talvez essa conexão seja artificial.
Da mesma forma:
C realmente precisa esperar B?
Talvez B e C possam trabalhar paralelamente.
Isso pode reduzir drasticamente o tempo de execução.
Graph Engineering também é, portanto, uma disciplina de engenharia de dependências.
Paralelismo muda a produtividade
Essa arquitetura abre outra possibilidade importante.
Agentes não precisam trabalhar necessariamente em sequência.
Imagine uma especificação já aprovada.
Parte da produtividade prometida por sistemas multiagentes vem exatamente dessa capacidade de paralelizar trabalho cognitivo.
MCP e Graph Engineering
Existe outra peça importante nessa arquitetura: Model Context Protocol (MCP).
O grafo determina quem trabalha, quando trabalha e quais dependências existem.
O MCP pode ajudar a determinar quais ferramentas e informações cada agente pode utilizar.
Essa separação é importante.
Graph = orquestração do trabalho.
MCP = acesso governado às capacidades necessárias para executar o trabalho.
A combinação dos dois cria uma base interessante para sistemas agênticos corporativos.
Graph Engineering aplicado ao desenvolvimento de software
Considere uma empresa que deseja implementar uma nova funcionalidade.
Em um modelo tradicional, handoffs entre PO, Arquiteto, UX, Desenvolvedor, QA e DevOps frequentemente criam:
perda de contexto;
documentação incompleta;
retrabalho;
inconsistências;
atrasos.
Com agentes podemos transformar esse processo em um grafo operacional.
Mas existe uma diferença fundamental.
Não é apenas uma sequência.
Existem loops.
Se QA encontrar um problema arquitetural:
QA → Architect → Developer → QA
Se um teste de segurança falhar:
Security → Developer → Security
Se UAT rejeitar uma funcionalidade:
UAT → PO → Developer → QA → UAT
O processo passa a ser um grafo vivo de execução.
Da metodologia para a execução: ASDD
Essa visão tem forte relação com o Agentic Spec-Driven Development (ASDD).
Na metodologia ASDD da SeedTS, o ciclo de desenvolvimento é dividido em etapas especializadas apoiadas por agentes:
A evolução natural é deixar de enxergar essas etapas somente como um workflow e passar a tratá-las como um grafo de engenharia.
Cada etapa se torna um node.
Cada dependência vira uma edge.
Cada artefato produzido atualiza o state.
Cada rejeição cria um loop.
Cada MCP disponibiliza ferramentas controladas.
Cada gate determina se o sistema pode continuar.
Isso transforma a metodologia em algo maior que um processo documentado. Ela pode se tornar um sistema executável de engenharia de software.
A importância da memória
Quando agentes trabalham durante horas ou dias, outro problema aparece:
continuidade.
Um agente precisa saber:
o que já foi feito;
quais decisões foram tomadas;
quais tentativas falharam;
qual versão está sendo utilizada;
quais dependências existem;
quais problemas continuam abertos.
Por isso, Graph Engineering precisa conversar com Memory Engineering.
Podemos pensar em três níveis:
Working State
Estado daquela execução.
Project Memory
Decisões persistentes do projeto.
Domain Knowledge
Conhecimento compartilhado da organização.
O agente não deveria precisar redescobrir decisões arquiteturais a cada execução.
Governança torna-se parte do grafo
Em sistemas corporativos, nem todas as decisões podem ser tomadas autonomamente.
Por isso podemos introduzir gates humanos.
Governança deixa de ser apenas um documento dizendo o que o agente deveria fazer.
Ela passa a ser parte da própria topologia do sistema.
Esse conceito é especialmente importante para setores regulados.
Observabilidade também precisa acompanhar o grafo
Se dezenas de agentes estiverem trabalhando simultaneamente, precisamos responder:
qual agente tomou determinada decisão?
qual contexto recebeu?
quais tools utilizou?
quanto custou?
quanto demorou?
qual modelo utilizou?
qual versão do prompt/skill estava ativa?
quais agentes participaram?
qual avaliação permitiu continuar?
qual humano aprovou?
Por isso Graph Engineering naturalmente leva a AgentOps.
Precisamos observar não apenas serviços.
Precisamos observar trajetórias de execução.
Do CI/CD para Agentic CI/CD
Existe ainda uma consequência importante.
O pipeline tradicional Code → Build → Test → Deploy pode evoluir para:
O CI/CD passa a administrar não somente artefatos de software.
Passa a administrar também:
agentes;
prompts;
skills;
MCP contracts;
evals;
modelos;
memória;
políticas;
budgets;
versões de contexto.
É a convergência entre DevOps AI, LLMOps e AgentOps.
O desenvolvedor desaparece?
Não.
Mas sua função começa a mudar.
Quanto maior a capacidade dos agentes de executar tarefas, maior tende a ser o valor de quem consegue:
decompor problemas;
definir especificações;
projetar arquiteturas;
estabelecer critérios;
construir evals;
desenhar grafos;
definir políticas;
revisar decisões;
validar resultados.
Em outras palavras:
menos microgerenciamento da geração e mais engenharia do sistema que gera.
O profissional deixa de pensar apenas:
“Como eu implemento isso?”
e começa também a pensar:
“Como construo um sistema capaz de implementar, testar e verificar isso repetidamente?”
O futuro pode ser Spec → Graph → Software
Durante décadas tivemos Requirement → Human → Code.
Com copilotos: Requirement → Human + AI → Code.
Com sistemas agênticos que constroem software, ou Fábricas agênticas:
Essa talvez seja uma das mudanças mais importantes trazidas pelos agentes de IA.
Código continua existindo.
Mas o ativo intelectual começa a subir de nível.
O que passa a ter cada vez mais valor são:
Specs + Graphs + Context + Evals + Policies.
O código torna-se, em determinados cenários, cada vez mais uma consequência desses elementos.
Graph Engineering não substitui Software Engineering
Esse ponto é fundamental.
Graph Engineering não elimina:
arquitetura;
DDD;
segurança;
APIs;
testes;
DevOps;
engenharia de dados;
observabilidade.
Na realidade, aumenta a importância dessas disciplinas.
Quanto maior a autonomia concedida aos agentes, mais precisamos de limites claros e resultados verificáveis.
A pergunta deixa de ser:
“O agente consegue fazer?”
e passa a ser:
“O agente consegue fazer de maneira repetível, segura, observável e governada?”
Essa é uma pergunta de engenharia.
Na SeedTS, Graph Engineering conecta ASDD, Agent Specs, MCP Contracts, Evaluation Suite, AgentOps e gates humanos em um sistema executável de entrega de software — não apenas em um conjunto de prompts.
Conclusão
Prompt Engineering ensinou empresas a conversar melhor com modelos.
Context Engineering ensinou a fornecer aos modelos as informações corretas.
Graph Engineering começa a ensinar algo diferente:
Como organizar trabalho realizado por múltiplos agentes.
O próximo salto de produtividade provavelmente não virá simplesmente de encontrar um modelo 10% melhor.
Pode vir da capacidade de combinar:
Agentes + Grafos + Contexto + Memória + MCP + Evals + Governança.
Para empresas, isso representa uma mudança ainda maior.
Não se trata apenas de colocar um chatbot sobre sistemas existentes.
Trata-se de construir uma arquitetura agêntica na qual agentes possam observar, decidir, colaborar e executar ações dentro de limites definidos.
E, para engenharia de software, talvez a principal mudança seja esta:
O desenvolvedor do futuro não programará apenas aplicações.
Ele também projetará os sistemas de agentes capazes de construí-las, testá-las, operá-las e continuamente melhorá-las.
Como a SeedTS atua nesse cenário
Na SeedTS, Graph Engineering conecta ASDD, Agent Specs, MCP Contracts, Evaluation Suite, AgentOps e gates humanos em um sistema executável de entrega de software — não apenas em um conjunto de prompts.
Comentários