Memória de Agente Explicada: Tipos, Ferramentas e Como Adicioná-la
Publicado originalmente em m-i-n-d.ai. Eu escrevo e mantenho o MIND, um servidor de memória MCP — divulgação completa desde o início, já que este artigo também aborda opções de memória que não são nossas.
O Que É Memória de Agente?
Os quatro tipos, como os principais frameworks diferem e como adicionar memória real a um agente que você está construindo.
Por Anthony Conti · Astra AI, LLC · Última atualização em 7 de setembro de 2026
A memória de agente é o mecanismo que permite que um agente de IA retenha informações — fatos, preferências, ações passadas e resultados — ao longo de turnos, sessões e ferramentas, em vez de começar do zero toda vez que sua janela de contexto é redefinida. Um agente sem memória pode raciocinar brilhantemente dentro de uma conversa e não lembra nada sobre a pessoa ou a tarefa no momento em que essa conversa termina. A memória é a camada que corrige isso, e é uma preocupação genuinamente separada do modelo, do framework e da janela de contexto.
Por que isso importa mais em 2026 do que em 2023. Os primeiros chatbots conseguiram funcionar sem memória porque uma sessão era todo o produto. Os agentes agora executam tarefas de vários dias, transferem trabalho entre ferramentas e são esperados para lembrar uma decisão tomada três semanas e duas trocas de modelo atrás. As janelas de contexto cresceram — muitos modelos agora oferecem bem mais de 100.000 tokens, e alguns excedem um milhão — mas uma janela maior ainda é memória de trabalho: ela é redefinida no instante em que a chamada termina. Nada disso resolve a persistência.
Os quatro tipos de memória que um agente pode ter
Tomado emprestado de forma ampla da ciência cognitiva, e útil porque a maioria das perguntas "adicionar memória ao meu agente" são realmente "qual desses quatro eu realmente preciso?".
| Tipo | Vive em | Sobrevive | Exemplo |
|---|---|---|---|
| Memória de trabalho | A janela de contexto — os tokens enviados ao modelo nesta chamada | Nada além desta conversa, e muitas vezes nem mesmo toda a conversa uma vez que ela é longa | As últimas dez mensagens do chat em que você está agora |
| Memória de longo prazo / semântica | Armazenamento externo — um banco de dados vetorial, um grafo de conhecimento, um armazenamento de documentos | Sessões, reinicializações e (se o armazenamento for compartilhado) o agente específico que o escreveu | "Este usuário prefere TypeScript em vez de JavaScript" — recuperado meses depois |
| Memória episódica | Um registro de eventos passados específicos, geralmente com data/hora | Enquanto o registro for mantido — muitas vezes podado ou resumido ao longo do tempo | "Em 3 de março tentamos Redis e revertermos devido à latência" |
| Memória procedural | Padrões aprendidos sobre como fazer algo, não o que aconteceu | Indefinidamente, e geralmente se generaliza em muitos episódios | "Este código sempre quer testes na mesma PR que a funcionalidade" |
A maioria dos sistemas reais só precisa de memória de trabalho mais memória de longo prazo/semântica para cobrir os casos comuns. Memória episódica e procedural importam mais para agentes que operam em tarefas longas, de vários dias, onde a sequência específica de eventos passados, não apenas os fatos extraídos deles, muda o que o agente deve fazer a seguir.
A memória de agente é a mesma coisa que RAG?
Não, embora os dois sejam frequentemente construídos juntos e se confundam por causa disso. Geração aumentada por recuperação é uma técnica de geração: buscar pedaços relevantes, colocá-los no prompt. A memória de agente é o sistema mais amplo responsável por decidir o que um agente deve reter, consolidar ou esquecer ao longo do tempo — RAG é tipicamente o mecanismo de recuperação que o sistema de memória usa no momento da resposta, mas a memória também cobre o caminho de gravação (o que é armazenado e quando) que RAG sozinho não diz nada.
Por que uma janela de contexto maior não pode simplesmente substituir a memória?
Porque uma janela de contexto é memória de trabalho, e a memória de trabalho nunca foi o que os problemas de persistência dizem respeito. Mesmo um modelo com uma janela de um milhão de tokens esquece tudo no momento em que uma nova conversa começa, a menos que algo fora daquela janela escreva os fatos relevantes primeiro. Enfiar um histórico inteiro em cada prompt também se torna lento e caro muito antes de você atingir um limite rígido de tokens — a maioria dos agentes de produção resume ou recupera seletivamente bem abaixo do máximo, o que é uma decisão do sistema de memória, não uma da janela de contexto.
Como os principais frameworks lidam com isso de forma diferente
Não há uma única implementação de "memória de agente" — cinco projetos bem conhecidos adotam abordagens significativamente diferentes, verificadas na documentação de cada projeto nesta sessão:
| Projeto | Abordagem |
|---|---|
| LangGraph | Checkpointing — todo o estado do grafo é persistido após cada passo, para que uma execução possa retomar exatamente de onde parou |
| Letta (MemGPT) | Um modelo inspirado em SO — o agente gerencia sua própria memória, trocando fatos entre "contexto principal" limitado (RAM) e "memória arquivada" ilimitada (disco) |
| Mem0 | Uma camada de extração e consolidação — um LLM decide o que de uma conversa vale a pena lembrar, e então armazena com indexação vetorial + opcional de grafo |
| Zep / Graphiti | Um grafo de conhecimento temporal — fatos são nós e arestas com janelas de validade, para que o sistema possa raciocinar sobre o que era verdadeiro quando, não apenas o que é verdadeiro agora |
| Servidores de memória MCP (este cluster) | Nível de protocolo — memória exposta como ferramentas MCP que qualquer agente compatível pode chamar, independente de qual framework construiu o agente |
Como adicionar memória a um agente via MCP?
Em vez de conectar seu agente a uma API de memória específica de um framework, você o direciona para um servidor de memória MCP — um processo externo que expõe a memória como ferramentas MCP padrão (store_memory, search_memory). A vantagem sobre um módulo de memória nativo de framework: a mesma memória se torna acessível de qualquer cliente compatível com MCP, não apenas do framework em que você construiu o agente. A configuração prática leva cerca de 10 minutos — veja o guia de configuração para a configuração exata.
O escopo é a outra decisão que vale a pena fazer explicitamente antes de conectar qualquer coisa. A memória pode ser escopada por usuário (cada fato vinculado a uma pessoa, o padrão que a maioria dos produtos assume), por agente (um fato que um agente específico aprendeu, não compartilhado com outros atuando na mesma conta), ou global (compartilhada entre todos os agentes e todos os usuários em uma conta, o que é raro e geralmente só apropriado para fatos de toda a organização). Errar isso em qualquer direção — vazar a memória de um usuário para o contexto de outro, ou isolar a memória de tal forma que nenhum dos dois agentes possa compartilhá-la — é uma falha mais comum do que escolher o backend de armazenamento errado.
Uma lista de verificação curta para escolher uma abordagem
- Um agente, um framework, nunca sai dele? Um módulo de memória nativo de framework (checkpointing do LangGraph, memória arquivada embutida do Letta) é a menor fricção.
- Múltiplos agentes ou ferramentas precisam da mesma memória? Um servidor de memória MCP é a camada certa — a memória se torna acessível independentemente de qual
A implementação de memória em agentes de IA é crucial para empresas que buscam automatizar processos e melhorar a experiência do usuário. Com a evolução das interações, a capacidade de reter informações se torna um diferencial competitivo. Empresas brasileiras devem considerar essa tecnologia para se manterem relevantes no mercado.
