Arquitetura de memória de agentes da Anthropic: quatro camadas, dreaming e uma falha com 413 arquivos (nov. 2026)

O que a Anthropic publicou?

Em 6 de novembro de 2026, a Anthropic publicou The components of agent memory, um post de pesquisa de Lance Martin sobre como o Claude leva conhecimento de uma sessão para a próxima. Não é o anúncio de um produto. Descreve uma pilha de memória que já roda dentro do Claude Code, e gasta mais ou menos o mesmo espaço com o que dá errado e com o design.

O post traça uma fronteira logo no começo. Três coisas costumam ser chamadas de memória, mas não são: os pesos com que um modelo foi treinado, o aprendizado em contexto que acontece dentro de uma conversa e a compactação, o resumidor que mantém uma sessão longa dentro da janela de contexto. Memória de agente, na definição da Anthropic, é o conhecimento que o agente decide anotar durante o trabalho real e relê depois, sozinho, em outra sessão.

Uma nota é uma aposta de que algo vai importar de novo, feita antes de você saber o que vem depois.

Por que anotar tudo deixou o Claude pior em Pokemon?

A Anthropic comparou duas execuções de Pokemon Red com cerca de 10.000 passos.

O Sonnet 3.7 registrava quase tudo. Um arquivo por batalha contra um Pokemon selvagem, um por item coletado, um por conversa com um personagem não jogador. No passo 10.000, tinha 413 arquivos de memória espalhados por 225 pastas e uma insígnia de ginásio.

O Fable 5 fez o contrário. Nove arquivos em duas pastas, mais um único arquivo na raiz chamado global.md. Quatro insígnias. O Opus 5.5 veio depois e manteve uma pasta pequena com seu objetivo e os próximos passos, reescreveu notas no próprio lugar e terminou o jogo.

A execução com 413 arquivos não ficou sem espaço. Por volta do passo 10.000, abriu uma quarta pasta de memória na raiz e, nos 17 passos seguintes, criou seis arquivos, apagou outros nove e não fez nada no jogo. O agente estava reorganizando notas sobre um mundo que já tinha seguido adiante.

Notas sobre um ambiente vivo envelhecem enquanto você as escreve, e toda nota desatualizada disputa atenção com o que está na tela agora. Memória não é um ativo gratuito.

Como uma nota errada quebrou três execuções seguidas?

O desperdício é a falha leve. A grave é uma nota simplesmente errada, porque ela sobrevive à sessão que a escreveu.

Em Pokemon Red, o Mt. Moon tem penhascos de mão única. O Claude registrou que o Centro Pokémon ficava a leste da caverna. Depois de sair, tratou a nota como resolvida, decidiu que a caverna estava terminada, marcou-a como concluída e saltou de um penhasco que devolve você à entrada.

A ferramenta de navegação não detectava o desnível, então ele concluiu que tinha ido longe demais para oeste e anotou essa conclusão com mais confiança do que antes. As sessões seguintes herdaram os dois erros. A Anthropic relata três execuções distintas que passaram pelo mesmo penhasco. Uma terminou com o Claude escrevendo que ia parar em vez de continuar em loop, seguindo para Pewter City e nunca chegando a Cerulean City. A execução cuja memória tinha sido corrigida voltou direto para dentro da caverna e chegou lá.

Uma única linha ruim, e toda sessão posterior parte dela sem verificar.

O que separa um fato que vale guardar do ruído?

A Anthropic divide o mundo entre coisas que mudam e coisas que se mantêm, um teste mais útil do que "isto é importante".

Fatos efêmeros mudam o tempo todo: em qual tile está um NPC, quantas poções restam, como a página estava um instante atrás. Relê-los é barato. Guardá-los também. E a cópia guardada já está errada no momento em que é escrita. Recuperar uma coordenada desatualizada de um armazenamento de memória é pior do que olhar a tela de novo.

Regras latentes não aparecem num único quadro. Nunca pule o penhasco à direita depois de sair desta caverna. Adquira o lock antes de uma chamada concorrente à API. Este tipo de erro quer dizer que falta uma variável de ambiente. Elas vêm de tentativas repetidas ao longo de várias sessões, inclusive das que falharam.

Só a segunda categoria pertence à memória de longo prazo. A primeira vale a pena observar de novo.

Você deve escrever regras que limitem o que o modelo pode registrar?

Muitas equipes tentam. Um prompt dizendo "nunca registre coordenadas" ou "registre apenas falhas" parece controle de qualidade. O CL-Bench, o benchmark da Anthropic para memória de horizonte longo, mostra que isso sai pela culatra nos modelos fortes.

Com a instrução de registrar apenas falhas, o Opus 5 e o Opus 4.7 perderam boa parte do ganho que a memória vinha lhes dando. Seguiram a regra e pararam de anotar o que precisariam.

A outra direção é mais interessante. Pedir ao Sonnet 4.6 que lesse a própria memória primeiro e depois testasse as teorias que encontrou quase dobrou sua pontuação no benchmark. O Sonnet 5 leu a memória antes de responder em 9 de cada 10 vezes, sem instrução nenhuma. E só dizer ao Claude que existia uma pasta de memória já elevou o desempenho do Opus 4.7 e do Opus 5.

Modelos mais fortes julgam melhor o que merece ser guardado do que uma lista feita à mão de tópicos permitidos. O que a arquitetura lhes deve é um lugar seguro para escrever, uma forma de corrigir depois e uma declaração clara de para que serve a memória.

Quais são as quatro camadas?

A pilha vai de um log completo na base a um índice enxuto no topo. Não é um banco de dados vetorial com um prompt colado por cima.

Transcrições. O registro completo: turnos de conversa, chamadas de ferramenta com seus argumentos, resultados, retorno do ambiente. Sem perdas, pesquisável por palavra-chave e por texto completo, e nunca perdido num resumo. Quando tudo o que foi construído em cima se revela errado, é a este arquivo que você volta.

Notas de memória. O que o agente escreve durante uma execução quando algo chama atenção. Notas curtas em Markdown sobre as lições de uma tarefa, muitas vezes com uma tag e uma data.

Representações de memória. Wikis e estruturas semelhantes. Em vez de deixar as notas se acumularem, uma passagem offline funde duplicatas, abstrai o que não para de se repetir e interliga páginas num mapa que o agente consegue navegar.

Contexto injetado. Algumas linhas carregadas no início da sessão. Diz em quais áreas o agente tem conhecimento e onde está o detalhe, e não carrega quase nenhum detalhe em si.

A Anthropic mediu quanto vale a terceira camada no Stainless, uma base de código real com cerca de 350.000 arquivos, aproximadamente 420 milhões de tokens, avaliada em 25 perguntas. O dreaming construiu a wiki em 128 sessões. Escalar de duas para 128 sessões levou a fração de critérios atendidos na avaliação de 13% para 48%. Só a busca pontuou 53%. Busca com wiki subiu de 54% para 61% conforme a wiki crescia, e economizou cerca de 20.000 tokens por pergunta.

A wiki não venceu sozinha. Ajudou quando usada junto com a busca, e numa tarefa em que cada resposta estava num único documento, o post diz que a wiki não mostrou ganho claro. Em outra tarefa, a wiki ficou maior que os documentos de origem que deveria comprimir.

O que é dreaming?

Dreaming é computação gasta enquanto nada está pedindo nada ao agente. O nome vem da pesquisa sobre sono: o hipocampo reproduz a experiência do dia durante o sono de ondas lentas e o sono REM, corta o ruído e grava o que sobrevive no armazenamento de longo prazo.

Num agente, a passagem offline lê logs e notas juntos e procura contradições. Pode reescrever uma nota com base na transcrição, promover algo que continua importando, fundir duas páginas que descrevem a mesma coisa ou achar links que apontam para páginas que ninguém criou.

A correção do Mt. Moon é o exemplo mais claro. O dreaming comparou a nota com o log de movimento, viu que o caminho registrado ia para leste e caía, e substituiu a nota por uma instrução para voltar para dentro da caverna e seguir ao norte. A execução corrigida chegou a Cerulean City e as não corrigidas não.

Ele também faz reparo estrutural. No teste de análise de contratos da Anthropic, a primeira passagem produziu um resumo que cobria 41 dos 57 fatos que importavam, 72%. Vários agentes tinham sobrescrito uma tabela compartilhada e parafraseado os termos de modo vago. A correção foi de processo: uma página por contrato, um agente por contrato, termos citados palavra por palavra. Esse resumo atendeu a 100% dos critérios. Uma passagem de dreaming posterior encontrou nove links que apontavam para uma página que não existia, corrigiu o destino desses links e acrescentou três páginas novas, incluindo um índice.

A saída do dreaming não está disponível para a sessão que roda agora, e a computação não é gratuita.

Como o Claude Code mantém a camada injetada pequena?

O Claude Code carrega apenas as primeiras 200 linhas ou 25 KB do MEMORY.md no início de uma sessão. O resto do diretório de memória continua no disco.

Esse cabeçalho é o índice injetado. Diz ao modelo em que áreas ele tem conhecimento e onde ficam os arquivos. Quando uma tarefa precisa de uma regra específica, o agente busca na camada de baixo ou lê o arquivo na hora.

A Anthropic dá duas razões. A memória injetada é cobrada como contexto a cada turno, e um arquivo de instruções mais longo reduz mensuravelmente o quanto o modelo segue esse arquivo. Um bloco de memória longo que por acaso contém a resposta pode valer menos do que um índice curto que aponta para ela de modo confiável.

Onde isso fica difícil em produção?

Três trade-offs, todos sobre computação.

Quando escrever. Capturar um evento notável na hora preserva o detalhe, mas o ato de escrever disputa contexto com a tarefa. Escrever offline mantém a sessão limpa e não entrega nada até mais tarde.

Como manter a memória atualizada. A memória deriva, porque as notas sobrevivem às condições que as tornaram verdadeiras. O dreaming pode corrigi-las, mas verificar o tempo todo custa tanto quanto economiza, então você precisa de uma cadência e de uma lista de alvos: memórias com probabilidade de mudar e memórias que já foram lidas uma vez e contraditas.

Quanta representação construir. A busca em transcrições é um piso sólido e não precisa de manutenção. Wikis ajudam quando combinadas com busca, mas precisam de computação para continuar precisas, e uma wiki sem manutenção vira mais uma camada de erros confiantes.

O que dá para tirar disso?

Os números da Anthropic vêm das tarefas da Anthropic. Algumas escolhas de design se transferem de qualquer jeito, e nós as registraríamos como conselho de design, não como resultados medidos:

• Mantenha o log bruto palavra por palavra. Todo resumo acima dele é um cache e deve apontar de volta para o original, não substituí-lo.
• Guarde logs, notas e páginas sintetizadas como coisas separadas. Têm ciclos de vida diferentes e falham de formas diferentes.
• Injete um índice pequeno e deixe o modelo buscar o detalhe sozinho. Não carregue o diretório de memória inteiro no prompt e torça para dar certo.
• Agende a passagem de correção e dê a ela computação de verdade. Um agente que nunca revisita suas notas mantém o primeiro erro para sempre.
• Monitore a desatualização como você monitora o custo: data da última verificação, vezes lidas, vezes contraditas. O número de notas não é uma métrica de saúde.

Se suas sessões duram cinco turnos e começam do nada, nada disso se paga. O design pressupõe uma tarefa que roda por milhares de passos contra um mundo que muda por baixo dela.