Seu agent não esqueceu. Ele mentiu sobre lembrar.

No turno vinte de uma conversa longa, um agent diz que a renovação do cliente é em março. Você rola para cima. O cliente nunca mencionou março. Ele disse que a renovação era “depois da auditoria”, e a data da auditoria era justamente o que estava em discussão. O agent não tirou março do nada, ele o tirou da forma da conversa, do lugar onde uma data pertencia, da lacuna onde o fato real costumava estar. Ele soa exatamente tão seguro sobre o março inventado quanto sobre tudo que de fato sabia.

Aqui está a parte que deveria te incomodar: nada na transcrição parece errado. A tarefa avançou. O tom ficou estável. O agent estava ajudando até o momento em que silenciosamente inventou algo.

Quando um agent compacta seu context, a continuidade-de-tarefa sobrevive mas a continuidade-de-fato morre, e ele preenche a lacuna com uma invenção confiante.

Este post é sobre essa falha exata: por que ela acontece, por que os consertos óbvios a pioram, e a única mudança estrutural que impede um agent de inventar um fato que ele já soube.

A versão ingênua: um context longo, e torcida

O jeito mais simples de dar memória a um agent é não dar memória nenhuma, só uma context window bem longa e o otimismo de que tudo importante fica dentro dela.

Para uma conversa curta, isso é perfeito. Todo fato que o usuário declarou ainda está na transcrição, palavra por palavra, e o modelo consegue lê-lo de volta literalmente. Pergunte “quando é a renovação?” e ele rola para cima e acha a frase literal. Não há sistema de memória para dar errado porque não há sistema de memória. O context é a memória.

Aí a conversa fica longa. Uma de verdade, uma sessão de trabalho que roda por uma hora, ou uma thread que um time retoma ao longo de uma semana. A transcrição cresce além do que a janela consegue segurar, e agora o sistema tem uma decisão a tomar a cada turno: o que fica, e o que sai.

Esse é o momento em que o problema começa, e quase ninguém projeta para ele, porque na demo a conversa nunca foi longa o suficiente para chegar lá.

A resposta padrão é compactação. Quando o context enche, resuma os turnos antigos em algo mais curto e siga em frente. Soa responsável, você está salvando a essência, jogando fora o enchimento. E funciona bem o suficiente para você lançar e se sentir bem, porque o agent continua fazendo a tarefa. O que você não vai ver, até um usuário pegar, é qual essência ele manteve.

O que a compactação de fato joga fora

Um resumo é uma compressão com perdas, e a coisa que ele é pior em preservar é a coisa de que você mais precisa.

Acompanhe para o que um sumarizador otimiza. Ele está tentando manter a conversa coerente, preservar o fio condutor para que o próximo turno faça sentido. Então ele mantém a narrativa: estamos ajudando este usuário a renovar um contrato, discutimos o cronograma, estamos definindo próximos passos. Esse fio condutor é o que continuidade parece, e o resumo o protege bem. O agent no turno quarenta ainda sabe o que está fazendo e por quê.

O que o sumarizador não está otimizando é o valor exato de um único campo declarado uma vez no turno seis. “A renovação é depois da auditoria.” Essa frase não carrega peso narrativo, é um fato, não um ponto de enredo, então um compressor afinado para coerência a trata como detalhe e a arredonda. A história sobrevive. O dado não.

A compactação mantém o enredo e perde os fatos, e o agent não consegue dizer qual deles está faltando.

Agora o agent está na pior posição possível. Ele tem um senso forte da tarefa e um buraco onde um valor específico costumava estar, e não tem nenhum marcador dizendo que o buraco existe. De dentro, um fato lembrado e um confiantemente-reconstruído parecem idênticos. Então quando o próximo turno precisa de uma data de renovação, o modelo faz o que modelos fazem: gera o token mais plausível para aquele slot. Uma data que encaixa na forma da conversa. Março. Declarado com a mesma calma certeza de tudo que ele genuinamente sabe.

Essa é a mentira do título. O agent não esqueceu, esquecer ao menos deixaria um vazio. Ele perdeu o fato e manteve a confiança, e confiança sem fato por trás é invenção vestindo a voz da memória. A continuidade-de-tarefa sobreviveu; a continuidade-de-fato morreu, e o agent preencheu a lacuna com uma invenção confiante.

O conserto ingênuo: é só resumir melhor

O primeiro instinto, uma vez que você vê isso, é consertar o resumo. Torne o prompt de compactação mais inteligente. Diga a ele para preservar datas, nomes, números, decisões. Adicione uma linha que diz não jogue fora fatos específicos.

Isso ajuda um pouco, e esse pouco é uma armadilha, porque torna a falha mais rara sem torná-la mais rara de nenhum jeito em que você possa confiar. Um sumarizador melhor mantém mais fatos com mais frequência. Ele ainda os mantém por julgamento, a cada compactação, sob pressão de ficar curto, o que significa que ele ainda está decidindo, turno após turno, quais fatos valem os tokens. Acerte cem dessas decisões e a centésima-primeira joga fora a que importava, e você volta a um março confiante sem nenhum aviso de que aconteceu.

Essa é a falha reafirmada: quando o agent compacta seu context, a continuidade-de-tarefa sobrevive mas a continuidade-de-fato morre, e ele preenche a lacuna com uma invenção confiante. Tornar o sumarizador mais inteligente muda quão frequentemente isso acontece, não se pode acontecer.

O problema mais profundo é que você pediu a um mecanismo para fazer dois trabalhos que puxam em direções opostas. Um resumo quer ser curto e fluido. Um fato quer ser exato e permanente. Comprimir a conversa e preservar seus fatos não são a mesma tarefa, e grampeá-las juntas significa que cada fato que você mantém está competindo por espaço contra a coerência, e perdendo um pouco a cada vez que a janela aperta.

Você não consegue sair de um conflito estrutural via prompt. Enquanto o único lugar onde um fato vive for dentro de uma coisa projetada para ser comprimida, o fato está com os dias contados.

A nossa: separe o que precisa comprimir do que não pode

A ideia-chave é simples. Pare de armazenar fatos na conversa. Dê a eles uma casa que a conversa não consiga comprimir.

Uma transcrição de trabalho e um fato durável são tipos diferentes de coisa e merecem armazenamento diferente. A transcrição tem permissão de ter perdas, tudo bem, ela deveria comprimir, porque o que você precisa dela é o fio condutor. O fato não tem permissão de ter perdas. Quando um usuário declara algo que é verdadeiro além deste único turno, uma renovação é depois da auditoria, o orçamento é fixo, o nome do contato se soletra assim, essa declaração é puxada para fora do fluxo e escrita num store que nenhum sumarizador jamais toca.

Então agora há duas camadas, e elas falham diferente de propósito. A camada de conversa compacta livremente; perca a conversa fiada, ninguém liga. A camada de fato é majoritariamente-append e palavra-por-palavra; um valor declarado entra como o usuário disse e sai do mesmo jeito. Quando um turno posterior precisa da data de renovação, o agent não enfia a mão num resumo desbotado e a reconstrói. Ele recupera o fato fixado, exatamente como declarado, com o turno de onde veio anexado.

Esse é o conserto estrutural para a falha com que começamos. Quando um agent compacta seu context agora, a continuidade-de-tarefa ainda sobrevive, mas a continuidade-de-fato sobrevive também, porque os fatos nunca estiveram na coisa que compactou. Não sobra lacuna nenhuma para preencher com uma invenção confiante.

Essa é a diferença entre recall e reconstrução. Reconstrução adivinha o valor mais plausível para um slot. Recuperação retorna o único valor verdadeiro que foi armazenado. Eles parecem iguais numa conversa curta, onde nada ainda foi comprimido. Eles divergem completamente no momento em que a janela aperta, e as conversas longas e reais são exatamente aquelas onde a janela sempre aperta.

Um fato que você consegue recuperar palavra por palavra não pode ser silenciosamente reinventado. Um fato que você tem que reconstruir sempre pode.

Há uma segunda vitória, mais silenciosa, e é a que um líder de time mais sente. Quando um fato é fixado, ele carrega sua origem, o turno em que foi declarado, as palavras exatas. Isso significa que o agent consegue fazer a coisa que o agent do março-confiante nunca conseguiu: ele consegue citar. “A renovação é depois da auditoria, conforme o turno seis” é checável. “A renovação é em março” é uma afirmação sem lugar para olhar. No momento em que um fato tem uma fonte, um fato inventado não tem onde se esconder, porque invenção é precisamente o fato sem fonte por trás.

Por que isso é uma disciplina, não uma feature

É tentador ler isso como um truque, “adicione um fact store”, e parar. Isso perde o que faz funcionar.

A parte difícil nunca foi o armazenamento. Um lugar para pôr fatos é fácil. A parte difícil é o julgamento nas bordas: decidir o que conta como um fato durável que vale fixar versus detalhe passageiro que deveria comprimir, e decidir o que fazer quando um turno posterior contradiz um anterior. Um usuário diz que a renovação é depois da auditoria no turno seis e “na verdade, faça no Q2” no turno trinta. Um store ingênuo agora guarda dois fatos que discordam, e um agent que recupera ambos não está melhor que um que não lembrou de nenhum.

Então o store não pode ser uma gaveta de bagunça. Ele precisa de um caminho de atualização, uma nova declaração substitui a antiga, a antiga é mantida com seu timestamp para que o histórico seja auditável, e uma recuperação retorna a verdade atual, não a pilha inteira. Essa é a mesma disciplina que uma pessoa cuidadosa mantém na própria cabeça: não só lembrar o que foi dito, mas rastrear quando mudou e qual versão está viva agora. Memória que não pode ser atualizada não é memória. É uma transcrição com passos extras.

Esse é o movimento que transforma um fact store de uma feature em algo a que você pode confiar uma operação real. Toda afirmação tem uma fonte que você pode checar, um timestamp que você pode ordenar, e um valor atual em que você pode confiar, e no momento em que qualquer um desses três é verdadeiro, a invenção confiante não tem mais onde viver.

A virada: a coisa que você não consegue comprimir é julgamento

O que é um fact store, na verdade, senão algo verdadeiro sobre pessoas muito antes de jamais ter sido verdadeiro sobre agents?

O colega em quem você confia a coisa bagunçada de várias semanas não é o de melhor memória. É o que sabe a diferença entre acho que sim e eu chequei, que, quando não tem o fato, diz isso claramente em vez de produzir um chute confiante que soa como memória. Essa honestidade sobre a borda do próprio conhecimento é a coisa inteira. É o que separa um colega a quem você pode entregar um problema real de um que você tem que conferir em cada detalhe.

Um agent que fixa seus fatos e os cita é construído para ter essa honestidade como propriedade da estrutura, não do humor. Ele não consegue inventar suavemente uma data de renovação, porque a data ou tem fonte ou não tem, e um fato sem fonte é um fato que ele tem que admitir que não tem. Essa admissão, eu não tenho isso de verdade, eis o que eu tenho, vale mais que mil respostas fluentes, porque é a única coisa que torna toda outra resposta confiável.

Você consegue instalar um fact store. Você não consegue instalar o julgamento de saber o que é um fato, quando ele mudou, e quando admitir que você simplesmente não sabe. Essa parte, a linha entre saber e adivinhar, mantida firme mesmo quando adivinhar soaria melhor, é o trabalho, e é o trabalho quer quem o faça seja uma pessoa ou um sistema construído para se comportar como o melhor delas.

---

É isso que estamos construindo na Apollo Space, agents que prefeririam te dizer “eu não tenho isso” a te entregar um março confiante que nunca esteve lá. Se você já pegou um sistema declarando um fato inventado na mesma voz calma que usa para os reais, você já sabe por que a parte que não pode ser comprimida é a parte que mais importa.