Seu loop funciona. O sistema pode estar piorando.

Fala, pessoal. Jonata aqui.

Peter Steinberger resumiu uma mudança inteira da arquitetura de agentes em uma pergunta:

A piada funcionou porque muita gente que constrói agentes reconheceu a transição. O loop continua sendo a base. A dúvida é o que fazer quando um loop funciona perfeitamente e, mesmo assim, piora o sistema.

Imagine uma equipe de suporte que passa meses melhorando o chatbot da empresa. A métrica escolhida é a taxa de resolução de chamados. Toda semana o time mede o número, ajusta prompts e políticas e vê a curva subir.

Cinco meses depois, chega o dado de renovação: os clientes estão saindo duas vezes mais.

O bot aprendeu a "resolver" chamados encerrando conversas cedo, desencorajando perguntas e marcando como resolvidos problemas que só foram abandonados. O loop funcionou. A métrica melhorou. O sucesso do loop foi o mecanismo da falha.

Esse exemplo abre o ensaio From Loop Engineering to Graph Engineering?, que serviu de base para esta edição.

O loop é o átomo da melhoria

Quase todo processo de melhoria pode ser reduzido a quatro movimentos:

1. escolha algo para controlar;

2. defina uma referência;

3. meça a distância até ela;

4. aja para reduzir essa distância e repita.

Um termostato faz isso com temperatura. Um time de produto faz com retenção. Uma equipe de IA faz com avaliações do modelo. Plan-do-check-act, retrospectivas, testes A/B e loops de treinamento usam a mesma estrutura.

O loop virou o "hello world" de quem constrói sistemas porque é simples, barato e poderoso. Você fecha o ciclo e vê o número responder.

Só que um loop enxerga o mundo pela variável que recebeu. Essa limitação produz quatro falhas recorrentes.

Onde o loop isolado quebra

A primeira é a lei de Goodhart: uma medida otimizada com força suficiente deixa de medir o que media. O chatbot do exemplo não estava quebrado. Ele encontrou a forma mais barata de aumentar a taxa de resolução, mesmo que isso traísse o motivo pelo qual a taxa existia.

A segunda é a cegueira para cima. O loop aproxima uma variável de uma referência, mas não consegue perguntar se a referência faz sentido. Um termostato não questiona a temperatura escolhida. Um agente não decide sozinho se o benchmark mede algo que o cliente percebe. Quanto mais eficiente for o loop, mais rápido ele pode alcançar um alvo ruim.

A terceira é o conflito. Sistemas reais têm vários loops. Um otimiza velocidade; outro, qualidade. Um acelera contratação; outro tenta preservar cultura. Vistos separadamente, todos podem estar funcionando. Juntos, podem puxar o sistema em direções opostas.

A quarta é a degradação da medição. Sensores desviam, pipelines quebram e definições mudam enquanto o dashboard continua verde. Em algum momento, o sistema pode começar a conferir um relatório contra outro relatório sem que nenhum deles encoste na realidade.

O grafo: loops observando loops

Sistemas maduros não eliminam loops. Eles os conectam.

Em uma operação séria de machine learning, o ciclo não termina em "treinar e publicar". Um modelo candidato precisa superar o atual. Outro loop observa drift nos dados. Um mecanismo de rollback reage se métricas pós-deploy saírem dos limites. Um conjunto de avaliação que o treinamento nunca vê tenta impedir que o modelo aprenda a jogar com a própria prova.

Cada parte continua sendo um loop. A confiabilidade passa a morar nas conexões: quem alimenta quem, quem observa quem, quem pode contestar e quem pode vetar.

O artigo-base organiza essas conexões em quatro respostas para as falhas do loop isolado:

• Goodhart pede pareamento: a métrica otimizada viaja com uma contramétrica capaz de revelar a vitória barata;

• cegueira para cima pede hierarquia: um loop mais lento pode revisar a referência do loop rápido;

• conflito pede arbitragem: alguém precisa ser dono do trade-off entre objetivos incompatíveis;

• degradação da medição pede auditoria: um ciclo independente verifica se os números ainda correspondem ao mundo.

Isso é o que o termo graph engineering tenta capturar. A unidade de desenho deixa de ser um ciclo solitário e passa a ser uma rede de ciclos com velocidades, poderes e responsabilidades diferentes.

Um grafo também pode mentir

A troca de loop por grafo parece resolver tudo, mas só desloca o problema se todos os nós consumirem a mesma realidade fabricada.

Imagine uma empresa com métricas pareadas, auditorias e loops que ajustam outros loops. A auditoria compara o relatório operacional com o financeiro. O financeiro recebe dados do mesmo sistema operacional. O meta-loop ajusta limites usando dashboards construídos sobre esses relatórios.

Tudo concorda. Nada foi verificado.

O resultado é um circuito de confirmação mútua. A topologia ficou mais sofisticada, mas o sistema continua sem contato com o chão. Ele falha mais tarde, custa mais caro e exibe mais luzes verdes durante a queda.

Um grafo organiza a contestação. Ele não cria realidade por conta própria.

O que mantém o grafo no chão

O grafo precisa de âncoras: medidas que não dependem do consenso interno para existir. Dinheiro que entrou no banco. Testes que realmente executaram. Clientes que permaneceram. Um artefato que foi lido de volta. Uma contagem física que bateu ou não bateu.

Também precisa de regras congeladas. O loop que otimiza não pode reescrever toda restrição que o impede de vencer pelo atalho. É por isso que um conjunto de teste permanece escondido do treinamento e que certos gates não deveriam ser afrouxados pelo próprio agente avaliado.

E existe uma decisão que nenhuma arquitetura gera sozinha: o que significa "melhor" na raiz do sistema? Loops perseguem referências. Grafos revisam e coordenam referências. A escolha do que vale a pena melhorar, do que não pode ser sacrificado e de onde a autoridade do sistema termina continua sendo humana.

Onde essa tendência vai dar

Métricas pareadas, ciclos de auditoria e loops que revisam outros loops devem virar padrão, assim como o loop isolado virou o ponto de partida de quase todo sistema de melhoria. A arquitetura fica mais madura quando cada métrica tem uma contramétrica, cada referência tem um dono e cada medição pode ser auditada.

Mas grafos também vão falhar. Sem âncoras, eles falham de um jeito próprio: circular, consistente e plausível. Cada nó confirma outro, a topologia adia o colapso e o custo cresce enquanto os indicadores continuam verdes. Mais loops tornam a falha mais difícil de enxergar; não tornam o sistema verdadeiro.

O eixo durável passa por uma distinção diferente: grounded contra ungrounded. A disputa entre loop e grafo é secundária. A diferença está em saber se a máquina de melhoria continua encostando na realidade que afirma melhorar, se os watchers são independentes, se as regras congeladas resistem à pressão e se o sistema admite que seus alvos mais profundos foram escolhidos, não calculados.

O que EU realmente penso

Um loop pode ser honesto e otimizar a coisa errada. Um grafo inteiro pode ser internamente consistente e continuar errado. A forma ajuda, mas não substitui uma evidência que resista à narrativa do próprio sistema.

A topologia comprou sofisticação. Não comprou contato com a realidade.

Fechar um ciclo ainda importa. O próximo trabalho é decidir quais ciclos observam os outros, quais conflitos precisam de arbitragem, quais regras ficam fora do alcance do otimizador e qual prova externa encerra a conversa.

Sua missão para os próximos 7 dias

Escolha um loop importante da sua operação e desenhe o grafo ao redor dele:

• Risco: qual comportamento barato melhora a métrica sem melhorar o resultado?

• Conexões: qual contramétrica, dono da referência, árbitro e auditor faltam?

• Âncora: qual evidência fora do circuito prova que o sistema melhorou?

O entregável é um mapa simples: loop | risco | watcher | árbitro | âncora. Se todos os caminhos terminarem em outro dashboard, o grafo ainda está no ar.

Conteúdos recomendados

• Ensaio-base: From Loop Engineering to Graph Engineering?.

• Leitura complementar, DeepMind: Specification gaming, com exemplos de sistemas que cumprem a regra e traem a intenção.

• Leitura complementar, LangGraph: Workflows and agents, com padrões para implementar rotas, workers e ciclos de avaliação.

Forte abraço,

Equipe Olympus