Críticas, limitações e armadilhas

TL;DR

O campo de memória de agentes em 2026 mistura inovação técnica real com hype de marketing. Esta nota é a auditoria honesta da trilha: o que não funciona como prometido, onde os benchmarks enganam, quando memória persistente é over-engineered, e o que a literatura crítica está apontando. O paper arxiv 2604.21284 sobre MemPalace, a análise externa em lhl/agentic-memory e o post DEV.to de awrshift formam um pequeno corpus de revisão pública que diferencia este material de cobertura amplificadora. Material essencial para discurso público equilibrado.

Dúvidas e lacunas desta nota

• Dúvida gerada pelo conteúdo: o paper crítico arxiv 2604.21284 foi ele mesmo revisado por pares? O campo tem revisão por pares funcionando rápido o suficiente para papers críticos sobre papers de benchmark, ou o ciclo demorar meses significa que a crítica chega obsoleta?
• Lacuna potencial: a nota trata riscos de privacidade em alto nível (GDPR/LGPD) mas não aprofunda como implementações concretas (MemPalace, Letta, Mem0) endereçam — ou não — o direito ao esquecimento operacionalmente. Uma análise comparativa de forget policy por framework seria valiosa.

O que é

Você está numa entrevista técnica e acabou de citar o score de 96,6% do MemPalace em LongMemEval como prova de que a spatial palace hierarchy é a inovação que resolve memória de agentes. O entrevistador — que leu o paper crítico arXiv 2604.21284 antes de você — pergunta: “de onde vem esse número, exatamente?” A resposta correta é desconfortável: o ganho vem majoritariamente de armazenamento verbatim + ChromaDB default (a configuração padrão do banco vetorial), não da metáfora do palácio mental que deu fama ao projeto. Citar o número sem essa ressalva não é mentira deliberada — é hype não verificado, e ele custa credibilidade exatamente no momento em que mais importa.

Esta nota é a auditoria honesta do estado da arte em memória de agentes em abril de 2026. Ela não é “anti-memória de agentes” — é pró-rigor. As notas anteriores da trilha mostram avanços reais: o gist do Karpathy reorganizou o vocabulário público (06 - O LLM Wiki Pattern), Generative Agents abriu o caminho de reflexão e recuperação por relevância (18 - Generative Agents) e os surveys de 2026 (20 - Surveys) deram vocabulário comum ao campo. Tudo isso é progresso real e merece ser citado com convicção.

O que esta nota faz é a contrapartida: reconhecer avanços e ressalvas no mesmo discurso. Quem cita só os números altos perde credibilidade quando alguém da audiência leu o paper crítico; quem cita os números altos e as ressalvas já partiu da posição de quem leu mais a fundo.

Por que importa

• Sem isso, citar memória de agentes em entrevistas/talks vira mais um “amplificador de hype”. Diferenciação técnica vem de saber as limitações mais que de saber as features.
• Material para responder objeções legítimas. Em consultoria/vendas, em entrevistas técnicas, em discussões de adoção, alguém vai perguntar: “mas e o paper crítico do MemPalace? E o overfitting de benchmark? E o custo escondido?” Ter respostas calibradas separa quem sabe de quem repete.
• Higiene intelectual. O campo é jovem o bastante para que cada postura pública pese — adotar voz amplificadora ou voz auditora é decisão de marca técnica.
• Auto-defesa contra modismo. Memória de agentes é next big thing do momento e, como todo next big thing, vai ter ciclo de inflação seguido de desilusão. Conhecer as armadilhas hoje é proteção contra a desilusão do próximo ciclo.

Como funciona — categorias de crítica

1. Hype vs realidade

A primeira categoria é a mais visível: a distância entre o que o material de marketing afirma e o que código + paper revisado por terceiros mostram.

• MemPalace 96,6% / 98,4% hybrid. Score auto-reportado em LongMemEval — alto, e um dos motivos pelos quais o projeto ganhou tração. O paper crítico arxiv 2604.21284 (“Spatial Metaphors for LLM Memory: A Critical Analysis of MemPalace”, 2026-04-23) argumenta que o ganho real vem principalmente de armazenamento verbatim + ChromaDB default, não da spatial palace hierarchy. A metáfora do palácio mental — wings, rooms, drawers — vende; a engenharia que move o número é mais convencional. O paper não diz que MemPalace é fraude; diz que a inovação real está em outras dimensões (zero-LLM write path, 170-token startup, deterministic offline operation), só que a metáfora espacial chama mais atenção. Caso clássico em que branding técnico desvia o foco.

• AAAK 30x compression. A análise externa em lhl/agentic-memory/blob/main/ANALYSIS-mempalace.md testou o claim de “zero information loss” da AAAK (Adaptive Agent Aware Knowledge compression). Resultado: drop de 12,4 pontos percentuais em qualidade (96,6% → 84,2%) em workloads adversariais, contradizendo o claim de zero perda. Compressão de 30x sem perda é, em geral, promessa que sobrevive até alguém testar fora do conjunto onde foi calibrada.

• 20 MCP tools auditadas (vs 29 anunciadas). A mesma análise externa contou ferramentas efetivamente implementadas no código e encontrou 20, não as 29 anunciadas. Diferença pequena em valor absoluto, grande em sinal — mostra que ninguém está validando o que é dito.

• “Bypass de RAG” do LLM Wiki Pattern. Há leituras do gist do Karpathy que vendem o pattern como “morte do RAG”. É exagero. RAG continua valioso, especialmente quando o corpus é vasto e estável. Discussão completa em 04 - RAG vs memória de longo prazo: o pattern é alternativa em cenários específicos, não substituto universal.

• “Karpathy-endossado” vs “Karpathy-inspirado”. Vários projetos se posicionam como implementações do “Karpathy approach” de forma que implica endosso direto. Karpathy publicou um gist pessoal. Isso não é endosso de nenhum projeto específico — é um ponto de partida público que qualquer um pode estender. A distinção entre filiação técnica informal e endosso real é crucial para quem cita esses projetos em contextos profissionais.

2. Overfitting de benchmark

Benchmarks são úteis até virarem alvo. LongMemEval é um benchmark vivo, com queries conhecidas, e isso tem implicações.

• LongMemEval pode ser overfit por implementações que conhecem o benchmark. É possível tunar prompts de extração, esquemas de chunking e configurações de retrieval para os tipos de query do test set. Tecnicamente válido — mas degrada a generalização.

• “100% em hybrid mode” apareceu em algumas coberturas externas como número do MemPalace. A análise no DEV.to (awrshift, “I Over-Engineered Karpathy’s Agent Memory. Here’s What Actually Works”) descreve esse score como tendo sido “engineered through a process that most benchmark-literate engineers would consider overfitting”. Não é acusação de fraude — é diagnóstico de que o caminho até 100% provavelmente passa por escolhas que não generalizam.

• Sem evaluation independente, scores reportados pelo próprio fornecedor são suspeitos no sentido estatístico clássico: o experimentador tem incentivo para mostrar o melhor número, e mil micro-decisões implícitas (modelo, versão, prompt template, seed) podem mover o score. Regra de ouro: número auto-reportado vale como hipótese, não como conclusão.

• A reprodutibilidade costuma ser esquecida. Para validar um score você precisa conhecer: qual modelo base, qual temperatura, qual versão do benchmark, qual modo de avaliação (raw vs. hybrid), qual seed. A maioria das publicações de benchmark em memória de agentes não fornece esses dados todos de forma acessível. Sem eles, replicar o número é impossível — e testar se generaliza para seu workload, idem.

3. Viés de auto-publicação

Quem publica score em LongMemEval está se sujeitando a uma comparação pública. Quem não publica está, de algum jeito, opting out dessa comparação. Em abril de 2026 o cenário é: Letta, Cognee, LangMem e SuperMemory não publicaram scores (21 - Comparativo crítico consolida).

• Isso é sinal, não condenação. Razões possíveis: score baixo, custo alto de avaliação, workload-alvo diferente (Letta otimiza agentic loop, não QA multi-session), prioridades comerciais sobre publicações acadêmicas, ou simplesmente que o benchmark não captura o que o sistema otimiza. Sem mais informação, é indeterminado.

• Mas falta de transparência é red flag, mesmo quando justificável. Se duas ferramentas têm features comparáveis e uma publicou scores e a outra não, a que publicou parte com vantagem de credibilidade técnica. Heurística, não regra.

• A ausência também é informação. Notas de implementação que listam só os scores publicados sem mencionar quem optou por não publicar pintam quadro incompleto.

4. Quando NÃO usar memória de agentes

Há o impulso, em qualquer tema novo, de aplicar a solução em todo lugar. Memória persistente para agentes é solução boa para um conjunto de problemas, não para todos. Casos onde não vale a pena:

• Tarefas one-shot. Se o agente vai responder uma pergunta e nunca mais será chamado, RAG ou prompt direto bastam. Adicionar memória persistente é over-engineering.

• Dados sensíveis sem proteção. Memória persistente sobre conversas com usuários vira risco LGPD/GDPR. Sem política clara de retenção, anonimização e right to be forgotten, memória de agentes em produto B2C tem custo regulatório que pode dominar qualquer ganho de UX.

• Baixo orçamento de manutenção. Wiki/KG sem lint, sem revisão e sem política de descarte vira lixo em 6 meses. Notas órfãs, links quebrados, contradições acumuladas. Sistema de memória não cuida sozinho do próprio jardim.

• Equipes que não dominam observabilidade. Memória sem trace é debug impossível. Quando o agente “lembra errado” de algo, é preciso conseguir reconstruir o caminho — qual evento gerou qual nota, qual retrieval trouxe qual contexto, qual edição do agente alterou qual estado. Equipes sem essa cultura vão sofrer mais do que ganhar.

• Volume de uso que não justifica. Sistema de memória adiciona dependências (vector store, KG, possivelmente Neo4j ou Chroma), CI, testes, monitoring. Em produto pequeno com poucos usuários, esse custo de infraestrutura pode dominar.

• Quando o usuário não sabe o que o sistema sabe sobre ele. Isso não é falha técnica — é falha de UX e de consentimento que vai explodir como reclamação de suporte ou compliance later.

5. Custo computacional escondido

Os números de “ganho de tokens” e “redução de latência” comparam, em geral, agente com memória contra agente com janela cheia. Mas a operação da própria camada de memória tem custo que costuma ficar fora dessa comparação.

• Cada interação com memory layer costuma adicionar uma LLM call extra. Mem0 faz extract; A-MEM faz evolve; Letta faz self-edit; MemPalace decide drawer. Infra-LLM — LLM chamando LLM por baixo, com custo monetário e de latência.

• Em escala, multiplica custo por 2-5x facilmente. Um agente que faz 1 chamada por interação passa a fazer 2-5 se a memória ativa fizer extract no write, evolve em background e rerank no read.

• Latência sobe. Memory ops adicionam tipicamente 200-500ms por interação. Em UX síncrona (chat), é visível. Em backend batch, é absorvível.

• Comparações de “ganho de tokens” ignoram custo das operações de memória. Tokens para extrair um fato, sumarizar uma sessão e indexar embeddings, somados, costumam ser comparáveis aos tokens economizados na janela. Comparação honesta inclui os dois lados.

• Custo de embedding. Cada novo chunk ingerido precisa ser vetorizado. Em corpus grande com ingestão frequente, o custo de embedding (via API externa ou GPU própria) é linha de custo real que benchmarks de “tokens poupados” raramente medem.

6. “Context pollution”

A premissa intuitiva é: mais memória → melhores respostas. Na prática, memória mal curada pode produzir o oposto.

• Quando o retrieval traz contexto irrelevante, o LLM gasta atenção em distrações e degrada a resposta. Em casos extremos, contexto enganador leva a alucinação dirigida — o modelo segue uma pista falsa fornecida pelo próprio sistema de memória.

• O fenômeno lost-in-the-middle (ver 02 - O problema das janelas de contexto) continua aplicável dentro do retrieved context. Se o retrieval traz 10 chunks e o relevante está no meio, a atenção do modelo cai. Sistemas de memória que retornam top-k grandes sem reranking vão sofrer disso.

• Curadoria, lint, política de aposentadoria de notas e priorização de retrieval não são opcionais em sistemas de memória maduros. Sem isso, o sistema cresce até virar ruído.

• Memória desatualizada é pior que ausência de memória. Um fato correto há 12 meses pode ser diretamente falso hoje (endereço, cargo, versão de API). O sistema de memória precisa de timestamping e de política de decay — sem isso, o agente age com convicção sobre informação velha.

7. Inconsistência entre claims acadêmicos e produção

Papers mostram ganhos em benchmarks; produção tem custo, latência, observabilidade, governance. “Funciona em paper” ≠ “funciona em produção”.

• O caso Mem0g é exemplo claro. O paper original descreve graph store externo (Neo4j) com pipeline de extração de entidades e relações; o SDK atual usa entity linking embedded, mais leve, sem dependência externa. Não é necessariamente regressão — pode ser escolha de simplicidade — mas é divergência paper-vs-código que o adotante precisa conhecer. Quem cita o paper esperando o sistema do paper vai instalar uma coisa diferente.

• Generalizando: artigos descrevem sistemas idealizados; SDKs descrevem o que é mantenível. Adotar com base só no paper, sem ler o código atual, é receita para frustração.

• Reprodutibilidade dos números do paper é outro eixo. Quantos dos benchmarks publicados em papers de memória de agentes em 2026 têm scaffolding público que permite reexecutar? A resposta honesta é: poucos. LongMemEval é exceção, não regra.

8. Os 2 links descartados (relevantes só como exemplo de confusão de nome)

Esta seção referencia uma decisão tomada no MOC da trilha. Durante a pesquisa, dois links apareceram em buscas por “memória de agentes” / “Karpathy memory” e foram descartados:

• Mattbusel/srfm-lab — quant trading framework, não é sobre memória. Aparece em buscas por overlap de termos (alguns abstracts de quant lab usam “memory” no sentido de buffer de mercado).

• forrestchang/andrej-karpathy-skills — princípios de coding do Karpathy (Think Before Coding, Simplicity First, etc.). É um repositório útil em si, mas trata de estilo de programação, não de memória de agentes. Confusão por associação ao nome do Karpathy, que também é autor do gist do LLM Wiki Pattern.

Ambos servem como ilustração honesta de nome próximo ≠ tema próximo. Vale o registro porque, em pesquisa rápida, é fácil deslizar para qualquer um deles e perder tempo. Quem está montando trilha sobre o tema deve aprender o reflexo de abrir o README e checar a primeira frase antes de aceitar o link como referência.

9. Riscos éticos e de privacidade

Memória persistente sobre usuários levanta questões que o campo, em abril/2026, ainda discute pouco em público.

• Consentimento. Em UX típica, o usuário sabe que o agente “se lembra de coisas”? Foi avisado quais coisas? Pode revisar o que está armazenado? Em B2C, raramente. Em B2B com SaaS, depende muito do fornecedor.

• Retenção. Quanto tempo a memória sobre uma conversa fica viva? Há política de descarte? Em quais casos o sistema esquece automaticamente? Implementações sem forget policy clara estão construindo dívida regulatória.

• Right to be forgotten. GDPR, LGPD e regulamentações análogas garantem direito ao esquecimento. Sistema de memória que não tem operação de remoção endereçável (por usuário, por sessão, por chave de conteúdo) é compliance-incompatível por construção.

• Pouca discussão pública até abril/2026. O tema aparece em rodapés de papers e em posts esparsos, mas não há ainda corpus consolidado de boas práticas. É gap a ser preenchido pelo campo nos próximos ciclos.

• Casos de saúde/finance. Em domínios regulados, a regulamentação ainda está se ajustando ao que sistemas de memória de agentes implicam. Adotar nessas áreas sem revisão jurídica é risco organizacional, não só técnico.

Armadilhas comuns

Armadilha 1: Confiar em score sem verificação independente

Score auto-reportado em LongMemEval vale como hipótese, não como conclusão. Antes de citar ou adotar com base num número, verifique: (1) quem mediu — o próprio fornecedor ou terceiro?, (2) qual modelo base, qual versão do benchmark, qual modo (raw vs. hybrid)?, (3) há paper crítico ou análise externa que matize? Se a resposta a qualquer das três é desconhecida, cite com hedge. Sem isso, você amplifica sem verificar — posição fraca em qualquer audiência técnica.

Armadilha 2: Não testar no próprio workload

Score público em LongMemEval não prediz performance no corpus específico do seu projeto. Tipos de query, idioma, densidade de entidades, padrão de updates — tudo isso varia. A única forma de saber se um sistema funciona para você é medir no seu conjunto de dados, com métricas que capturam o que importa para o seu caso de uso. Adotar antes de testar é escolher o framework pela embalagem.

Armadilha 3: Subestimar o custo de manutenção e governança

Wiki/KG sem lint, sem revisão periódica e sem política de descarte apodrece em 6 meses. Notas órfãs acumulam, wikilinks quebram silenciosamente, contradições se cristalizam. O sistema de memória não cuida do próprio jardim — isso é trabalho humano ou de processo automatizado. Equipes que adotam achando que o sistema se mantém sozinho pagam esse custo mais tarde, com juros: debug de “por que o agente lembrou errado” é ordens de magnitude mais caro que lint preventivo.

Armadilha 4: Usar memória persistente em dados sensíveis sem política de privacidade

Memória persistente sobre conversas de usuários é acumulação de PII (Personally Identifiable Information). Sem forget policy explícita, sem operação de remoção endereçável por usuário, sem timestamping para expiração, você está construindo dívida regulatória silenciosamente. GDPR, LGPD e regulações análogas não são opcionais. Em domínios de saúde e finanças, a exposição é ainda maior.

Armadilha 5: Confundir "Karpathy-inspired" com endosso oficial

O gist de Karpathy é um documento público de 2023. Dezenas de projetos o usam como ponto de partida e se posicionam como “Karpathy-inspired” — o que é honesto. Mas algumas coberturas implicam endosso direto do Karpathy ao projeto específico. Esse gap entre inspiração e endosso é relevante em dois cenários: ao citar o projeto para audiências que conhecem Karpathy, e ao avaliar credibilidade técnica de um framework que “ele aprova”.

Armadilha 6: Adotar memória por FOMO em vez de necessidade

Se a tarefa não exige persistência cross-session — ou se RAG simples resolve — adicionar memória persistente é over-engineering. Antes de qualquer adoção, responda: “qual problema concreto memória persistente resolve que RAG não resolve?” Se a resposta for vaga, a necessidade não está clara o suficiente para justificar a complexidade.

Recap consolidado em formato de checklist para quem está revisando uma decisão de arquitetura ou um material público:

• Número auto-reportado sem verificação independente → cite com hedge
• Não testou no próprio workload → não adote ainda
• Sem lint periódico planejado → a wiki vai apodrecer
• Dados sensíveis sem forget policy → risco regulatório acumulando
• Cita “Karpathy-endossa” → ajuste para “Karpathy-inspirado”
• Adota por FOMO → pergunte “qual problema específico isso resolve?”
• Compara tokens sem incluir custo de memory ops → análise incompleta
• Latência de memory ops não modelada → SLA irreal em produção
• Sem estratégia de versão de memória → impossível rollback de estado corrompido
• Não planejou portabilidade (GDPR Art. 20) → dívida de exportação futura
• Não diferenciou benchmark de retrieval de benchmark de utilidade → decision-making baseado em métrica errada

Direito ao esquecimento por framework

A frase “implementamos GDPR” é vaga. O que importa é o mecanismo concreto. Em 2026, os frameworks da trilha oferecem:

Framework	Operação de remoção	Granularidade	Audit trail
basic-memory	Apagar/editar .md manualmente ou via MCP tool	Arquivo/entidade	Git history
Letta	memory_delete tool + operações via ADE	Bloco de core memory / entrada de archival	ADE log
Mem0	memory.delete(memory_id) + memory.delete_all(user_id)	Fato individual / usuário completo	Memory ops log
Zep	graph.edge.delete(group_id, uuid)	Edge individual no KG temporal	Timestamps no KG
MemPalace	Sem operação de delete documentada publicamente	Não endereçável externamente	Ausente

A coluna “granularidade” é a que importa para GDPR Art. 17 / LGPD Art. 18: o titular tem direito a apagar dados específicos, não apenas encerrar conta. Um framework sem delete granular por usuário não está operacionalmente pronto para dados regulados — independente do que o README afirma.

GDPR não é só consentimento

O erro mais comum em sistemas de memória é tratar GDPR como “pedir permissão para guardar dados”. O Art. 17 (direito ao esquecimento), Art. 20 (portabilidade), e Art. 22 (decisões automatizadas) criam obrigações que vão além do consentimento inicial. Memória acumulada sem mecanismo de portabilidade ou remoção granular é passivo legal, não feature.

Custo operacional oculto: o que os benchmarks não medem

LongMemEval mede qualidade de retrieval — a pergunta é respondida corretamente ou não. O que não aparece:

• Latência de memory.add: cada chamada pode adicionar 200-800ms ao turn se o pipeline de extração for síncrono.
• Custo de tokens de extração: em produção com 10k usuários fazendo 10 turns/dia, 2 LLM calls extras por turn = 200k chamadas/dia só para extração.
• Custo de busca vetorial em escala: memory.search com 100k fatos por usuário em alta concorrência não é gratuito — especialmente em cloud-managed vector stores.
• Custo de consolidação (sleep agents): frameworks como Letta que rodam consolidação assíncrona adicionam um segundo tier de custo que não aparece na análise de throughput normal.

Para qualquer adoção em produção, o TCO real inclui: (custo base de LLM) + (custo de memory ops) + (custo de infra de vector store) + (custo de manutenção/operação). Ignorar os últimos três itens é o erro mais comum em POCs que não sobrevivem à produção.

Como explicar em inglês

Interview quote

“Agent memory systems in 2026 show real technical progress, but benchmark scores are frequently self-reported, overfitted to LongMemEval, and don’t account for the hidden compute cost of memory operations themselves — so I always validate on my own workload before adopting.”

Português	Inglês
Auditoria honesta	Honest audit / Critical review
Hype vs realidade	Hype vs reality / Marketing claims vs engineering reality
Overfitting de benchmark	Benchmark overfitting
Custo computacional escondido	Hidden compute cost
Context pollution	Context pollution / Retrieval noise
Política de descarte	Forget policy / Retention policy
Score auto-reportado	Self-reported score
Viés de auto-publicação	Self-publication bias / Reporting bias
Direito ao esquecimento	Right to be forgotten
Memória desatualizada	Stale memory / Outdated context
Custo operacional total	Total cost of ownership (TCO)
Perda de informação por compressão	Information loss through compression
Latência de operação de memória	Memory operation latency

Como usar em entrevista

Quando perguntarem sobre memória de agentes, a postura de “auditoria honesta” é diferenciadora:

• “I find that most benchmark numbers in this space are self-reported on LongMemEval, which can be overfitted. So I look for third-party audits before trusting a score.”
• “The hidden cost is memory operations themselves — each interaction can add 2-5 extra LLM calls for extract, evolve, and rerank. The ‘tokens saved’ comparison often ignores this.”
• “Memory without a forget policy is regulatory debt. GDPR requires addressable deletion, and most open-source implementations don’t have that out of the box.”

O que vem a seguir

Esta nota encerrou a dimensão crítica da trilha — o contrapeso necessário para qualquer discurso público equilibrado sobre memória de agentes. Com o mapa completo de onde o campo avança e onde promete mais do que entrega, a próxima nota traduz tudo isso em ação prática: como efetivamente sair do zero e ter uma base de memória rodando no mesmo dia, com os dois caminhos concretos que a trilha revisou e os critérios para escolher entre eles. Conhecer as armadilhas desta nota antes de implementar é exatamente o que diferencia uma implementação que sobrevive seis meses de uma que apodrece em seis semanas. Veja 23 - Guia de implementação do zero.

Veja também

• 02 - O problema das janelas de contexto — context rot e lost-in-the-middle, base para entender context pollution
• 04 - RAG vs memória de longo prazo — quando RAG basta e o “bypass total” é exagero
• 06 - O LLM Wiki Pattern — pattern central da trilha, lido aqui com ressalvas
• 08 - Arquitetura de um sistema de memória — schema vs substrate
• 17 - MemPalace — caso central de hype-vs-rigor analisado em detalhe
• 20 - Surveys — onde os autores reconhecem limitações do campo
• 21 - Comparativo crítico — números rigorosos com hedge
• index — MOC com avisos sobre links descartados e segurança

Perguntas para usar em entrevista ou revisão técnica

Uma auditoria honesta termina com perguntas, não com respostas fechadas. Se precisar revisar um framework de memória que não conhece bem, estas questões expõem as lacunas mais comuns:

Estas perguntas funcionam tanto para revisar um framework novo quanto para revisitar decisões já tomadas. Tecnicamente, um sistema de memória maduro deve ter respostas prontas para todas elas — a ausência de resposta é o dado.

1. “O score de benchmark que você está citando foi medido por um terceiro independente, ou é self-reported pelo próprio vendor?”
2. “Qual é o custo de tokens de uma operação de memory.add ou equivalente? Isso foi contabilizado no TCO?”
3. “Como um usuário exerce o direito ao esquecimento neste sistema? Qual operação remove um fato específico e como verificar que foi removido?”
4. “O benchmark usado (LongMemEval, LOCOMO, outro) foi testado com os mesmos dados de treinamento usados para calibrar o sistema — ou há evidência de separação adequada de treino/teste?”
5. “Se a latência de memory search aumentar 3x ao escalar, o sistema ainda funciona dentro do SLA?”
6. “Qual é o plano de manutenção da base de memória quando ela começar a acumular fatos contraditórios ou desatualizados?”
7. “Qual é a estratégia de fallback se o vector store ou o grafo ficar indisponível — o sistema falha completamente ou degrada graciosamente?”
8. “Existe um teste de regressão automatizado que valida a qualidade do retrieval ao longo do tempo?”

Nenhuma dessas perguntas é hostil — são perguntas de engenharia de produção. Quem tem respostas preparadas entende o sistema; quem não tem, entende só o marketing.

O que o campo precisa para amadurecer

A análise crítica não termina em condenação — termina em diagnóstico de lacunas. O que falta para memória de agentes amadurecer como campo?

• Benchmarks independentes e diversificados. LongMemEval é referência, mas pode ser overfit. O campo precisa de pelo menos 2-3 benchmarks com diferentes tipos de memória testados (episódica, semântica, procedural), diferentes idiomas e diferentes estruturas de corpus. LoCoMo é um passo nessa direção, mas sem adoção ampla ainda.
• Reprodutibilidade sistemática. Código aberto, versão de modelo fixada, dataset público, seed fixada para runs determinísticas — a maioria dos papers revisados não atende a todos esses critérios. Isso impede acumulação de conhecimento verificável.
• Privacidade por design. O campo cresceu focado em performance e eficiência. Forget policy precisa ser cidadã de primeira classe na arquitetura, não add-on de compliance.
• TCO como métrica de primeira classe. Nenhum comparativo principal reporta custo por interação incluindo operações de memória. Um sistema que economiza 2.000 tokens de janela mas gasta 3.000 em operações de memória não é mais eficiente — é mais caro.

Referências

• Paper crítico MemPalace (2026): Spatial Metaphors for LLM Memory: A Critical Analysis of MemPalace. arXiv: https://arxiv.org/abs/2604.21284. Argumenta que o ganho de performance em hybrid mode vem de armazenamento verbatim + ChromaDB, não da hierarquia espacial.
• Análise externa lhl: https://github.com/lhl/agentic-memory/blob/main/ANALYSIS-mempalace.md. Audit de código e benchmarks. Encontra 20 MCP tools efetivamente implementadas (vs 29 anunciadas) e drop de 12,4 pp da AAAK em workloads adversariais.
• DEV.to (awrshift): I Over-Engineered Karpathy’s Agent Memory. Here’s What Actually Works. Análise prática que descreve o caminho até “100% em hybrid” como overfitting de benchmark na prática.
• Du et al. 2026 — survey: https://arxiv.org/abs/2603.07670. Limitações reconhecidas pelos próprios autores no campo: ausência de benchmarks padronizados além de LongMemEval/LoCoMo, divergência entre sistemas acadêmicos e SDKs de produção, custo computacional pouco endereçado na literatura.
• LongMemEval (Wu et al., ICLR 2025): https://github.com/xiaowu0162/LongMemEval. Benchmark de referência discutido em 21 - Comparativo crítico — relevante aqui pelo tópico de overfitting.
• Regulações de referência: GDPR Artigos 17 (direito ao esquecimento), 20 (portabilidade de dados) e 22 (decisões automatizadas) — https://gdpr-info.eu/art-17-gdpr/. LGPD Artigo 18 (direito dos titulares de dados pessoais) — Lei 13.709/2018. Ambos estabelecem obrigações operacionais concretas que frameworks de memória precisam satisfazer, não apenas declarar.
• LoCoMo benchmark (Facebook Research, 2024): https://arxiv.org/abs/2309.11235. Benchmark alternativo ao LongMemEval, foco em conversas longas (até 35 sessões, até 300 turnos). Usado em contextos onde LongMemEval é considerado estreito demais. Metodologia diferente implica números não diretamente comparáveis — ver 21 para detalhes.
• Survey Du et al. 2026: https://arxiv.org/abs/2603.07670. Towards Persistent Autonomous Agents: A Survey on Long-Term Memory in AI Systems. Um dos autores, ao reconhecer limitações do campo, cita explicitamente a ausência de benchmarks padronizados além de LongMemEval/LoCoMo como gap aberto — o survey não amplifica hype, é uma das referências mais equilibradas disponíveis.
• GDPR enforcement tracker: https://www.enforcementtracker.com/ — registra multas aplicadas, útil para calibrar o risco real de não-conformidade com direito ao esquecimento e outras obrigações que afetam sistemas de memória persistente.