Memória Universal Entre Agentes: O Contexto Que Segue Você do Claude Code ao Codex

Terça-feira de manhã, abri o Claude Code num repositório que eu tinha mexido no dia anterior com o Codex e gastei vinte minutos explicando de novo a mesma coisa: que aquele módulo não usa o ORM, que a convenção de nome de migration é diferente da do resto do projeto por um motivo histórico chato, que existe um teste de integração que só passa se o seed rodar antes. Nada disso é segredo, está tudo escrito em algum lugar. Só que "algum lugar" não é lugar nenhum quando o agente da vez não tem como chegar lá.

Foi a terceira vez no mês, e o incômodo não é o tempo — vinte minutos não quebram ninguém. É que eu estava fazendo transporte de estado na mão, entre dois processos, no meio de 2026. Quando é entre serviços, a gente chama isso de integração, monta um contrato e para de fazer manualmente. Entre agentes, ainda estou copiando e colando.

O Memmy, do repositório MemTensor/memmy-agent, é uma das tentativas mais diretas de resolver isso: um hub de memória local que propõe uma camada única compartilhada entre Cursor, Claude Code, Codex, OpenClaw e Hermes Agent, entre outros, disponível como app desktop, CLI e API. A ideia é simples de enunciar e nada simples de executar: que os agentes construam sobre o contexto uns dos outros em vez de cada um começar do zero. No mesmo período, o Mem0 publicou números de benchmark que colocam a discussão num patamar diferente.

Este post é sobre as duas metades disso. A primeira é a animadora, e vou tratá-la com o cuidado que os números merecem — inclusive apontando por que acurácia de benchmark de memória, sozinha, engana. A segunda quase ninguém discute: memória compartilhada entre agentes é estado mutável compartilhado, que sempre foi a parte mais difícil da engenharia de software.

---

Uma Camada, Vários Agentes: O Que O Memmy Está Propondo

O recorte do Memmy é bem escolhido. Ele não tenta ser o framework de memória do seu agente em produção; tenta ser o hub local entre você e as ferramentas de codificação que já usa. A lista de clientes que pretende cobrir — Cursor, Claude Code, Codex, OpenClaw, Hermes Agent — descreve com precisão a bagunça real da mesa de um dev sênior hoje.

Essa bagunça não é acidente de mercado. Cada uma dessas ferramentas resolveu memória para dentro: Claude Code tem o arquivo de instruções do projeto, Cursor tem as regras dele, Codex tem o dele. Formatos, escopos e ciclos de vida diferentes, e nenhum desenhado supondo que existiria outro agente lendo o mesmo repositório na mesma semana. O resultado é o contexto do projeto fragmentado em três ou quatro arquivos que dizem quase a mesma coisa com palavras diferentes, todos ligeiramente desatualizados em relação ao código.

Um hub muda a topologia disso de estrela para barramento: em vez de cada agente manter a própria cópia, existe um lugar onde a informação é escrita e de onde todos leem. É a mesma jogada que fazemos quando três serviços começam a manter cópias divergentes do mesmo cadastro. Funciona — e é exatamente no momento em que funciona que os problemas interessantes começam, porque cópia divergente é um problema chato e barulhento, enquanto fonte única errada é um problema silencioso.

O detalhe mais acertado da proposta é o hub ser local. Memória de trabalho de um dev é a coisa mais sensível que passa por uma ferramenta de IA: nomes internos de sistema, decisões de arquitetura não publicadas, o motivo real pelo qual aquele workaround existe. Mandar isso para um serviço gerenciado de terceiro é uma decisão que a maioria dos times toma sem perceber; rodar na própria máquina deixa a decisão explícita.

---

Memória Não É Cache, E É Aí Que A Maioria Erra O Desenho

A palavra "memória" faz um estrago nessa conversa, porque sugere armazenamento e o problema não é de armazenamento. Guardar tudo que foi dito é trivial e não resolve nada — é o que a janela de contexto já faz. Memória, no sentido útil, é o conjunto de decisões sobre o que extrair de uma interação, como consolidar com o que já existe, o que promover a fato durável, o que deixar expirar e o que trazer de volta na hora certa.

Já escrevi sobre arquitetura de memória de agentes em produção e a parte que continua valendo é a separação entre os tipos: episódica, que registra o que aconteceu numa sessão; semântica, que guarda fatos estáveis sobre o usuário e o projeto; e procedural, que retém como uma tarefa é feita neste contexto. Ferramentas que tratam os três como um balde só de embeddings entregam bem a busca por similaridade e mal todo o resto, porque as três têm políticas de escrita, atualização e esquecimento diferentes.

O Mem0 é a referência mais visível da categoria, e a maturidade dele aparece menos nos números e mais na superfície: a documentação oficial de integrações cobre 21 frameworks e plataformas, em Python e TypeScript. Isso é chato de construir e é o sinal mais honesto de que um projeto saiu da fase de demonstração.

Também vale distinguir memória de recuperação, porque as duas se confundem o tempo todo. Recuperação busca num corpus que alguém já escreveu; memória escreve o corpus. É diferença de responsabilidade, não de tecnologia — os dois podem usar o mesmo banco vetorial. Discuti a fronteira vizinha em RAG ou janela de contexto longa, e o que se transfere para cá é que a pergunta certa nunca é qual mecanismo é melhor, e sim quem é o dono da escrita. Em RAG, é uma pipeline que você controla. Em memória de agente, é o próprio agente. Guarde essa frase, porque metade deste post depende dela.

---

Acurácia Sozinha Engana: O Número Só Vale Em Par Com O Custo

Os números de 2026 do Mem0 são bons e merecem ser lidos com atenção ao que está ao lado deles: 92,5 no LoCoMo e 94,4 no LongMemEval, com cerca de 6.900 tokens por consulta. Os ganhos maiores aparecem onde memória deveria fazer diferença — raciocínio temporal, com 29,6 pontos a mais, e multi-hop, com 23,1. Faz sentido mecanicamente: as duas categorias exigem relacionar informações que apareceram em momentos distintos, que é o que uma janela de contexto plana faz mal.

O contraste que me interessa mais vem do resultado anterior, publicado no ECAI 2025. Ali o Mem0 registrou 66,9% no LoCoMo, com latência mediana de 0,71s e cerca de 1.800 tokens por conversa, enquanto a inferência com contexto completo chegava a 72,9% — seis pontos acima — com 9,87s de latência mediana e cerca de 26 mil tokens por consulta. Seis pontos custando uma ordem de grandeza em tokens e quase catorze vezes em latência.

Abordagem	Acurácia LoCoMo	Latência mediana	Custo em tokens
Mem0 (ECAI 2025)	66,9%	0,71s	~1.800 por conversa
Contexto completo (mesmo estudo)	72,9%	9,87s	~26.000 por consulta
Mem0 (resultados 2026)	92,5	—	~6.900 por consulta

Um aviso sobre essa tabela, que é parte do argumento e não nota de rodapé: as unidades da terceira coluna não são as mesmas. "Por conversa" e "por consulta" medem coisas diferentes, e o número de 2026 não é comparável ao de 2025 numa subtração simples. Deixei assim de propósito, porque é assim que esses números circulam. Num gráfico de barras num slide, essa incompatibilidade some e a comparação vira ficção com aparência de rigor.

A lição metodológica é a que eu queria que ficasse deste post, se for para ficar uma só. Número de benchmark de memória não significa nada sozinho. Um sistema que carrega tudo para dentro do prompt sempre vai ter teto de acurácia mais alto, porque nada foi descartado. A pergunta que decide arquitetura não é "quanto ele acerta", é "quanto ele acerta por token e por milissegundo". Um sistema com 92,5 e 6.900 tokens e outro com 94 e 40 mil não estão na mesma conversa, mesmo que a barrinha do segundo seja mais alta. Se o fornecedor mostra acurácia e não mostra tokens, o número que falta é o que interessa.

---

Write-Time Ou Read-Time: Onde Você Escolhe Pagar A Conta

Tem um detalhe nos dados do Mem0 que explica boa parte do desenho: a latência mediana se mantém praticamente estável, com aumento de 1 milissegundo, mesmo com ranqueamento por recência e raciocínio temporal ligados. Não é otimização mágica, é escolha de onde o trabalho acontece. As duas coisas rodam no momento da escrita, não no da leitura.

É a decisão arquitetural mais consequente de todo sistema de memória, e tem a forma de um dilema que você já resolveu dezenas de vezes: índice na escrita ou varredura na leitura, materializar a view ou calcular no SELECT. Toda vez que você move custo para o write path, a leitura fica barata e previsível, e você paga com complexidade de escrita, dado que envelhece e dificuldade de mudar de ideia depois — porque mudar a política de extração exige reprocessar o que já foi escrito.

O caminho oposto é legítimo: guardar tudo cru e resolver na leitura mantém a escrita trivial e preserva a possibilidade de reinterpretar o histórico depois. O preço aparece na latência e no custo por token, em cada interação — proibitivo para um agente de codificação num loop apertado, aceitável para um sistema que roda uma vez por dia.

O que me parece mal compreendido é quanto a escolha de write-time custa em reversibilidade. Quando você decide na escrita o que vira memória, está aplicando um julgamento — quase sempre de um modelo, com um prompt de extração que alguém escreveu numa tarde — sobre informação que ainda não sabe para que vai servir. O que foi descartado não volta. Se o prompt tinha um viés, ele está congelado dentro do acervo, e nenhuma melhoria futura na leitura corrige isso, porque não sobrou bruto para reprocessar.

Na prática, o desenho que serve à maioria dos times é híbrido: extração agressiva na escrita para o que é claramente durável — preferências declaradas, decisões registradas, convenções de projeto —, retenção do bruto por uma janela curta para o resto. O que não faz sentido é adotar uma camada de memória sem saber de que lado dessa linha ela está. Ao avaliar uma ferramenta, a pergunta não é quais modelos ela suporta. É: o que acontece no momento em que escrevo, e o que sobra do bruto depois disso.

---

Contaminação De Contexto: Quando A Conclusão Errada Vira Fato Compartilhado

Aqui começa a metade do post que motivou escrevê-lo. Todo o raciocínio acima trata memória como problema de eficiência. Ela deixa de ser isso no instante em que passa a ser compartilhada por vários agentes, porque aí vira estado mutável compartilhado — e sabemos há décadas que essa é a parte mais difícil da engenharia. Não por ser difícil de implementar, por ser difícil de raciocinar sobre.

O cenário concreto é banal e é o que me preocupa. Um agente investiga um bug de performance, conclui que a lentidão vem de uma query N+1 e escreve isso na memória compartilhada. A conclusão está errada — o gargalo real é um lock em outra tabela, que só aparece sob concorrência. Três outros agentes leem o registro e nenhum tem contexto para duvidar dele. Um otimiza a query, mede melhora marginal e escreve que a otimização foi aplicada, reforçando a premissa. O terceiro parte da premissa reforçada e desenha uma mudança de schema em cima dela.

Repare no que aconteceu: um erro virou fato compartilhado e depois virou fato compartilhado com evidência de corroboração. Não houve má-fé, bug nem injeção — o sistema funcionou como projetado. O problema é que a propriedade que exigimos de qualquer fonte de verdade, saber de onde veio cada afirmação e com que grau de confiança, não é padrão em nenhuma camada de memória que eu vi até hoje.

Com um agente só, isso se corrige sozinho quase sempre, porque a próxima interação traz evidência nova e o modelo revisa. Com quatro agentes lendo o mesmo acervo, a conclusão errada tem quatro chances de ser reforçada a cada uma de ser corrigida, e o registro corrigido convive com o errado sem que nada indique qual é o mais recente. Acúmulo de erro com realimentação positiva e sem amortecimento.

O que isso pede é o que exigiríamos de qualquer sistema com escritores concorrentes: proveniência por registro, dizendo qual agente escreveu e quando; distinção explícita entre observação e conclusão; e algum decaimento, porque conclusão sem confirmação deveria perder força em vez de virar patrimônio. Nada disso é exótico. Só que sistemas de memória são vendidos por acurácia de recuperação, e ninguém está sendo cobrado por essas propriedades.

---

Memória Persistente É Um Canal De Injeção Que Sobrevive À Sessão

O segundo problema é de segurança, e muda a natureza de um risco que já conhecíamos. Injeção de prompt, na forma clássica, é um ataque com validade de uma sessão: conteúdo malicioso entra no contexto, influencia o comportamento do agente naquela execução e some quando o contexto é descartado. É ruim, mas tem limite natural de dano.

Memória persistente remove esse limite. Se um conteúdo consegue ser gravado no acervo — via README de dependência, comentário num issue, resultado de busca, arquivo num repositório de terceiro —, ele não some no fim da sessão. Vira contexto recuperável, disponível para todos os agentes daquela camada, potencialmente por meses, e apresentado ao modelo com o mesmo status de qualquer outra memória: como algo que o sistema sabe.

Isso interage de forma feia com o problema que descrevi em os agentes mais úteis são os mais perigosos. A combinação de acesso a dado sensível, exposição a conteúdo não confiável e capacidade de comunicação externa já é a receita conhecida. Memória compartilhada dá persistência ao ingrediente do meio e amplia o alcance dos outros dois, porque um conteúdo injetado num agente com pouco privilégio passa a ser lido por um agente com muito.

Vale ser preciso, porque alarmismo aqui não ajuda. Não estou dizendo que memória compartilhada é insegura por natureza. Estou dizendo que ela move a fronteira de confiança, e que a maioria dos desenhos que vi ainda trata o acervo como dado interno confiável — o que ele não é, já que boa parte do que entra ali deriva de conteúdo que o agente leu no mundo. Perder essa marcação no caminho é o erro de desenho, não a persistência em si.

O mínimo defensável é tratar escrita em memória como operação privilegiada e não como efeito colateral de leitura: separar o que veio de fonte interna do que veio de fonte externa, e exigir um ponto de promoção antes que memória de origem não confiável valha como fato. É a disciplina que aplicamos a input de usuário desde sempre — só que aqui o input chega com aparência de conhecimento consolidado.

---

A Pergunta Sem Resposta: O Que Esse Agente Lembra De Mim

O terceiro problema é o que menos aparece nas discussões técnicas e o que mais vai aparecer nas conversas de compliance nos próximos meses. A pergunta é simples: o que exatamente esse agente lembra de mim, e quem escreveu isso lá.

Tente responder para o seu setup atual. Eu tentei e não consegui. Não tenho listagem legível do que está armazenado, não tenho carimbo de origem em cada registro, não sei quanto daquilo veio de uma conclusão de modelo em vez de uma afirmação minha, e não tenho como apagar seletivamente. O que tenho é zerar tudo, o equivalente a resolver dado incorreto num banco com DROP DATABASE. Funciona. Não é auditoria.

Isso é mais grave do que parece porque não é só desconforto de engenheiro. Se a camada guarda qualquer coisa que se qualifique como dado pessoal — e guarda, porque preferência de trabalho e histórico de decisão de uma pessoa identificável são exatamente isso —, direitos de acesso, correção e eliminação se aplicam. Não dá para atender a um pedido de correção num acervo em que você não consegue localizar o registro nem saber quem o escreveu. É o mesmo vazio que descrevi em a lacuna de governança de agentes em produção, só que agora com dado que persiste e se propaga entre ferramentas em vez de morrer no fim da chamada.

O incômodo prático é mais mundano e talvez por isso mais convincente. Quando um agente me dá uma resposta estranha hoje, consigo olhar o contexto da sessão e entender de onde veio. Com memória persistente compartilhada, ela pode ter origem numa gravação feita por outro agente, três semanas atrás, a partir de uma conversa que eu nem lembro de ter tido. A cadeia causal fica longa demais para caber na cabeça e não existe ferramenta apontando para trás. Perder a capacidade de explicar por que o sistema fez o que fez é caro, e é uma perda que acontece devagar, sem incidente que marque a data.

---

O Que Eu Ligaria Primeiro Se Fosse Adotar Hoje

Nada disso é argumento para não usar. O problema que o Memmy ataca é real, eu o sinto três vezes por mês, e a fragmentação atual do contexto entre ferramentas é insustentável. A questão é a ordem: decidir o que você precisa conseguir observar antes de decidir o que vai construir.

Começaria por escopo, porque é a decisão mais barata de acertar e a mais cara de corrigir depois. Memória por projeto, não global. A tentação do acervo único que segue você por tudo é justamente o que cria a superfície de contaminação e de vazamento entre contextos que não deveriam se conhecer. O contexto do cliente A não tem razão para estar disponível quando você abre o repositório do cliente B, e a versão global do sistema não tem como saber disso.

Depois, exigiria proveniência antes de acurácia. Antes de perguntar quanto o sistema acerta, perguntaria se consigo listar o que ele guardou, ver quem escreveu cada item e quando, distinguir o que eu afirmei do que um modelo concluiu, e apagar item por item. Se a resposta a qualquer uma dessas for não, a ferramenta pode ser ótima e ainda assim não estar pronta para carregar contexto de trabalho de verdade.

E manteria a escrita explícita pelo máximo de tempo possível. Isso vai contra o apelo inteiro da categoria, que é a memória automática, invisível, sem esforço. Mas a diferença entre um acervo em que eu decidi o que entra e um que se encheu sozinho durante seis meses é a diferença entre uma base de conhecimento e um sedimento — e o segundo é muito mais difícil de confiar.

---

Conclusão

O que mais me chamou atenção juntando o material deste post foi o descompasso entre as duas metades. A de eficiência está madura: existem benchmarks, metodologia publicada, números de token e de latência ao lado dos de acurácia. Dá para comparar opções e defender uma escolha com dado. A metade de correção e segurança não tem nada disso. Não existe benchmark de contaminação de memória, não existe métrica publicada de proveniência, e a pergunta "o que esse agente lembra de mim" ainda não tem resposta operacional em praticamente nenhuma ferramenta do mercado.

Também saio com a impressão de que estamos repetindo um ciclo já vivido. Estado mutável compartilhado entre processos concorrentes foi o problema que produziu transações, isolamento, versionamento e todo o vocabulário de consistência que a gente usa sem pensar. Estamos reintroduzindo o mesmo problema numa camada nova, com escritores que erram de formas correlacionadas e plausíveis — bem pior do que errar de forma aleatória — e sem nenhuma das garantias que levamos quarenta anos para construir. Não estou dizendo que precisamos de ACID para memória de agente. Estou dizendo que hoje temos aproximadamente zero, e zero não é ponto de chegada.

A parte honesta é que não tenho resposta fechada para o meu próprio caso. Vou continuar perdendo vinte minutos por semana reexplicando convenção para agente, e sei que isso não é defensável. Provavelmente vou ligar uma camada dessas em algum projeto nos próximos meses, começando por um só, escopado, com escrita manual, e observar o acervo ao longo de um trimestre — porque suspeito que o problema real dessa categoria não apareça na semana um, e sim no mês seis, quando o acervo já é grande demais para ser lido inteiro e ninguém lembra do que entrou lá. Se eu estiver certo, o número que vai importar não é nenhum dos que estão nos benchmarks de hoje.

Fontes:

• Memmy — GitHub
• Mem0 — State of AI Agent Memory 2026
• Mem0 — AI Memory Benchmarks 2026: LoCoMo, LongMemEval & BEAM
• arXiv — Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
• Graphlit — AI Agent Memory Frameworks in 2026: Memory vs. Context