Nosso agent de longa duração começou a inventar a própria história com total confiança

Duas horas dentro de uma tarefa longa, o agent nos disse, com total compostura, que já tinha enviado o relatório. Não tinha. Ele descreveu o arquivo que escreveu, nome errado, conteúdo errado. Ele se referiu a uma decisão “que combinamos antes” que ninguém tinha tomado. Nada disso soou como um glitch. Soou como um colega confiante recapitulando a manhã. A parte perturbadora não foi que ele estava errado. Foi que ele estava certo de si, e a coisa de que estava certo era o próprio passado.

Tínhamos batido no failure mode que termina todo agent de longa duração que não se planeja para ele.

Quando você comprime a memória de um agent para mantê-lo vivo, a primeira coisa que ele esquece é o que de fato fez.

Este post é sobre por que isso acontece com todo time rodando um agent por mais que uma única resposta, e a única distinção que conserta. A correção não é um context window maior. É decidir quais memórias têm permissão de ser sumarizadas e quais nunca podem ser tocadas.

Por que um agent de longa duração tem que esquecer algo

Comece com a restrição que todo mundo encontra, porque a falha cresce diretamente dela.

Um agent pensa dentro de um context window, um orçamento fixo de tokens que segura a conversa, os resultados de tools, as instruções, tudo o que ele pode atualmente “ver.” Esse orçamento é finito. Uma tarefa curta nunca o enche. Mas rode um agent por horas, dezenas de chamadas de tool, um vai-e-vem com uma pessoa, e alguns desvios, e o transcript cresce além do que a janela aguenta. Algo tem que ceder.

A resposta ingênua é a que toda primeira versão entrega: quando o histórico fica longo demais, sumarize a parte antiga e siga em frente. Pegue os primeiros milhares de tokens do transcript, comprima-os num parágrafo apertado, descarte os originais, e libere espaço. Parece obviamente correto. É como um humano toma notas. É como você descreveria uma reunião que assistiu. E por um tempo, funciona lindamente, o agent guarda a essência, perde o enchimento, e segue navegando.

Então ele sumariza a coisa errada, e você tem um agent certo de que enviou um relatório que nunca enviou.

A razão é sutil e vale ser encenada com cuidado, porque é o ponto inteiro.

A correção ingênua: sumarize o histórico antigo, siga em frente

Imagine o que a sumarização de fato faz a um transcript. Ela é, por design, lossy. Ela guarda o que parece importante e descarta o resto, e tem que decidir “importante” sem saber o que você vai perguntar depois. Essa é uma boa aposta para a maioria do conteúdo. Uma explicação longa de um conceito comprime limpo, a ideia sobrevive, o fraseado não importa. Uma digressão à qual você nunca voltou pode desaparecer e ninguém sente falta.

Mas nem todo o transcript é explicação. Parte dele é registro.

A linha “vou rascunhar o relatório e enviá-lo para revisão” é um plano. A linha “o relatório foi enviado à fila de revisão às 16:02, aqui está o recibo” é um fato sobre o que aconteceu no mundo. Para um sumarizador tentando economizar espaço, essas duas frases parecem quase idênticas, mesmas palavras, mesmo tópico, a poucos tokens de distância. Então quando ele comprime, alegremente mistura as duas. O plano e o fato derretem num parágrafo liso: trabalhou no relatório e cuidou da revisão. O relatório de fato foi enviado? O resumo não sabe mais. Ele guardou o formato da atividade e perdeu a verdade dela.

Agora o dano se acumula. O agent lê o próprio resumo como verdade fundamental, ele não tem outro registro, os originais sumiram, e age sobre ele. Ele “lembra” de ter enviado o relatório porque o resumo diz que foi cuidado. Peça o recibo a ele e ele não diz “não tenho certeza.” Ele gera um plausível, porque gerar texto plausível a partir de um prompt vago é exatamente para o que o modelo foi construído. O resumo era vago. O modelo preencheu a lacuna. E preenche com a mesma confiança que usa para tudo o mais.

Um resumo do que você fez não é um registro do que você fez.

Essa é a armadilha. Compressão lossy num transcript não só perde detalhe, ela silenciosamente converte fatos sobre ações em vibes sobre atividade, e um modelo que recebe uma vibe vai fabricar o detalhe faltante em vez de admitir a lacuna. O agent não mentiu. Ele leu uma nota borrada na própria caligrafia e confiou nela.

A distinção que conserta: um ledger não é um transcript

A ideia-chave é simples. Nem toda a memória de um agent é o mesmo tipo de coisa, e tratá-la como um stream indiferenciado é o que deixa a corrupção entrar.

Há dois tipos, e eles têm necessidades opostas.

Um tipo é raciocínio, a cadeia de pensamento do agent, suas explicações, sua exploração de uma ideia, a longa discussão que o levou a uma decisão. Esse tipo é seguro de comprimir. A conclusão é o que importa; o caminho pode ser sumarizado numa frase e nada importante se perde. Se o agent decidiu usar a abordagem B em vez da A, você precisa que ele escolheu B e por quê, não os quatro parágrafos de deliberação. Sumarize à vontade.

O outro tipo é registro, os eventos discretos e factuais do que o agent de fato fez no mundo. Um arquivo foi escrito, aqui. Uma mensagem foi enviada, para esta fila, neste horário. Uma tool retornou este resultado exato. Uma pessoa aprovou esta coisa específica. Esses não são opiniões ou explicações. São fatos com consequências, e um fato que você borrou é pior que um fato que você esqueceu, porque um fato borrado ainda responde perguntas, erradamente.

Então paramos de manter uma memória e começamos a manter duas.

O raciocínio vive no transcript de trabalho, e esse transcript é sumarizado livremente quando cresce, tudo bem, é para isso que ele serve. O registro vive em outro lugar inteiramente: um ledger append-only de ações, cada uma uma entrada estruturada que o agent escreve no instante em que faz algo real. Escreveu o arquivo X. Enviou a mensagem Y para a fila Z no horário T. A tool retornou o resultado R. Esse ledger nunca é sumarizado. Ele nunca é comprimido para abrir espaço. Quando a memória de trabalho enche e o raciocínio antigo é espremido num parágrafo, o ledger fica ao lado dele, intocado, segurando a verdade literal de cada ação que o agent tomou.

Agora pergunte ao agent se ele enviou o relatório. Ele não consulta um parágrafo vago e adivinha. Ele checa o ledger. Ou há uma entrada que diz que o relatório foi enviado, com o horário e o destino, ou não há. Se não há, a resposta honesta é “não, ainda não,” e o agent pode dizê-la, porque a ausência de um registro é em si um fato.

A versão ingênua pede a uma única memória para ser tanto um espaço de pensamento quanto um sistema de registro. Esses trabalhos brigam um com o outro. Um espaço de pensamento quer ser fluido e compressível; um sistema de registro tem que ser rígido e exato. Forçá-los num único store significa que toda vez que você comprime para proteger o primeiro, você corrompe o segundo.

Por que “simplesmente não sumarize” não é a resposta

Há um atalho tentador aqui, e vale matá-lo explicitamente, porque é o movimento que a maioria das pessoas busca em segundo lugar.

Se sumarizar o histórico é o que quebra o registro, por que sumarizar de jeito nenhum? Mantenha o transcript completo para sempre. Compre uma janela maior. Nunca comprima nada. Problema resolvido.

Não é, por duas razões que aparecem rápido em produção. A primeira é mecânica: janelas são finitas não importa quão grandes, e um agent genuinamente de longa duração, um que trabalha por um dia, uma semana, indefinidamente, vai ultrapassar qualquer orçamento fixo. “Só faça maior” te compra horas e te custa a semana. A segunda é pior, e é sobre atenção em vez de espaço. Um agent raciocinando sobre um transcript gigante e indiferenciado fica pior, não melhor. O sinal de que ele precisa está enterrado em milhares de tokens de deliberação antiga com a qual ele não se importa mais. Fatos relevantes ficam diluídos. O modelo gasta a atenção dele relendo exploração que já resolveu, e o registro importante, as três ações que de fato importam agora, se afoga no ruído de tudo o que ele já pensou.

Então você não pode manter tudo, e não pode sumarizar tudo. A resposta nunca foi sobre quanto comprimir. Foi sobre o que comprimir. Sumarize o raciocínio, porque o valor do raciocínio sobrevive à compressão. Proteja o registro, porque o valor do registro é destruído por ela. A mesma operação que é saudável para um tipo de memória é veneno para o outro, que é por que a única correção durável é parar de tratá-los como um único tipo.

O que isso muda sobre confiar num agent de longa duração

Uma vez que a divisão está no lugar, uma propriedade emerge que você não consegue de nenhum outro jeito: o agent pode ser honesto sobre o próprio passado, mesmo quando a memória dele da conversa foi comprimida uma dúzia de vezes.

Essa honestidade é o jogo inteiro para qualquer agent que roda operações reais. Um sistema que faz trabalho ao longo de horas e dias está constantemente sendo perguntado, implicitamente, você fez a coisa?, e o custo de uma resposta errada não é constrangimento, é uma ação duplicada, um passo pulado, um relatório enviado duas vezes ou nunca. Um agent que adivinha sobre a própria história é um agent que você tem que checar duas vezes, e um agent que você tem que checar duas vezes é um a quem você não delegou de fato. O ledger é o que te deixa parar de checar. Quando o agent diz que enviou o relatório, ele está lendo um recibo, não relembrando um sentimento.

Há uma disciplina aqui que sobrevive muito a qualquer modelo único.

Memória que você pode comprimir e memória em que você pode confiar não são o mesmo store, e o dia em que você as funde é o dia em que seu agent começa a inventar coisas.

Isso é verdade para software, e é silenciosamente verdade para pessoas também, a razão pela qual operações sérias mantêm um logbook que o recap não pode sobrescrever é a mesma razão pela qual demos um ao agent.

A virada: a parte que você não pode sumarizar

O ledger e o transcript são palavras novas para uma coisa antiga e humana.

Pense no colega em quem você confia com algo que importa ao longo de um período longo, um lançamento, uma migração, uma coisa que leva semanas. Nunca é o com a memória mais impressionante. É o que, quando você pergunta “a coisa foi feita?”, não performa uma resposta. Ele checa. Ele vai olhar o registro, e te diz o que de fato está lá, mesmo quando o que está lá é “ainda não.” A confiança não está na memória dele ser perfeita. Está na recusa dele de preencher uma lacuna com um palpite confiante, de manter a linha entre acho que fiz aquilo e aqui está o recibo nítida, especialmente quando borrá-la seria mais fácil e soaria igualmente bem.

Essa linha é a coisa que estávamos de fato construindo. Um agent que roda por um dia vai esquecer a textura da maior parte daquele dia, e deveria, é assim que ele se mantém rápido e claro. O que ele nunca deve esquecer, e nunca deve borrar, é o ledger do que ele de fato fez ao mundo. Um sistema que mantém esses dois tipos de memória nos seus lugares certos não é impressionante porque a memória dele é grande. Ele é confiável porque, perguntado sobre o próprio passado, ele prefere checar e dizer “não” a adivinhar e dizer “sim.”

Quando você comprime a memória de um agent para mantê-lo vivo, a primeira coisa que ele esquece é o que de fato fez, a menos que você decida, de propósito, que o registro do que ele fez é a única coisa que a compressão nunca tem permissão de tocar.

---

É isso que estamos construindo na Apollo Space: agents a quem você pode entregar um trabalho longo e real e ir embora, porque a única coisa que eles nunca farão é inventar um passado para cobrir uma lacuna. Se você já se pegou rechecando trabalho que supostamente delegou, você já sabe por que um agent que pode honestamente dizer “não, ainda não” vale mais que um que sempre soa certo de si.