Entre 8 e 9 de junho, três pessoas que raramente escrevem a mesma redação escreveram a mesma redação. [Addy Osmani](https://x.com/addyosmani/status/2064127981161959567), diretor de IA do Google Cloud, publicou "Loop Engineering", uma taxonomia dos sistemas que solicitam agentes de codificação para que você não precise fazer isso. [Matt Van Horn](https://x.com/mvanhorn/status/2063865685558903149) publicou "WTF Is a Loop?", uma pesquisa no Reddit, X, YouTube e Hacker News que rastreou a ideia desde o artigo ReAct de 2022 até os loops de orquestração que as pessoas executam hoje. E [Lance Martin](https://x.com/RLanceMartin/status/2064397389189071163), membro da equipe técnica da Anthropic, publicou "Designing loops with Fable 5", dois padrões para obter o máximo dos modelos de fronteira projetando loops em vez de solicitar diretamente.

Todos os três convergem para a mesma mudança: a solicitação está dando lugar ao design de loops que solicitam os agentes para você. E todos os três nomeiam o mesmo componente como aquele que mais importa. Osmani lista cinco blocos de construção, depois acrescenta um sexto e dá-lhe a frase mais forte do seu artigo: “O ficheiro estatal é a espinha dorsal de tudo”. Van Horn argumenta que a geração atual de loops é genuinamente nova por uma razão estrutural: "a durabilidade tornou-se explícita, com estado apoiado por git e recuperação de falhas". Martin enquadra a memória como "um loop externo que se estende por sessões".

O diagnóstico agora é consenso. O estado externo durável é a parte que suporta a carga dos agentes autônomos. O que me surpreendeu foi o que aconteceu a seguir. Todos os três entregaram o trabalho para um arquivo de texto.

## O que é um loop, resumidamente

A definição de Van Horn é a mais clara: um loop é cron mais um tomador de decisão no corpo. Um cron job executa um script fixo. Um loop executa um modelo que analisa o estado atual, decide o que fazer, faz, verifica se funcionou e decide se deve continuar. Empilhe-os, deixe um loop despachar outros, e você terá o que Boris Cherny quis dizer quando disse que seu trabalho é escrever loops.

O modelo dentro desse loop esquece tudo entre as execuções por design. As janelas de contexto terminam. As sessões são reiniciadas. Portanto, algo no sistema não deve ser esquecido. Esse algo é o que o loop lê para decidir o que fazer a seguir e escreve para registrar o que aconteceu. É a coluna vertebral, e Osmani tem razão em chamá-la assim.

## O punt do substrato

Aqui está o inventário completo de candidatos à coluna vertebral em todas as três postagens: um arquivo markdown, uma placa linear, arquivos de estado comprometidos com o git e um sistema de arquivos montado compartilhado entre sessões. Osmani oferece os dois primeiros. Van Horn documenta o terceiro, que é o que Gas Town, de Steve Yegge, usa para coordenar de vinte a trinta instâncias de Claude. Martin usa o quarto, o recurso de memória dos Claude Managed Agents.

Tudo isso resolve a persistência. Os bytes sobrevivem a uma reinicialização. Nenhum deles resolve a integridade. Faça a qualquer um desses substratos a pergunta que um loop realmente precisa de resposta: dessas duas notas contraditórias, qual é a verdadeira, quem a escreveu, quando e foi verificada alguma vez? Um arquivo em prosa mantém as duas notas lado a lado e deixa a reconciliação para o modelo que ler o arquivo em seguida. O Git preserva todas as versões históricas da ambigüidade sem resolvê-la. Uma montagem compartilhada adiciona as últimas vitórias de gravação no topo.

Persistência e integridade são propriedades diferentes. O discurso absorveu plenamente o primeiro e ainda não percebeu o segundo.

## Realizamos esse experimento antes

Os aplicativos armazenaram seu estado em arquivos simples por décadas. Três forças encerraram aquela era: escritores simultâneos corromperam arquivos, contradições acumuladas não tinham mecanismo de resolução e responder perguntas significava analisar tudo. Os bancos de dados venceram porque tornaram a integridade uma propriedade da camada de armazenamento, em vez de uma disciplina esperada de cada programa que tocou nos dados.

Cada uma dessas forças já é visível dentro dos três postes.

A simultaneidade chega no momento em que os loops supervisionam os loops, que é exatamente o estágio que Van Horn diz que estamos entrando. Dois loops escrevendo um arquivo de estado são a mesma falha que dois engenheiros comprometendo-se com as mesmas linhas sem falar. Worktrees resolvem isso para código. Nada no conjunto de ferramentas atual resolve isso para [estado compartilhado](/posts/when-agents-share-state-everything-breaks).

A contradição está documentada nos resultados do benchmark de Martin. Em uma tarefa de aprendizado contínuo, o Soneto 4.6 deixou para trás um armazenamento de memória que ele descreve como uma lista de notas de falhas e suposições em aberto, incluindo entradas como "talvez prc em vez de prc_usd?" Os palpites se acumulam. Nada marca alguém resolvido. A próxima sessão herda a pilha.

As consultas são a piada do próprio Van Horn. Ele argumenta que a parte dispendiosa da codificação de agentes é agora a gestão do ciclo: condições de paragem, ausência de detecção de progresso e limites máximos orçamentais. Cada uma delas requer a comparação da execução atual com as anteriores. Em um substrato de prosa, isso significa reler e analisar novamente um arquivo crescente a cada tick, que é um imposto simbólico que aumenta com a idade do loop.

## O que comandar um enxame me ensinou

Eu administro um enxame de agentes nomeados em minha própria máquina: um para inteligência do cliente, um para conteúdo, um para divulgação, outros para operações. Na configuração inicial, cada um mantinha anotações em seus próprios arquivos. Esses arquivos foram perdidos. A mesma pessoa apareceu sob três nomes. Um fato corrigido em um arquivo sobreviveu sem correção em outros dois, e nenhum registro mostrou qual versão era atual ou de onde veio.

O enxame agora compartilha [uma loja estruturada](/posts/from-memory-to-nervous-system), e esta postagem é em si um recibo. A pesquisa por trás disso foi feita pelo meu agente de inteligência do cliente, que buscou todas as três postagens X, armazenou cada uma como um registro digitado com números de engajamento e procedência, escreveu as descobertas competitivas em uma análise estruturada e arquivou tarefas de acompanhamento para dois outros agentes por meio da loja compartilhada. Quando fiz uma pergunta de acompanhamento uma hora depois, a comparação foi anexada ao mesmo registro de análise com sua própria trilha de proveniência, e não espalhada em um novo arquivo. Nenhum agente re-derivou o que outro já havia estabelecido.

## A maturidade da memória é uma propriedade do substrato

Os dados mais nítidos em qualquer um dos três posts estão no de Martin. Ele descreve cinco estágios de uso da memória: um agente falha, investiga o porquê, verifica o que encontrou, destila a resposta em uma regra e consulta essa regra na próxima vez. Um agente que completa todos os cinco transforma as falhas em regras verificadas e reutilizáveis. Um agente que para cedo deixa uma pilha de suposições.

Seus resultados, todos no mesmo sistema de arquivos montado: o Sonnet 4.6 para no estágio um, registrando falhas sem investigá-las. O Opus 4.7 atinge o estágio de verificação, mas verifica apenas cerca de 17% de suas reivindicações no período médio. Fable 5 completa a progressão e verifica até 73 por cento.

Mesmo sistema de arquivos, qualidade de memória radicalmente diferente. A diferença reside inteiramente na disciplina do modelo, porque o sistema de arquivos não garante nada: cada estágio é um comportamento que o modelo deve escolher executar. Um armazenamento estruturado transforma esses comportamentos em operações de dados. Uma falha é uma observação armazenada. A investigação está recuperando os registros relacionados. A verificação é uma correção com procedência anexada. A destilação está escrevendo uma regra digitada. Consultoria é uma consulta limitada. Quando o substrato carrega a progressão, qualquer modelo consegue completá-la.

## O que exigir de uma camada de estado de loop

Ferramenta declarada de forma agnóstica, a espinha dorsal de um loop deve fornecer seis coisas: registros digitados em vez de blobs em prosa, proveniência em cada campo, correções que calculam a verdade atual em vez de versões acumuladas, gravações simultâneas que não podem entrar em conflito, recuperação que retorna apenas o que o tick atual precisa e acesso de qualquer equipamento em vez da pilha de um fornecedor.

Para ser justo com o arquivo de texto: para um loop em um repositório, [markdown é genuinamente bom](/posts/the-markdown-memory-ceiling). É legível, diferenciável e gratuito. A função de forçamento é o loop número dois, a primeira vez que dois processos se preocupam com o mesmo fato e nenhum deles pode confiar no que o outro escreveu.

## Arquivos lembram, sistemas de registro sabem

Van Horn termina seu artigo argumentando que o circuito é o encanamento e o ativo durável é a biblioteca de habilidades que ele chama. Meio certo, eu acho. As habilidades são a memória processual, o como do trabalho repetido. Abaixo deles está a memória factual, o que é verdade agora, do qual depende toda invocação de habilidade. Ambos são compostos, mas apenas se a camada factual puder ser confiável após mil gravações autônomas.

Eu criei o [Neotoma](https://github.com/markmhendrickson/neotoma) porque precisava dessa camada para meu próprio enxame: observações digitadas, por proveniência de campo, correções que resolvessem a verdade atual e acesso compartilhado para cada agente que eu executo. O discurso do loop passou apenas uma semana descrevendo a vaga que preenche, sem nomear nada que a preencha.

Osmani encerra seu ensaio com o conselho de construir o ciclo como quem pretende continuar engenheiro. A camada de estado é onde essa intenção se torna testável. Lembre-se dos arquivos. Um sistema de registro sabe.