Como a Memória de Agentes Realmente Funciona
Faça a mesma pergunta a um chatbot duas vezes em duas sessões e ele responde como um estranho nas duas. Isso não é um bug — é o padrão. Um modelo de linguagem bruto não tem memória entre chamadas. Tudo o que ele "lembra" dentro de uma conversa vive na janela de contexto, e quando essa conversa termina, tudo se perde.
Memória é a maquinaria que você acopla para consertar isso: os sistemas que decidem o que um agente deve carregar adiante, onde armazená-lo e como trazer de volta a peça certa no momento certo. Em 2026 isso deixou de ser uma missão secundária e virou uma parte de primeira classe do design de agentes, com seus próprios benchmarks, frameworks e uma literatura de pesquisa genuína. Esta página é o mapa.
- Entender por que uma janela de contexto não é memória — e onde a fronteira realmente está
- Distinguir os quatro tipos de memória que os agentes usam: de trabalho, episódica, semântica, procedural
- Comparar os quatro padrões de armazenamento: contexto completo, vetorial/RAG, knowledge-graph e compactação/sumarização
- Ver como Claude, ChatGPT e Gemini implementam memória hoje
- Escolher uma abordagem de memória para o seu próprio agente sem exagerar na engenharia
A única ideia para guardar: contexto ≠ memória
A confusão mais comum é tratar uma janela de contexto grande como "memória". Não é. A janela de contexto é espaço de trabalho para um único turno — ela é reabastecida do zero a cada chamada, é finita e é cara. A atenção também se degrada ao longo dela (o efeito "lost in the middle" abordado em Context Engineering).
A memória é diferente de três maneiras:
| Janela de contexto | Memória | |
|---|---|---|
| Duração | Uma requisição | Entre sessões, dias, para sempre |
| Tamanho | Teto fixo de tokens | Efetivamente ilimitada (armazenamento externo) |
| Custo | Pago a cada turno | Pago uma vez para escrever; barato para referenciar |
| Acesso | Tudo, sempre à vista | Seletivo — recupera apenas o que é relevante |
Todo o jogo da memória de agentes é mover a informação certa entre essas duas: escrever fatos duráveis para fora da janela para que você não pague por eles a cada turno, e trazê-los de volta para dentro apenas quando este passo específico precisar deles. Acerte esse fluxo e um agente pode operar por semanas com uma janela de contexto que só contém alguns milhares de tokens relevantes.
Os quatro tipos de memória
Tomando emprestado (livremente) da ciência cognitiva, o ecossistema de agentes de 2026 convergiu para quatro categorias. Você raramente precisa de todas as quatro — mas nomeá-las impede que você construa um único amontoado que faz tudo mal.
- O que está na janela de contexto agora — a tarefa atual, os últimos turnos, os resultados de ferramentas deste passo. Volátil por design. Este é o rascunho, não o arquivo. Gerenciá-la bem é context engineering; não é persistência.
- Coisas específicas que aconteceram, com um timestamp. 'Na terça o usuário disse que o checkout estava quebrado; na quarta o suporte marcou como resolvido.' A memória episódica é inerentemente temporal — a ordem e o quando importam. É o que permite a um agente raciocinar sobre um histórico em vez de um instantâneo.
- Fatos e preferências duráveis, despojados de quando você os aprendeu. 'O usuário prefere unidades métricas.' 'Este cliente está no plano enterprise.' A memória semântica é em grande parte atemporal — ela representa o que o agente acredita ser verdade atualmente, não o evento em que descobriu.
- Como fazer algo — habilidades reutilizáveis, workflows e rotinas aprendidas. A menos madura das quatro na prática. Em ferramentas como Claude Code isso frequentemente vive como arquivos de instrução (CLAUDE.md) e skills reutilizáveis em vez de um armazenamento automático.
Um teste útil: se você responderia com "quando isso aconteceu?" é episódica; se você responderia com "o que é verdade?" é semântica; se você responderia com "veja como" é procedural; e se só importa pelos próximos segundos, é memória de trabalho e não precisa ser persistida de forma alguma.
Os quatro padrões de armazenamento
Uma vez que você sabe o que lembrar, você escolhe como armazená-lo e recuperá-lo. Existem quatro padrões dominantes, aproximadamente em ordem de complexidade. A maioria dos sistemas reais combina dois ou três.
1. Contexto completo (enfia tudo dentro)
Mantenha todo o histórico e reenvie-o a cada turno. Zero infraestrutura, recall perfeito — até você atingir o teto de tokens, a curva de custo ou o "lost in the middle". Ótimo para assistentes curtos; um beco sem saída para qualquer coisa de longa duração. Este é o baseline sobre o qual todos os outros padrões melhoram.
2. Memória vetorial / RAG
Escreva cada memória como um embedding em um banco de dados vetorial; no momento da consulta, faça o embedding do turno atual e recupere as top-k memórias mais similares. Isto é retrieval-augmented generation apontado para o histórico da conversa em vez de documentos. Barato, escalável e o padrão para o recall semântico de fatos e preferências.
Sua fraqueza: similaridade ≠ relevância para perguntas temporais ou multi-hop. "O que decidimos depois que o orçamento foi cortado?" é uma pergunta de ordenação, e a similaridade de cosseno não tem noção de tempo ou de encadear dois fatos.
3. Memória de knowledge-graph
Armazene memórias como entidades e relacionamentos — nós e arestas, frequentemente com timestamps nas arestas. Para responder a uma pergunta você percorre o grafo em vez de fazer correspondência aproximada de vetores. É isso que torna o raciocínio multi-hop e temporal tratável ("quem substituiu a pessoa que era dona da conta sobre a qual o usuário reclamou?"). Frameworks como Zep/Graphiti construíram toda a sua proposta em torno de knowledge graphs temporais. O custo é engenharia real: extração, resolução de entidades e evitar que o grafo apodreça.
4. Compactação e sumarização
Comprima periodicamente o histórico corrente em um resumo destilado e continue a partir dele — trocando o recall literal por uma janela menor e mais barata. É isso que o /compact faz no Claude Code, e o que o "auto-summary" faz em muitos produtos de chat. É a forma mais barata de memória de longo prazo e frequentemente a primeira que você realmente precisa. Seu risco: o resumo descarta silenciosamente o único detalhe de que você precisava. Veja Long-Running Agent Harnesses para saber como isso se desenrola ao longo de execuções de horas.
Sistemas reais combinam essas camadas. Um stack comum em 2026: compactação para a conversa corrente, vetorial para fatos semânticos e um grafo por cima apenas quando consultas temporais/multi-hop realmente aparecem no seu tráfego. Não construa o grafo até sentir a dor que o grafo resolve.
Como os três grandes fazem isso
Todo assistente importante agora entrega alguma memória. Elas não são a mesma coisa, e as diferenças importam.
| Produto | O que ele lembra | Como funciona (aproximadamente) |
|---|---|---|
| Claude | Duas camadas: uma memória em nível de app das suas preferências, e uma memory tool voltada para desenvolvedores para agentes. | A memória do app Claude armazena fatos entre conversas; a memory tool mais context editing da API permite a um agente escrever notas em um armazenamento client-side e podar automaticamente resultados de ferramentas obsoletos para sobreviver a execuções longas. |
| ChatGPT | "Saved memories" (fatos explícitos) mais referência às suas conversas passadas. | Uma mistura de fatos declarados pelo usuário e preferências extraídas automaticamente, injetadas no contexto do sistema em turnos posteriores. Editáveis e ativáveis/desativáveis pelo usuário. |
| Gemini | Contexto pessoal extraído das suas conversas e, opcionalmente, da superfície mais ampla da conta Google. | Recupera detalhes de conversas anteriores e pode personalizar usando o contexto da conta, sujeito aos seus controles de privacidade. |
Duas conclusões. Primeiro, a memória de consumidor é majoritariamente semântica — preferências e fatos — não um replay episódico completo. Segundo, se você está construindo um agente, a memória embutida do produto não é o seu sistema de memória; você é dono dessa camada, usando primitivas como a memory tool do Claude ou um framework externo.
Transforme um modelo bruto em um agente que faz anotações (a memória real mais barata)
You have a file called MEMORY.md that persists between our sessions. At the END of each session, append any durable facts worth keeping: - my stable preferences (tools, formats, style) - decisions we made and WHY - open threads to resume next time At the START of each session, read MEMORY.md first and use it. Keep it under 30 lines — when it grows past that, consolidate and delete anything stale. Never store secrets or credentials.
Esse único padrão — escrever notas duráveis em um arquivo externo, lê-las de volta da próxima vez — é o 80/20 da memória de agentes. A maior parte da maquinaria de frameworks abaixo é uma versão mais automática e mais escalável de exatamente isso.
Medindo a memória: o benchmark LoCoMo
Você não pode melhorar o que não pode medir, e a memória era difícil de medir até os benchmarks chegarem. O mais citado é o LoCoMo ("Evaluating Very Long-Term Conversational Memory of LLM Agents"): conversas multi-sessão muito longas — centenas de turnos ao longo de dezenas de sessões — com pares de pergunta-resposta em cinco sabores: single-hop, multi-hop (entre sessões), raciocínio temporal, open-domain e adversarial.
O que o LoCoMo revela é o padrão em torno do qual projetar: os sistemas se saem bem no recall factual single-hop e desmoronam em perguntas temporais e multi-hop. Esse modo de falha é exatamente por que a memória de knowledge-graph existe — é o padrão que mais eleva essas duas categorias. Quando você avaliar a memória do seu próprio agente, pese os casos multi-hop e temporais fortemente; o recall single-hop lisonjeia quase tudo.
Escolhendo uma abordagem sem exagerar na construção
- Não faça nada. A memória de trabalho (a janela de contexto) é suficiente. Adicionar um armazenamento de memória aqui é puro overhead.
- Comece com anotações em um arquivo externo, ou com a memória embutida do produto. Isso cobre a maioria das necessidades de 'lembrar minhas preferências' a custo quase zero.
- Adicione compactação/sumarização. Mantenha os fatos que sustentam a estrutura, descarte o lance a lance. É aqui que vivem os agentes de longa duração.
- Adicione memória vetorial/RAG. Recupere as top-k memórias relevantes por turno em vez de reenviar tudo.
- Só agora recorra a um knowledge graph — ou a um framework gerenciado (Mem0, Letta, Zep, LangMem) que te dá um sem ter que fazer extração e resolução de entidades na mão.
A armadilha é começar no passo cinco. A memória de grafo é impressionante em demos e cara em produção. Suba a escada; pare no primeiro degrau que resolve o seu problema real.
Check yourself
0/4O resumo do que importa
A memória não é um recurso que você liga — é um fluxo que você projeta: o que sai da janela, onde é armazenado e como volta. Nomeie os quatro tipos de memória para não construir um único amontoado para todos eles. Comece no padrão de armazenamento mais barato que resolve o seu problema e suba apenas quando sentir a dor do próximo. E meça com casos temporais e multi-hop, porque o recall single-hop faz tudo parecer mais inteligente do que é.
A memória é a outra metade de Context Engineering: o context engineering decide o que preenche a janela neste turno; a memória decide o que sobrevive entre os turnos. Juntos, eles são o que separa um chatbot de um agente que fica melhor quanto mais tempo você trabalha com ele.
Fontes e leituras adicionais
- Evaluating Very Long-Term Conversational Memory of LLM Agents (LoCoMo) — o benchmark canônico; página do projeto.
- Effective context engineering for AI agents — Anthropic sobre compactação, anotações e recuperação just-in-time.
- Claude memory tool & context editing docs — a primitiva voltada para desenvolvedores.
- Agent Memory Techniques — 30 notebooks executáveis cobrindo buffers de conversa, vector stores, knowledge graphs, memória episódica/semântica, Mem0, Letta, Zep, Graphiti e LoCoMo.
- The State of AI Agent Memory 2026 — relatório de fornecedor sobre arquiteturas de memória e benchmarks (leia com a cautela habitual sobre números auto-reportados).
- Relacionados no AILmanac: Context Engineering · Long-Running Agent Harnesses · RAG · Claude app memory · Memory & Context Editing (API).