Memória de Agentes IA em Produção: Como Construir Sistemas Que Realmente Lembram

Em abril de 2026, um survey publicado no arXiv por Huang e colegas estabeleceu o que todo time de engenharia de IA já sentia na prática: a pesquisa em inteligência artificial entrou na sua "segunda metade", onde o desafio central não é mais treinar modelos maiores, mas fazer com que agentes mantenham utilidade real em interações longas, dinâmicas e dependentes do usuário (Huang et al., 2026, arXiv:2602.06052). Nesse novo paradigma, a memória emerge como a solução crítica para preencher a lacuna de utilidade. Centenas de papers foram publicados só em 2026 sobre o tema. A pergunta deixou de ser "o modelo sabe responder?" e passou a ser "o agente lembra do que precisa saber para responder bem?"

A maioria dos agentes de IA em produção hoje é amnésica. Cada nova sessão começa do zero: sem memória de preferências do usuário, sem histórico de interações passadas, sem conhecimento acumulado sobre o domínio. Em 2025, isso era aceitável. Em 2026, com agentes que custam centavos por turno e operam dezenas de inferências por sessão, a amnésia é um problema de custo, de experiência e de competitividade. Um agente que esquece tudo entre sessões força o usuário a repetir contexto, aumenta o número de turnos necessários para completar uma tarefa e degrada a percepção de inteligência do sistema.

Este artigo mapeia as quatro camadas de memória que um agente de produção precisa ter, compara os quatro frameworks que dominam o mercado em 2026 (Letta, Mem0, Zep e LangMem), e mostra como tomar a decisão de arquitetura correta para o seu caso de uso, com atenção especial ao contexto brasileiro, onde infraestrutura na nuvem custa caro e soberania de dados é requisito, não diferencial.

1. Por que "só aumentar o contexto" não funciona

O instinto de resolver o problema de memória simplesmente enchendo a janela de contexto com todo o histórico é compreensível. Modelos de 2026 como GPT-5.4 e Claude Opus 4.6 suportam janelas de centenas de milhares de tokens. Por que não colocar tudo lá dentro?

O benchmark BEAM, desenhado especificamente para testar memória em conversas de um milhão de tokens, responde diretamente a essa pergunta. Todos os modelos testados, incluindo aqueles com as maiores janelas de contexto, ainda falham em resolução de contradição: manter estado globalmente consistente quando fatos anteriores conflitam com atualizações posteriores (AgentMarketCap, 2026). O problema não é capacidade de armazenamento, é capacidade de raciocínio sobre o que foi armazenado.

Há também o custo. A precificação de APIs frontier em 2026 cobra por token de entrada. Uma janela de 600 mil tokens carregada a cada turno de agente se traduz em custos de infraestrutura que escalam rapidamente em produção. Um relatório da VentureBeat previu que camadas dedicadas de memória contextual ultrapassarão o uso de RAG tradicional para agentes de IA até o final de 2026 (AgentMarketCap, 2026). Os dados sugerem por quê: agentes de produção que implementam múltiplos tipos de memória mostram desempenho mensuravelmente melhor em benchmarks multi-sessão do que agentes de contexto único, mesmo quando estes têm acesso a janelas maiores.

A conclusão é direta: contexto é recurso finito com retornos marginais decrescentes. Memória não é sinônimo de contexto. Memória é a arquitetura que decide o que entra no contexto, quando entra, e por quanto tempo fica.

2. As quatro camadas de memória de um agente

O survey de Huang et al. (2026) propõe uma taxonomia unificada de memória para agentes de fundação ao longo de três dimensões: substrato (interno e externo), mecanismo cognitivo (episódica, semântica, sensorial, de trabalho e procedural) e sujeito (centrada no agente e centrada no usuário). Na prática de engenharia, isso se traduz em quatro camadas que todo agente de produção precisa implementar, em maior ou menor grau.

Memória de trabalho (working memory)

É o contexto imediato do agente: a instrução atual, as últimas mensagens da conversa, os resultados de ferramentas recentes. Fica na janela de contexto do LLM e é volátil por definição. Equivale à memória de curto prazo do sistema cognitivo humano. O custo de manter informação aqui escala quadraticamente: a arquitetura transformer calcula atenção par a par (n² relações para n tokens), o que significa que dobrar o contexto mais que dobra o custo computacional de atenção (Vaswani et al., 2017, arXiv:1706.03762).

A gestão da memória de trabalho é o que o artigo anterior desta série chamou de context engineering: curar o conjunto ótimo de tokens a cada turno. Mas memória de trabalho é apenas a camada mais superficial. Sem as outras três camadas alimentando-a com a informação certa no momento certo, ela se torna um buffer que esquece tudo entre sessões.

Memória episódica (episodic memory)

Registra eventos específicos passados: "na sessão de ontem, o usuário perguntou sobre impostos sobre faturamento e o agente respondeu com base na Lei 14.973/2024". É a memória do que aconteceu, quando aconteceu e em que contexto. Em produção, a memória episódica permite que um agente retome conversas interrompidas, referencie interações anteriores e mantenha coerência narrativa ao longo de dias ou semanas.

A implementação típica é um log estruturado de turnos de conversa, armazenado em um banco de dados vetorial ou banco relacional, com timestamps e metadados de sessão. O desafio não é armazenar, é recuperar: a memória episódica cresce sem parada, e a qualidade de recuperação diminui à medida que o volume aumenta. Políticas de expiração, consolidação e sumarização são essenciais para manter a relação sinal-ruído.

Memória semântica (semantic memory)

Extrai fatos e preferências das interações e os armazena de forma estruturada: "o usuário prefere respostas em português formal", "a empresa do usuário usa PostgreSQL como banco principal", "o orçamento mensal com IA é de R$ 15 mil". É a camada que transforma experiência em conhecimento. Diferente da memória episódica, que guarda eventos, a semântica guarda verdades extraídas desses eventos.

Frameworks como Mem0 automatizam essa extração: a cada turno de conversa, um LLM auxiliar analisa a interação e decide quais fatos merecem ser persistidos. O custo de escrita é alto (uma ou duas chamadas de LLM por turno), mas o custo de leitura é baixo: uma busca vetorial simples retorna os fatos relevantes em milissegundos, sem necessidade de LLM no caminho de leitura.

Memória procedural (procedural memory)

Guarda as skills e procedimentos que o agente aprendeu: "para responder sobre impostos, consulte a API da Receita Federal primeiro", "para este usuário, sempre formate a resposta em bullets, não em tabelas". É a memória de como fazer, não de o que aconteceu ou de o que é verdade. Em sistemas de produção, a memória procedural se manifesta como system prompts dinâmicos, configurações de tool routing aprendidas com o uso, e bibliotecas de skills que o agente descobre e aplica.

A pesquisa de fronteira em 2026 foca em como agentes podem automaticamente consolidar procedimentos a partir de trajetórias de sucesso. O survey de Lin et al. (2026, arXiv:2605.06716, aceito no ACL 2026 Findings) propõe um framework evolutivo em três estágios: Storage (preservação de trajetórias), Reflection (refinamento) e Experience (abstração). A memória procedural é o produto final da abstraction stage: o agente não apenas lembra do que fez, mas aprende regras gerais sobre como agir.

3. Os quatro frameworks que dominam o mercado

Em 2026, quatro frameworks consolidaram o espaço de memória para agentes de IA: Letta (antigo MemGPT), Mem0, Zep e LangMem. Cada um otimiza um ponto diferente na curva de custo de escrita versus custo de leitura, e a escolha correta depende do padrão de tráfego da sua aplicação.

Letta (MemGPT): o modelo de sistema operacional

Letta começou como MemGPT, um projeto de pesquisa da UC Berkeley que reformulou o problema de memória usando uma analogia com sistemas operacionais (Packer et al., 2023, arXiv:2310.08560). A janela de contexto é a RAM. O armazenamento externo é o disco. O agente gerencia suas próprias decisões de paginação via tool calls explícitas.

A arquitetura organiza a memória em três tiers: Core Memory (sempre em contexto, contém fatos essenciais sobre o usuário e a tarefa atual), Archival Memory (vector store consultado via tool calls, funciona como um banco de dados que o agente conscientemente consulta) e Recall Memory (histórico de conversa pesquisável sob demanda). Em 2026, a Letta rearquitetou seu loop de agente para incorporar lições do ReAct e do Claude Code, introduzindo memory blocks versionados com git e um runtime de deploy que funciona entre provedores de modelo (AgentMarketCap, 2026).

O diferencial é o controle do agente: o próprio LLM decide o que lembrar, o que esquecer e quando recuperar. O tradeoff é overhead explícito: o agente faz mais chamadas de ferramenta, e a qualidade da gestão de memória depende da capacidade do modelo de decidir o que é importante.

Latência de busca: baixa (tool calls, sem LLM no caminho de leitura) Custo de escrita: baixo (escrita em banco + tool call) Bi-temporal: não Melhor para: agentes stateful de longa duração onde a transparência da gestão de memória importa (compliance, auditoria empresarial)

Mem0: memória gerenciada, production-first

Mem0 emergiu em 2026 como o serviço de memória de longo prazo mais maduro do ponto de vista operacional. Onde Letta oferece um framework para construir, Mem0 oferece uma API para chamar. A arquitetura combina um vector store com uma camada de grafo para relacionamentos entre entidades e um key-value store para preferências estruturadas (AgentMarketCap, 2026).

A extração de memória acontece automaticamente em background: você envia um turno de conversa para o Mem0, e ele decide o que armazenar, como categorizar e como recuperar futuramente. Os números de benchmark do próprio time do Mem0 (replicados independentemente em várias comparações da comunidade) mostram latência de busca p50 de 0,148s e p95 de 0,200s (AgentMarketCap, 2026). Para aplicações interativas como voice agents e chatbots de atendimento, sub-200ms é o limiar entre "parece nativo" e "parece que está carregando".

No benchmark LongMemEval, o Mem0 reporta 94,4% de acurácia com seu algoritmo token-efficient, contra 49,0% de versões anteriores e 63,8% do Zep (Mem0, 2026; Rasmussen et al., 2025, arXiv:2501.13956). É importante notar que esses números são altamente voláteis: o protocolo de avaliação, o modelo juiz e o pipeline de ingestão variam entre estudos, e comparações diretas devem ser feitas com cuidado.

Latência de busca: 0,148s (p50), 0,200s (p95) Custo de escrita: alto (1-2 chamadas de LLM por turno para extração de fatos) Bi-temporal: não Melhor para: aplicações customer-facing com alta densidade de fatos por usuário, times que querem memória persistente sem gerenciar infraestrutura

Zep (Graphiti): grafos de conhecimento temporais

Zep toma a abordagem mais ambiciosa arquiteturalmente. Sob o capô, o produto comercial roda sobre Graphiti, um engine open-source de grafo de conhecimento bi-temporal que rastreia não apenas o que é verdade, mas quando se tornou verdade e quando mudou (Rasmussen et al., 2025, arXiv:2501.13956).

Isso importa para uma classe específica de aplicações. Se um usuário muda sua linguagem de programação preferida, atualiza seu contato comercial ou revisa um requisito de projeto, o Zep consegue raciocinar sobre qual versão do fato era verdadeira em qual momento. Vector stores tipicamente retornam a informação mais similar. O Graphiti retorna a informação mais atual para entidades, o que é diferente.

No LongMemEval com GPT-4o, o Zep pontua 63,8% contra 49,0% do Mem0 em versões anteriores, mas a 15 pontos de distância para o Mem0 atual. O tradeoff é significativo: a latência de ingestão do Zep é alta porque a construção do grafo é custosa (extração de entidades, extração de relações, deduplicação, stamping bi-temporal, detecção de contradições). Testes indicam que a recuperação imediatamente após a ingestão pode falhar: respostas corretas às vezes só aparecem horas depois, quando o processamento do grafo em background completa (AgentMarketCap, 2026). Uma vez construído, o grafo tem latência de leitura abaixo de 50ms.

Latência de busca: <50ms (uma vez construído o grafo) Custo de escrita: muito alto (extração de entidades + relações + stamping bi-temporal) Bi-temporal: sim (valid_time + transaction_time) Melhor para: aplicações que exigem raciocínio temporal (CRM, compliance, consultoria financeira, jurídico), casos de uso onde relações entre entidades são centrais

LangMem: o nativo do LangGraph

LangMem é construído pelo time do LangChain como a camada de memória para agentes LangGraph. É open source, gratuito, e integra diretamente com a camada de storage do LangGraph sem serviços adicionais. A filosofia é transparência e controle: agentes usam tool calls explícitas para gerenciar sua própria memória, similar à abordagem do Letta, mas o backend de armazenamento é configurável: SQLite em desenvolvimento, PostgreSQL em produção, ou qualquer store compatível com LangGraph (Jatin Bansal, 2026).

As limitações práticas são reais. A latência de busca p50 é de aproximadamente 18 segundos e a p95 de 60 segundos, devido ao pipeline de extração sob demanda (AgentMarketCap, 2026). Isso elimina o LangMem para qualquer aplicação interativa de agente. O lock-in no ecossistema LangGraph também é significativo: se seu framework de agentes for CrewAI, AutoGen ou custom, o LangMem trava.

Latência de busca: ~18s (p50), ~60s (p95) Custo de escrita: variável (on-demand extraction) Bi-temporal: não Melhor para: pipelines batch em LangGraph onde a persistência de memória importa mas a latência de resposta não

4. Matriz de comparação

Dimensão	Letta (MemGPT)	Mem0	Zep (Graphiti)	LangMem
Substrato principal	Hierárquico (core/recall/archival)	Vetor + grafo opcional	Grafo bi-temporal + vetor + BM25	Configurável (SQLite, Postgres)
Custo de escrita	Baixo	Alto (LLM por turno)	Muito alto	Variável
Custo de leitura	Baixo (tool calls)	Baixo (0,148s p50)	Baixo (<50ms pós-build)	Alto (~18s p50)
Bi-temporal	Não	Não	Sim	Não
Gerenciado pelo agente	Sim (tool calls)	Não (automático)	Não (automático)	Sim (tool calls)
Multi-tenancy	Por agente	user_id	user_id / session_id	Por agente
Self-hosted	Sim	Sim (open-source)	Sim (community edition)	Sim
Melhor workload	Agentes stateful de longa duração	Chatbots e assistentes	CRM, compliance, jurídico	Pipelines batch em LangGraph

A escolha se resume a três eixos: requisitos de latência, controle versus automação, e apetite de infraestrutura do time. Para agentes customer-facing interativos, Mem0 é a escolha padrão em 2026. Para agentes que precisam raciocinar sobre mudanças temporais em relacionamentos de entidades, Zep. Para agentes enterprise com requisitos de auditoria e compliance, Letta. Para pipelines batch em LangGraph, LangMem.

5. O padrão de consolidação: não escolha um, orquestre vários

O padrão emergente em stacks de produção de 2026 não é escolher um framework, mas construir uma camada de consolidação que roteia diferentes tipos de memória para stores apropriados (AgentMarketCap, 2026). A memória de trabalho fica na janela de contexto. As preferências semânticas vão para o Mem0 ou um vector store. Os relacionamentos de entidades vão para o Graphiti do Zep. O conhecimento procedural (skills e workflows aprendidos) vai para uma biblioteca de prompts e configurações versionadas.

Essa abordagem reconhece que nenhum framework é o melhor em todos os quatro critérios identificados pelo MemoryAgentBench: recuperação acurada, aprendizado em tempo de teste, compreensão de longo alcance e esquecimento seletivo (AgentMarketCap, 2026). O Zep lidera em compreensão de longo alcance devido à estrutura do grafo temporal. O Mem0 lidera em recuperação acurada e performance prática de produção. Letta e LangMem oferecem o maior controle sobre esquecimento seletivo, já que os agentes gerenciam explicitamente o que persiste.

A camada de consolidação é o ponto onde engenharia de produto encontra arquitetura de memória. A pergunta certa não é "qual framework de memória eu uso?" mas "quais tipos de memória meu agente precisa, e qual store serve melhor cada tipo?"

6. Memória de agentes no contexto brasileiro

Para uma empresa brasileira construindo agentes de IA, três fatores moldam a decisão de arquitetura de memória de forma diferente do que se vê nos benchmarks internacionais.

Soberania de dados: agentes que atendem órgãos públicos brasileiros ou empresas em setores regulados (saúde, financeiro, jurídico) não podem enviar dados de usuário para APIs externas de extração de memória. O Mem0 Cloud, o Letta Cloud e o Zep Cloud estão fora de questão nesses casos. A opção é rodar as versões self-hosted: Mem0 open-source em infraestrutura nacional, Graphiti standalone, ou uma camada custom sobre PostgreSQL com pgvector. O custo de engenharia é maior, mas a conformidade com a LGPD e os requisitos contratuais do setor público exigem isso.

Custo de infraestrutura: os frameworks que fazem extração de LLM no caminho de escrita (Mem0, Zep) adicionam custo de API a cada turno de conversa. Em volumes altos de tráfego, esse custo se acumula. Para um agente que atende 10 mil usuários com 20 turnos por sessão, são 200 mil chamadas de LLM auxiliar por dia só para extração de memória. A alternativa é usar modelos open-source locais (como Qwen ou Llama) para a extração, reduzindo o custo marginal a quase zero, ao custo de qualidade de extração. O tradeoff entre custo e qualidade de extração é uma decisão que times brasileiros precisam fazer explicitamente.

Latência de rede: serviços managed internacionais adicionam latência de rede que pode ser inaceitável para aplicações customer-facing no Brasil. Uma chamada ao Mem0 Cloud a partir de infraestrutura em São Paulo adiciona 100-200ms de round trip, que somado à latência própria do framework pode ultrapassar o limiar de 200ms para aplicações interativas. Self-hosting em datacenters brasileiros (AWS São Paulo, GCP São Paulo, ou infraestrutura local como o Rio AI City) elimina esse overhead.

Na BaXiJen, a nossa arquitetura de memória para agentes que atendem o setor público combina Letta self-hosted para gestão de contexto (o agente decide o que promover para a memória de trabalho), um vector store em PostgreSQL com pgvector para memória semântica, e logs estruturados em PostgreSQL para memória episódica. Não usamos LLM auxiliar para extração de fatos em tempo real: fazemos consolidação em batch noturno, quando o custo de computação é menor e a latência não importa. O tradeoff é que a memória semântica não é imediatamente disponível após a interação: ela fica disponível no dia seguinte. Para o nosso caso de uso (agentes que atendem gestores públicos em sessões agendadas), essa latência de consolidação é aceitável.

7. Quando não adicionar uma camada de memória

Nem todo agente precisa de uma camada de memória dedicada. A decisão de adicionar deve ser baseada em evidência de que o agente demonstravelmente precisa lembrar entre sessões, não em sofisticação arquitetural.

Agentes de sessão única com escopo bem definido (classificação de texto, extração de entidades, sumarização de documento) não se beneficiam de memória persistente. Agentes internos de tooling que têm acesso a bancos de dados estruturados que podem consultar diretamente não precisam de um vector store de memória: a "memória" deles é o banco de dados. E agentes onde a personalização é uma query de banco ("qual o perfil deste usuário?") são melhor modelados como uma consulta estruturada do que como uma recuperação semântica.

A regra prática: adicione uma camada de memória quando seu agente atende os mesmos usuários repetidamente, acumula conhecimento de domínio ao longo do tempo, precisa manter contexto de projetos multi-dia, ou quando a personalização é uma proposta de valor central do produto. Não adicione porque soa sofisticado. Memória é infraestrutura com custo de manutenção, monitoramento e debugging que só se paga se o caso de uso a justifica.

8. Próximos passos e fronteiras de pesquisa

A pesquisa em memória de agentes está longe de resolvida. O MemoryAgentBench identifica quatro competências onde os frameworks atuais ainda falham: recuperação acurada (encontrar a memória certa, não apenas uma similar), aprendizado em tempo de teste (atualizar crenças a partir de nova informação durante a sessão), compreensão de longo alcance (conectar informação entre muitas sessões) e esquecimento seletivo (despriorizar memórias desatualizadas ou irrelevantes) (AgentMarketCap, 2026).

A fronteira mais promissora é o que o survey de Lin et al. (2026) chama de cross-trajectory abstraction: a capacidade de um agente de aprender regras gerais a partir de múltiplas trajetórias de interação, não apenas de uma. É a diferença entre "lembro que na sessão 47 o usuário pediu X e eu respondi Y" e "aprendi que usuários deste perfil tendem a pedir X, então devo preparar Y antecipadamente". Essa transição de memória episódica para procedural automatizada é o santo graal da pesquisa atual.

Para times de engenharia, o trabalho prático dos próximos meses não é esperar pela próxima inovação de framework, mas construir a camada de consolidação que permite trocar componentes conforme o estado da arte evolui. A arquitetura correta hoje é aquela que permite substituir o Mem0 por uma alternativa melhor amanhã sem reescrever o agente.

Referências

Huang, W. et al. (2026). "Rethinking Memory Mechanisms of Foundation Agents in the Second Half: A Survey." arXiv:2602.06052. https://arxiv.org/abs/2602.06052

Lin, H. et al. (2026). "From Storage to Experience: A Survey on the Evolution of LLM Agent Memory Mechanisms." ACL 2026 Findings. arXiv:2605.06716. https://arxiv.org/abs/2605.06716

Packer, C. et al. (2023). "MemGPT: Towards LLMs as Operating Systems." arXiv:2310.08560. https://arxiv.org/abs/2310.08560

Rasmussen, P. et al. (2025). "Zep: A Temporal Knowledge Graph Architecture for Agent Memory." arXiv:2501.13956. https://arxiv.org/abs/2501.13956

Vaswani, A. et al. (2017). "Attention Is All You Need." arXiv:1706.03762. https://arxiv.org/abs/1706.03762

Jiang, D. et al. (2026). "Anatomy of Agentic Memory: Taxonomy and Empirical Analysis of Evaluation and System Limitations." arXiv:2602.19320. https://arxiv.org/abs/2602.19320

AgentMarketCap (2026). "Agent Long-Term Memory in 2026: Letta, Mem0, Zep, and LangMem Compared." https://agentmarketcap.ai/blog/2026/04/08/agent-long-term-memory-architecture-letta-memgpt-langmem-zep

Jatin Bansal (2026). "Production Memory Frameworks: MemGPT/Letta, mem0, Zep, Graphiti." https://jatinbansal.com/ai-engineering/production-memory-frameworks/

Mem0 (2026). "State of AI Agent Memory 2026." https://mem0.ai/blog/state-of-ai-agent-memory-2026