Um grafo de agents é um diagrama. Rodá-lo é um sistema operacional.

Desenhe num quadro branco e graph engineering parece resolvido. Um node pesquisador se espalha em três nodes de busca, que convergem de volta num node redator, um node revisor confere o rascunho e o devolve em caso de falha. Caixas limpas, setas limpas, todo mundo concorda com a cabeça. Aí você tenta rodar isso numa segunda-feira, e o diagrama silenciosamente vira você: copiando a saída do pesquisador para o prompt do redator, lembrando qual rascunho o revisor já rejeitou, segurando o estado que as setas só fingiam carregar. O grafo nunca foi a parte difícil. Rodar um sem virar a fiação dele é.

Graph engineering é como você roda muitos loops de agents como um único sistema governado, e você o roda sobre um sistema operacional de IA, um sistema de registro que cada loop lê e escreve, um sistema de inteligência que raciocina sobre ele, e um sistema de ação que executa, não sobre uma pasta de agents colados à mão. Este texto é sobre essa lacuna: por que o diagrama é de graça, por que o runtime é o jogo inteiro, e por que rodar graph engineering é um problema de sistema operacional, não um problema de desenho.

O grafo é a ideia certa

Comece dando à ideia o crédito que ela merece, porque ela é real. Um ano atrás a unidade de trabalho era o prompt. Depois Boris Cherny descreveu o próprio trabalho numa frase que se espalhou rápido: “Eu não faço mais prompt no Claude. Eu tenho loops rodando que fazem prompt no Claude e descobrem o que fazer. Meu trabalho é escrever loops.” Um loop é o ciclo externo de um agent, descobrir, planejar, executar, verificar, repetir, com o agent dirigindo o ciclo em vez de um humano clicando em cada passo. Depois, em julho, Peter Steinberger postou a piada que batizou a próxima camada, “Ainda estamos falando de loops ou já migramos para grafos?”, e o enquadramento se assentou numa pilha: um prompt molda uma chamada, um harness é o código em torno do modelo, um loop é o ciclo de um agent, e um grafo é a organização desses loops, nodes especialistas ligados por arestas que roteiam, fazem fan out, fan in, e vetam. É cumulativo, não uma substituição: um grafo é cheio de nodes, um bom node é um loop bem rodado, um bom loop precisa de um harness de verdade. Isso tudo se sustenta, e a mecânica, node, aresta, estado compartilhado, um node verificador que é um agent diferente do produtor, vale a pena construir em cima.

Mas repare no que o diagrama assume e nunca entrega. Toda seta assume que um pedaço de estado se move de um node para o próximo e chega intacto. Todo “fan back in” assume que algo funde os resultados paralelos sem perder metade deles. Todo “devolver em caso de falha” assume uma memória do que já falhou. As caixas são os 20% fáceis. O estado que flui entre elas, e a coisa que o segura, são os outros 80%, e isso não está no quadro branco.

O jeito ingênuo de rodar: colar os agents à mão

Então como os times de fato rodam um grafo hoje. A resposta honesta, para a maioria, é à mão. Você abre o Claude Code num lugar, o Codex em outro, um chat assistant num terceiro, talvez um background worker em algum canto, e você mesmo conecta tudo: a saída de um vira o prompt que você cola no próximo, e a sua própria atenção é o estado compartilhado que mantém a coisa toda coerente. Funciona para um demo. É um grafo do jeito que uma fila de pessoas passando bilhetes é uma rede.

Isso falha por uma razão estrutural, e é sempre a mesma razão: não existe um sistema de registro compartilhado. Cada agent guarda o próprio contexto, então nada além de você conhece o estado inteiro do trabalho. No instante em que o grafo tem mais que um par de nodes, você é o fio, copiando contexto entre ferramentas, reconciliando as discordâncias entre elas, lembrando o que cada uma já fez, exatamente o problema do clipboard que aparece no instante em que você tenta orquestrar agents à mão. E porque nada segura o registro, nada consegue auditá-lo: quando um node alega que terminou, não há um livro-razão compartilhado contra o qual checar a alegação, então “pronto” é uma mensagem em que você confia em vez de um fato que você consegue verificar.

Os frameworks que de fato te dão um runtime de grafo, LangGraph, o Agent Development Kit do Google, o AutoGen graph flow da Microsoft, são reais e são anteriores ao buzzword, o que os céticos tinham razão em apontar. Eles te entregam nodes, arestas, roteamento condicional, até execução durável que retoma depois de um crash. O que eles não te entregam é o sistema de registro da sua empresa. Eles rodam o grafo; eles não seguram a verdade sobre a qual o grafo deveria operar. Essa é a diferença entre uma biblioteca de orquestração e um sistema operacional, e é a diferença que decide se o grafo roda a sua empresa ou só roda um script.

O que de fato roda um grafo: as três camadas

Aqui está a parte que o diagrama deixa de fora, e é a resposta inteira para “como você roda graph engineering.” Você roda sobre três camadas, e um sistema operacional de IA é a coisa que te dá as três de uma vez.

A primeira é um sistema de registro: um único lugar de onde o grafo inteiro lê o estado e para onde escreve os resultados. É isso que transforma as setas de ilusão em encanamento de verdade, porque o estado não viaja de node a node na memória de alguém, ele mora no registro e cada node lê e escreve a mesma cópia. A segunda é um sistema de inteligência: o próprio grafo de loops, raciocinando sobre esse registro, os nodes especialistas decidindo o que fazer a seguir. A terceira é um sistema de ação: a camada de execução que carrega essas decisões contra sistemas reais e escreve o resultado de volta no registro de onde ele partiu, para que o loop de fato feche em vez de parar numa recomendação que um humano ainda precisa carregar. Essas três camadas são a arquitetura para a qual a era da IA está convergindo, e graph engineering é o que você faz em cima delas depois que você as tem.

Rode um grafo sobre essas três camadas e os modos de falha da versão conectada à mão desaparecem. O estado para de vazar porque existe um único registro. A coordenação para de morar na sua cabeça porque ela mora no registro que cada node compartilha. E “pronto” para de ser uma mensagem em que você confia, porque o registro guarda uma trilha de auditoria e um node verificador que o loop produtor não consegue reescrever avalia o trabalho contra a verdade fundamental. O grafo continua sendo o design. O sistema operacional é o que faz o design ser uma coisa que roda.

Por que a ApolloSpace AI trata isso como um problema de sistema operacional

Esta é a aposta por trás da ApolloSpace AI, dita sem rodeios: graph engineering não é um diagrama que você compra, é um sistema operacional sobre o qual você roda o trabalho da sua empresa. A Apollo é construída para que os seus agents sejam nodes num único grafo sobre um sistema de registro compartilhado, os loops raciocinem sobre esse registro como um sistema de inteligência, e um sistema de ação execute e escreva o resultado de volta, com a fundamentação já conectada desde o início, âncoras que leem resultados reais, regras que os loops são proibidos de ajustar, e um portão humano que vive fora da otimização em vez de como um passo dentro dela. Você não monta isso a partir de uma pasta de agents separados, assim como você não monta um sistema operacional abrindo cinco apps ao mesmo tempo. O sistema operacional era a coisa que faltava debaixo do grafo esse tempo todo.

Esse enquadramento também nos mantém honestos sobre o custo, porque um sistema operacional é um compromisso maior que uma biblioteca. Você abre mão da liberdade de trocar a melhor ferramenta disponível para cada node, em troca de as três camadas ficarem dentro de uma única fronteira onde o loop consegue de fato fechar e ser auditado. Para um script de fim de semana, essa troca não vale a pena, conecte dois agents à mão e siga em frente. Para uma empresa que quer que o trabalho dela rode como um sistema em vez de uma pilha de abas, é a única troca que termina com um grafo que roda sozinho em vez de um grafo que roda você.

A virada: o diagrama é de graça, o sistema operacional é o moat

Qualquer um consegue desenhar o grafo. As caixas e as setas já são commodity, os frameworks já vêm com elas, e um concorrente consegue copiar o seu diagrama de um slide numa tarde. O que ele não consegue copiar do slide é o sistema operacional por baixo: o sistema de registro ao qual os seus loops estão conectados, a fundamentação que os mantém tocando a realidade, a trilha de auditoria que faz de “pronto” um fato. Isso não está no quadro branco, e é a diferença inteira entre um grafo de agents que parece impressionante num demo e um que roda silenciosamente as suas operações numa terça-feira enquanto você está fazendo outra coisa.

Então a resposta para “a gente já migrou de loops para grafos” é sim, e também é a pergunta errada. A mudança que importa não é de loops para grafos. É de um diagrama de agents para um sistema operacional que os roda, de você ser o fio para um sistema de registro ser o fio, de um grafo que você coordena à mão para um grafo que se coordena sozinho porque tudo que ele precisa mora num único lugar fundamentado.

---

A ApolloSpace AI é esse sistema operacional: os seus loops de agents como um único grafo governado, rodando sobre um sistema de registro, um sistema de inteligência, e um sistema de ação, para que o grafo que você desenha seja o grafo que de fato roda, fundamentado e auditado, em vez de um diagrama que você segura junto à mão. Se você quer rodar graph engineering em vez de só desenhar, entre para a lista de early access.