Por que o agente esquece tudo: como dar memória de verdade ao seu agente de IA

Todo dia seu agente começa do zero. Você conversa, explica o contexto, ele resolve o problema. Aí a sessão fecha e, na manhã seguinte, é como se você nunca tivesse falado com ele. Mesmo dentro da mesma conversa, depois de muito vai-e-vem, ele "esquece" o que você pediu lá no começo.

Não é bug. É como o modelo funciona por baixo. Um LLM não tem memória própria — cada chamada é uma folha em branco. A "memória de agente de IA" não vem de graça: é uma camada de arquitetura que você constrói por cima do modelo. E é exatamente isso que separa um chatbot de demonstração de um agente que aguenta produção.

Neste post você vai entender por que o agente esquece, qual a diferença entre memória de curto e de longo prazo, e como dar memória de verdade pro seu agente sem cair na complexidade desnecessária.

TL;DR

• O que é: memória de agente é a infraestrutura que faz um LLM (que é stateless) lembrar de coisas dentro de uma conversa e entre sessões diferentes.
• Por que importa: sem ela, o agente não aprende nada sobre o usuário, repete perguntas e não mantém estado de tarefas longas.
• Os dois tipos: curto prazo (histórico da conversa + janela de contexto) e longo prazo (armazenamento externo que sobrevive ao fim da sessão).
• Aprofundamento: onde guardar a memória de longo prazo com pgvector no Postgres.

Por que o agente de IA esquece tudo

Vamos ao ponto que ninguém explica direito.

O modelo de linguagem é stateless. Sem estado. Cada requisição que você manda pra API é independente da anterior. O modelo não tem um "lugar" onde guarda o que aconteceu ontem, nem mesmo o que aconteceu três mensagens atrás. Ele recebe um monte de texto na entrada, calcula a próxima resposta, e esquece tudo.

"Mas o ChatGPT lembra do que eu falei na mensagem anterior."

Lembra porque a aplicação reenvia o histórico inteiro a cada turno. A ilusão de memória é isso: a cada nova mensagem, o sistema cola toda a conversa anterior e manda pro modelo de novo. O modelo não lembrou de nada — ele releu tudo.

Isso tem duas consequências diretas:

1. A memória "de graça" é só a janela de contexto. O agente só sabe o que está naquela leva de tokens que você reenviou. Fechou a sessão, perdeu o histórico, acabou a memória.
2. A janela de contexto é finita — e cara. Você não pode reenviar tudo pra sempre. Conversa longa, documento grande, histórico de semanas: uma hora não cabe. E mesmo antes de não caber, a performance cai.

A Anthropic chama esse segundo problema de context rot: o modelo tem um "orçamento de atenção" limitado, igual à memória de trabalho de uma pessoa. Como a arquitetura transformer faz cada token prestar atenção em todos os outros, quanto mais você empilha contexto, mais difícil fica pro modelo focar no que importa. Nas palavras deles: "assim como humanos, que têm capacidade de memória de trabalho limitada, LLMs têm um 'orçamento de atenção' do qual eles sacam ao processar grandes volumes de contexto" (Anthropic — Effective context engineering).

Ou seja: encher a janela de contexto não é memória. É empurrar o problema com a barriga até ele estourar.

Os dois tipos de memória que seu agente precisa

A confusão começa porque "memória" é uma palavra só pra duas coisas bem diferentes. Quem trabalha com agente sério separa em curto prazo e longo prazo. A analogia que o pessoal do Mem0 usa é boa: pense num caderno. Tem o post-it da tarefa de agora, tem o diário do dia, e tem o arquivo de tudo que o usuário já te contou.

Memória de curto prazo (a conversa atual)

É o estado da sessão em andamento. O histórico de mensagens daquela conversa específica. No LangGraph, isso é o que um checkpointer faz: salva o estado do agente a cada passo, amarrado a um thread_id — o identificador daquela conversa. Enquanto você manda mensagens no mesmo thread, o agente continua de onde parou.

Curto prazo responde à pergunta: "o que foi dito nesta conversa?"

O problema: ela morre com a sessão. Novo thread_id, memória zerada. E ela vive dentro da janela de contexto — então sofre do mesmo limite de tamanho que vimos acima.

Memória de longo prazo (o que sobrevive à sessão)

É o que persiste entre conversas. As preferências do usuário, fatos que ele te contou semana passada, o progresso de uma tarefa que dura dias. Isso não pode viver na janela de contexto — tem que ficar guardado fora dela, num armazenamento externo, e ser recuperado sob demanda.

No LangGraph esse é o papel do store, separado do checkpointer e organizado por namespaces (tipo ("user_id", "memories")). A diferença é cirúrgica: "se você guarda uma preferência do usuário no checkpointer, ela some no instante em que você começa um novo thread_id; se guarda no store, ela está lá independente do thread em que o usuário voltar."

Longo prazo responde a outra pergunta: "o que eu sei sobre este usuário e este projeto, de todas as vezes que conversamos?"

Dentro do longo prazo ainda dá pra separar dois sabores, emprestados da psicologia:

• Memória episódica: eventos específicos, com ordem cronológica. "O usuário subiu um PDF ontem", "na sessão passada a gente decidiu usar Postgres".
• Memória semântica: fatos e conceitos soltos do tempo. "O usuário prefere respostas curtas", "a stack do projeto é Laravel + pgvector".

Você não precisa dos dois pra começar. Mas saber que existem evita você jogar tudo num balde só.

Como dar memória de verdade ao seu agente

Beleza, e na prática? Tem três níveis, do mais simples ao mais robusto. Sobe um degrau de cada vez — não comece pelo topo.

Nível 1: histórico + resumo (resolve a curto prazo)

O básico: a cada turno, reenvie o histórico da conversa. Você já faz isso de graça quando usa o array de messages da API.

O problema aparece quando a conversa cresce. A solução não é reenviar tudo pra sempre — é resumir. Quando o histórico passa de um tamanho, você roda uma compactação: pega as mensagens antigas, gera um resumo, e substitui o bloco inteiro por esse resumo. O agente mantém o fio da meada gastando uma fração dos tokens.

A própria Anthropic empacotou essa ideia no context editing: remover automaticamente chamadas de ferramenta antigas e resultados obsoletos da janela conforme o agente se aproxima do limite. Num teste de busca web de 100 turnos, isso deu 84% de redução no consumo de tokens e ainda permitiu completar fluxos que antes falhavam por estouro de contexto (Anthropic — context management).

Nível 2: anotações externas (a ponte pro longo prazo)

Resumo segura a conversa, mas some quando a sessão fecha. O próximo degrau é o agente escrever notas pra fora da janela de contexto e relê-las depois.

A Anthropic chama isso de structured note-taking ou agentic memory: "uma técnica onde o agente regularmente escreve notas que persistem em memória fora da janela de contexto". O memory tool deles implementa isso da forma mais simples possível — nada de vector database, nada de busca semântica. É um diretório de arquivos. O Claude cria, lê, atualiza e apaga arquivos numa pasta de memória que você hospeda na sua infraestrutura, e que persiste entre conversas:

"Claude pode criar, ler, atualizar e apagar arquivos num diretório de memória dedicado, armazenado na sua infraestrutura, que persiste entre conversas. Isso permite que agentes construam bases de conhecimento ao longo do tempo, mantenham estado de projeto entre sessões e referenciem aprendizados anteriores sem ter que manter tudo no contexto."

Combinado com context editing, esse arranjo deu 39% de ganho numa avaliação interna de busca agêntica — porque a memória persiste o que é importante mesmo quando a compactação corta o histórico. É o melhor custo-benefício pra maioria dos casos: um arquivo Markdown bem organizado já te leva longe.

Nível 3: memória semântica recuperável (longo prazo de verdade)

Quando o volume cresce — milhares de fatos, histórico de meses, muitos usuários — ler um arquivo inteiro não escala. Você quer recuperar só os pedaços relevantes pra pergunta de agora. É aí que entra o RAG aplicado à memória: você guarda cada fato como um embedding num banco vetorial e, a cada turno, busca por similaridade os trechos que importam e injeta só eles no contexto.

Esse é o nível que merece um post inteiro — e tem. Se você chegou até aqui e quer ver onde guardar essa memória de longo prazo na prática, sem assinar serviço gerenciado caro, é só seguir pro pgvector no Postgres: onde guardar a memória do seu agente. Spoiler: o Postgres que você já tem resolve 80% do problema.

Limitações e pontos de atenção

Memória resolve um problema e cria outros. Antes de sair plugando store em tudo:

• Mais memória não é melhor. Recuperar contexto demais traz de volta o context rot. Memória boa é seletiva — guarda o que importa e descarta o resto. Resumo que vira romance é tão ruim quanto não ter resumo.
• Memória é estado, e estado tem ciclo de vida. Fato desatualizado é pior que fato ausente. Se o usuário mudou de ideia, a memória antiga precisa ser corrigida ou apagada, senão o agente decide com base em informação velha.
• Memória é superfície de ataque. Se o agente escreve na memória o que o usuário diz, um usuário mal-intencionado pode plantar instruções que vão ser relidas depois (prompt injection persistente). Memória que alimenta o contexto precisa do mesmo cuidado de qualquer input não confiável.
• Privacidade. Memória de longo prazo é dado de usuário guardado. Isso é LGPD. Tenha um jeito de listar, exportar e apagar o que você guardou sobre cada pessoa.

FAQ rápido

Memória de agente é a mesma coisa que RAG? Não, mas se cruzam. RAG é uma técnica de recuperar informação relevante e injetar no contexto. Memória de longo prazo geralmente usa RAG pra recuperar fatos guardados — mas memória também inclui curto prazo (histórico) e anotações simples em arquivo, que não são RAG.

Preciso de um banco vetorial pra dar memória ao meu agente? Não pra começar. Histórico + resumo resolve curto prazo sem banco nenhum. Um arquivo de notas resolve boa parte do longo prazo. Banco vetorial entra quando o volume de fatos cresce a ponto de não dar mais pra ler tudo de uma vez.

Janela de contexto grande não resolve o problema de memória? Ajuda, mas não resolve. Janela maior cabe mais texto numa sessão, mas continua morrendo quando a sessão fecha — e o context rot piora quanto mais você enche. Contexto grande é capacidade de leitura, não memória persistente.

Qual a diferença entre memória de curto e longo prazo, na unha? Curto prazo vive na janela de contexto e some no fim da sessão (no LangGraph, o checkpointer amarrado ao thread_id). Longo prazo vive num armazenamento externo e sobrevive entre sessões (o store, acessível de qualquer thread).

Conclusão

O agente esquece porque o modelo é stateless por natureza — e a memória que parece existir é só a janela de contexto sendo reenviada. Memória de verdade é arquitetura: curto prazo pra segurar a conversa, longo prazo pra atravessar as sessões, e bom senso pra não encher o contexto de lixo.

Comece simples. Histórico e resumo resolvem mais do que parece. Um arquivo de notas te leva ainda mais longe. E quando o volume pedir, você sobe pro banco vetorial sem ter quebrado nada no caminho.

Esse raciocínio — decidir qual camada de memória cada problema realmente exige, em vez de plugar a solução mais cara — é o tipo de decisão de arquitetura que a gente coloca na mesa no Workshop Arquitetando Soluções de IA, construindo agentes de verdade, do contexto à memória. Porque construir produto com IA não é prompt bonito: é saber onde cada peça mora.