Mem0

TL;DR

Mem0 (github.com/mem0ai/mem0) é um framework de produção que se posiciona como “universal memory layer for AI agents”: uma camada drop-in que extrai fatos salientes de conversas via LLM e os persiste em vector store (variante base) ou em uma combinação de vetor com grafo (variante Mem0g descrita no paper original). O paper de fundação (arxiv 2504.19413, ECAI 2025) reporta 91% de redução em p95 latency e mais de 90% de economia de tokens versus baselines full-context na avaliação LOCOMO. O blog oficial State of AI Agent Memory 2026 (1º de abril de 2026) e a página de pesquisa (mem0.ai/research) reportavam 93,4% no LongMemEval em abril de 2026 — número auto-reportado, a ser validado por benchmark independente. Atualização de julho/2026: o repositório (verificado em github.com/mem0ai/mem0, julho/2026) já reporta 94,8% no LongMemEval e 91,6 no LoCoMo, atribuídos a uma nova versão do algoritmo (“single-pass ADD-only extraction” — uma única chamada de LLM por add, sem operações separadas de UPDATE/DELETE) — os números seguem auto-reportados. Cobertura ampla de integrações: ~24 frameworks listados em docs.mem0.ai/integrations (LangChain, LangGraph, CrewAI, LlamaIndex, AutoGen, Vercel AI SDK, OpenAI Agents SDK, Google ADK, Mastra, Agno, Pipecat, ElevenLabs, Livekit e outros — contagem estável entre abril e julho de 2026). Apache-2.0, Python + TypeScript SDK, self-host gratuito, cloud paga em modelo freemium.

Dúvidas e lacunas desta nota

Dúvida gerada pelo conteúdo: Se o pipeline de extração de “fatos salientes” é opaco e controlado por um LLM interno, como auditar o que foi descartado como “não saliente”? Existe algum modo de debug ou log de extração acessível no SDK open-source?

Lacuna potencial: A nota não detalha como o entity linking embutido (que substituiu o graph store externo no SDK open-source) funciona internamente — entender esse mecanismo é crucial para avaliar se Mem0g do paper e Mem0 atual são realmente equivalentes em raciocínio multi-hop.

O que é

Imagine um agent de suporte que conversa com o mesmo usuário há dez sessões. Na 11ª, o histórico completo não cabe mais na janela de contexto — e a estratégia mais comum, truncar as mensagens mais antigas, apaga justamente a instrução que o usuário deu na sessão 2 (“nunca me sugira o plano X, já cancelei duas vezes”). O agent repete o erro, o usuário se irrita, e o time de produto só descobre o problema quando o ticket de reclamação chega. Esse é o sintoma que o mem0 ataca: não é falta de memória de curto prazo dentro de uma conversa, é a ausência de um lugar fora da janela onde fatos estáveis sobrevivam ao truncamento.

mem0 é um framework para memória persistente de agentes mantido pela Mem0 AI. O paper de fundação — Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory (Chhikara, Khant, Aryan, Singh, Yadav; arxiv 2504.19413, ECAI 2025) — apresenta o sistema como resposta ao problema das janelas de contexto fixas (ver 02 - O problema das janelas de contexto) e às limitações de RAG simples para conversas longas (ver 04 - RAG vs memória de longo prazo e 05 - Beyond RAG - quando RAG não basta).

O posicionamento canônico é o de memory layer universal: em vez de propor um framework de agent novo, Mem0 funciona como camada de memória que se acopla a qualquer LLM e a qualquer framework existente. A API central é minimalista — memory.add(messages, user_id) e memory.search(query, user_id) — e abstrai extração, armazenamento e recuperação por trás dessas duas operações. O paper apresenta duas variantes:

Base Mem0 — armazenamento puramente vetorial dos fatos extraídos.
Mem0g — variante enriquecida com representação em grafo (entidades + relações labeled), que reporta cerca de 2 pontos percentuais a mais que a base no LOCOMO (68,4% vs 66,9% LLM-as-judge accuracy).

Mem0g no paper vs grafo no SDK open-source

O paper de 2025 descreve Mem0g como variante com grafo (entidades + relações em store externo como Neo4j, Memgraph, Kùzu, Apache AGE ou Neptune). A documentação atual de docs.mem0.ai indica que o suporte a graph store externo foi removido do SDK open-source em release recente do “novo algoritmo de memória” e substituído por entity linking embutido, que extrai entidades durante o add e armazena em coleção paralela no próprio vector store. Antes de afirmar “Mem0g com Neo4j” em 2026, verifique a versão do SDK que se está usando — paper e código divergiram nesse ponto.

Por que importa

Talvez o framework de memória open-source mais comercialmente maduro em 2026. Repositório com mais de 54 mil estrelas em abril de 2026, 60,3 mil em julho de 2026 (verificado em github.com/mem0ai/mem0), paper peer-review-quality (ECAI 2025), empresa por trás do projeto (Mem0 AI), pricing público estabelecido, SDKs Python e TypeScript estáveis. É a opção de referência para times que querem memória de produção sem construir do zero.
Memory layer simplifica integração. Não força reescrever o agent: acopla-se a um LangGraph existente, a um CrewAI, a um Vercel AI SDK chatbot, e ganha persistência sem reorganizar o código de orquestração. Diferente de Letta, que é um framework de agent stateful por inteiro, Mem0 é estritamente layer.
A variante grafo destrava raciocínio multi-hop. No paper, Mem0g supera a variante base em queries que exigem composição de múltiplos fatos (entidades + relações), no espírito do que Graphiti também propõem. O ganho não é gigantesco no LOCOMO (~2 pontos), mas é consistente.
Score no LongMemEval (auto-reportado) é dos mais altos do mercado — e subiu ao longo de 2026. 93,4% em abril, 94,8% em julho (após a atualização do algoritmo de extração), aparece no blog oficial State of AI Agent Memory 2026, na página de pesquisa e no próprio repositório, sempre com o caveat de score auto-reportado por vendor (ver 21 - Comparativo crítico e 22 - Críticas, limitações e armadilhas).
Cobertura de integrações é o ponto comercial mais forte. A página docs.mem0.ai/integrations lista ~24 frameworks de agentes — abrangência rara entre frameworks de memória.

Como funciona

graph LR
    AGT[Agent / app] -->|memory.add| M0[Mem0 Layer]
    M0 -->|extract salient| EXT[LLM extraction]
    EXT --> VEC[Vector store]
    EXT --> GR[Graph store / entity linking<br/>Mem0g ou built-in]
    AGT -->|memory.search| M0
    M0 --> VEC
    M0 --> GR

O fluxo central é deliberadamente simples e tem duas operações principais:

memory.add(messages, user_id) — recebe uma lista de mensagens (ou um turno de conversa) e um identificador de usuário/sessão. Internamente, o Mem0 invoca um LLM (configurável: OpenAI, Anthropic, Ollama local, Azure, Bedrock, Groq e outros) que extrai fatos salientes das mensagens — afirmações estáveis sobre o usuário, sobre o domínio, sobre o que foi decidido. Esses fatos são gravados no vector store configurado (Qdrant, Pinecone, Chroma, Weaviate, PGVector, Redis, Milvus, Elasticsearch, OpenSearch, Supabase, FAISS e outros). Quando entity linking está ativo (ou na variante Mem0g do paper, com graph store externo), entidades extraídas e suas relações também são gravadas.
memory.search(query, user_id) — recebe uma query e o identificador de usuário, e retorna a lista de fatos relevantes ranqueados, no estilo RAG. O agent injeta o resultado no prompt como contexto e responde.

A propriedade-chave do design é que o agent não precisa decidir o que armazenar. Diferente de Letta, que expõe core_memory_append e archival_memory_insert como tools que o agent invoca por conta própria, no Mem0 a decisão é delegada a um pipeline de extração rodando no add — invisível ao agent. Isso é simultaneamente uma vantagem (menos cognitive load no LLM principal, menos tokens gastos em decisões de memória) e uma desvantagem (a heurística de extração é parcialmente opaca, e cada add custa pelo menos uma chamada de LLM extra).

Exemplo concreto: chatbot de saúde pessoal

Imagine um chatbot de acompanhamento de saúde que conversa com o usuário semanalmente. Sem Mem0, o agent não lembraria de uma consulta anterior. Com Mem0:

from mem0 import Memory
 
m = Memory()
 
# Sessão 1 — usuário relata metas
messages = [
    {"role": "user", "content": "Comecei uma dieta sem glúten há duas semanas."},
    {"role": "assistant", "content": "Ótimo! Como está sendo a adaptação?"},
    {"role": "user", "content": "Bem, mas sinto falta de pão. Minha meta é perder 5kg em 3 meses."}
]
m.add(messages, user_id="usuario_joao")
 
# Sessão 2 — semana seguinte, o agent busca contexto antes de responder
memories = m.search("dieta e metas de saúde", user_id="usuario_joao")
# Retorna: ["dieta sem glúten há 2 semanas", "meta: perder 5kg em 3 meses"]

O agente recebe os fatos recuperados no prompt, responde com continuidade e não precisa perguntar “pode me lembrar de onde paramos?“. O usuário sente que o sistema realmente o conhece.

Uso incorreto: `memory.search` sem isolar por `user_id`

E se o time, sob pressão de prazo, esquecer de passar user_id na busca? O SDK não obriga o parâmetro em toda chamada — e o erro compila, roda, e só aparece em produção:

# ERRADO — busca sem filtrar por usuário
memories = m.search("dieta e metas de saúde")
# Sem user_id, a busca pode varrer (ou, dependendo da config do
# vector store, misturar) memórias de OUTROS usuários que também
# mencionaram "dieta" — vazamento de dado pessoal de saúde entre contas.
 
# CERTO — sempre escopar a busca (e o add) pelo usuário/sessão
memories = m.search("dieta e metas de saúde", user_id="usuario_joao")

A consequência não é um crash — é silenciosa: o agent responde com um fato de saúde de outro usuário, e ninguém percebe até uma auditoria ou uma reclamação de privacidade. O mesmo descuido em memory.add tem um custo diferente: cada chamada dispara ao menos uma invocação extra de LLM para extrair fatos (ver Armadilha 2, abaixo); rodar add em alto volume sem medir esse custo de extração — por exemplo, chamando add a cada mensagem de um chat com milhares de usuários simultâneos — infla a fatura de tokens sem que o benchmark de latência de retrieval do vendor jamais capture esse gasto.

Fluxo de extração de fatos

O passo interno mais crítico é o de extração: o LLM de extração (que pode ser diferente do LLM de resposta) recebe o texto cru da conversa e produz afirmações atômicas, como:

“João segue dieta sem glúten”
“Meta de João: perder 5 kg em 3 meses”
“João sente falta de pão”

Essas afirmações são embedadas e gravadas no vector store. Na busca, a query do agent é comparada semanticamente com essas afirmações por similaridade de coseno, e as mais próximas são retornadas — RAG clássico, mas sobre fatos extraídos, não sobre chunks crus de texto.

sequenceDiagram
    participant A as Agent
    participant M as Mem0 Layer
    participant LLM_E as LLM de Extração
    participant VS as Vector Store

    A->>M: memory.add(messages, user_id)
    M->>LLM_E: "Extraia fatos salientes dessas mensagens"
    LLM_E-->>M: ["fato 1", "fato 2", "fato 3"]
    M->>VS: embed + store fatos
    VS-->>M: confirmação

    A->>M: memory.search("dieta e metas", user_id)
    M->>VS: query embedding → similaridade
    VS-->>M: fatos relevantes ranqueados
    M-->>A: lista de fatos para injetar no prompt

Anatomia técnica

Os itens abaixo foram verificados em github.com/mem0ai/mem0, docs.mem0.ai e mem0.ai em abril de 2026. Algumas configurações suportadas em Python ainda não estão disponíveis no SDK TypeScript — quando relevante, indica-se a divergência.

Linguagens / SDKs: Python (pip install mem0ai) e TypeScript/JavaScript (npm install mem0ai). CLI disponível em ambos. O repositório é majoritariamente Python (~56%) com TypeScript (~35%).
Licença: Apache-2.0.
LLMs suportados (16, em Python): OpenAI, Anthropic, Azure OpenAI, Google AI, AWS Bedrock, Mistral AI, DeepSeek, Together, Groq, xAI, MiniMax, Sarvam AI, Ollama, LM Studio, LiteLLM e Langchain como provider. No SDK TypeScript, atualmente apenas OpenAI, Anthropic e Groq.
Vector stores suportados (~20, em Python): Qdrant, Chroma, Pinecone, Weaviate, Milvus, FAISS, PGVector, Redis, Valkey, Elasticsearch, OpenSearch, Supabase, MongoDB, Azure AI Search, Vertex AI, Upstash Vector, Amazon S3 Vectors, Databricks, Turbopuffer e Langchain. No SDK TypeScript, suporte mais restrito (Qdrant, Redis, Valkey, Cloudflare Vectorize e in-memory).
Graph store / entity linking: o paper Mem0g descreve uso de graph stores externos (Neo4j, Memgraph, Kùzu, Apache AGE, Neptune). A documentação atual sinaliza que o suporte a graph store externo foi removido do SDK open-source em release recente, substituído por entity linking embutido no vector store. Verifique a versão antes de assumir Neo4j em produção.
Variantes (paper): Base Mem0 (vetorial puro, 66,9% LLM-as-judge no LOCOMO) e Mem0g (vetorial + grafo, 68,4% LLM-as-judge no LOCOMO).
Integrações de framework (~24 listadas em docs.mem0.ai/integrations): LangChain, LangGraph, LangChain Tools, LlamaIndex, CrewAI, AutoGen, Vercel AI SDK, OpenAI Agents SDK, Google ADK, Mastra, Agno, Pipecat, Camel AI, ChatDev, ElevenLabs, Livekit, Dify, Flowise, Raycast, AgentOps, Keywords AI, AWS Bedrock, Mem0 MCP e outras. Não afirmar “21 integrações” sem reverificar — a lista cresceu desde o paper original.
API: REST (cloud), Python SDK, TypeScript SDK, self-hosted server.
Pricing (em mem0.ai/pricing, verificado em julho/2026): Free gratuito (10k add / 1k search por mês); Starter US $19/ m \overset{e}{^} s (50 ka dd /5 k se a rc h); * * n o v o t i er * G ro wt h * U S$ 79/mês (200k add / 20k search, 3 projetos, suporte por e-mail)** — não existia na checagem de abril/2026; Pro US$ 249/mês (500k add / 50k search, analytics avançado, projetos ilimitados); Enterprise sob consulta (on-prem, SSO, audit logs, usage-based pricing). Self-host open-source é gratuito sempre — paga-se apenas pelo cloud gerenciado.
Scores reportados (auto-reportados por Mem0, em mem0.ai/research, 25 de abril de 2026): LongMemEval 93,4 (categoria geral 92,0, em 500 questões / 6 categorias); LOCOMO 91,6 (overall 85,0); BEAM 64,1 em 1M tokens e 48,6 em 10M tokens; “averaging under 7,000 tokens per retrieval call” vs 25 mil+ em métodos full-context. Atualização (verificada em github.com/mem0ai/mem0, julho/2026): com o novo algoritmo de extração single-pass ADD-only (uma chamada de LLM por add, sem UPDATE/DELETE separados), o repositório já reporta LongMemEval 94,8 e LoCoMo 91,6 — a mudança de algoritmo é relevante porque a seção “Pipeline de extração em detalhe” desta nota descreve o modelo de eventos ADD/UPDATE/DELETE/NONE; times que atualizarem o SDK devem checar o changelog para confirmar se esse modelo de eventos ainda se aplica à versão instalada.
Claims de eficiência do paper (arxiv 2504.19413): 91% lower p95 latency vs full-context, +90% economia de tokens vs full-context, e 26% de melhora relativa sobre OpenAI Memory na métrica LLM-as-judge.

Comparativo de posicionamento: Mem0 vs Letta

Dimensão	Mem0	Letta
Papel	Memory layer (drop-in)	Agent framework completo
Quem decide o que armazenar	Pipeline de extração (LLM interno)	O próprio agent (via tools)
Curva de integração	Baixa (2 métodos de API)	Alta (requer migrar para o agent loop do Letta)
Transparência do mecanismo	Parcialmente opaca	Totalmente explícita (ADE)
Benchmark público	LongMemEval 93,4% (auto-reportado)	Não publicado
Licença	Apache-2.0	Apache-2.0
Substrato de persistência	Vector store (+ entity linking)	PostgreSQL + pgvector

Quando usar / quando não usar

Quando vale:

Time quer memory layer drop-in sem reescrever o agent existente (LangChain, LangGraph, CrewAI, Vercel AI SDK).
Caso requer integração com framework já em produção — a cobertura de integrações é o ponto comercial mais forte.
Cenário mistura busca factual (RAG-like) com memória episódica de usuário — exatamente o sweet spot de Mem0.
Há tolerância a dependência de cloud (Mem0 Cloud) OU o time tem maturidade para self-host com infra de vector store (Qdrant, Pinecone, etc.).
Se o ganho de multi-hop com grafo importa, e há infra para a variante Mem0g do paper (com a ressalva acima sobre o estado atual do graph store externo no SDK).

Quando NÃO vale:

Cenário local-first puro com markdown como substrato canônico. Para isso, basic-memory é melhor — o Mem0 não persiste em arquivos legíveis por humano.
Workflow markdown-first (vault Obsidian, Logseq, Foam): Mem0 grava em vector store, não em .md editáveis. Quem precisa de revisão humana sobre cada nota deve preferir basic-memory ou seguir o gist do Karpathy direto.
Quando se quer transparência total do algoritmo de extração — a seleção de “fatos salientes” via LLM é parcialmente opaca, e cada release pode mexer no pipeline.
Custo de infra / equipe não comporta Qdrant ou Pinecone em produção, e cloud da Mem0 é caro demais para o caso.
Caso pede agent stateful por inteiro (com identidade persistente, hierarquia de memória explícita, paginação RAM/disco): Letta está mais alinhado.
Quando knowledge graph temporal é requisito (queries do tipo “qual era o estado em t1?“): Graphiti tem suporte a tempo bi-temporal nativo.

Armadilhas comuns

Armadilha 1: Confiar em score LongMemEval auto-reportado como dado objetivo

Os 93,4% são reportados pela própria Mem0 AI, não por benchmark independente. Antes de citar em decisão técnica, validar com benchmark próprio sobre o caso de uso real — a metodologia exata, o modelo de LLM usado na avaliação e o conjunto de dados importam muito (ver auditoria em 22 - Críticas, limitações e armadilhas).

Armadilha 2: Ignorar o custo da chamada de extração

Cada memory.add invoca pelo menos uma chamada extra de LLM para extrair fatos salientes. Em conversas longas e de alto volume, esse custo acumula — e não aparece no benchmark de retrieval que o vendor publica. Modelar o custo real de tokens de extração é pré-requisito para qualquer cálculo de TCO.

Armadilha 3: Tomar Mem0g do paper como sinônimo de Mem0 + Neo4j em 2026

O paper descreve graph store externo (Neo4j, Memgraph, etc.); a documentação atual indica remoção desse suporte no SDK open-source em favor de entity linking embutido. Quem replica o setup do paper pode encontrar surpresa na configuração. Antes de afirmar “Mem0 com grafo” em uma proposta técnica, verificar a versão e o changelog do SDK.

Armadilha 4: Presumir que "integrations" significam suporte de primeira linha

Algumas integrações são exemplos / cookbooks, outras são suportadas oficialmente como first-class. Antes de prometer “Mem0 funciona com X” para um cliente, abrir a página de integração de X e verificar se é cookbook, exemplo ou suporte mantido — a diferença é substancial em termos de manutenção ao longo do tempo.

Armadilha 5: Assumir revisão humana possível sobre a memória armazenada

Os fatos extraídos vivem em vector store, não em arquivos legíveis. Não há .md editável para auditoria manual, ao contrário de LLM-knowledge-base ou basic-memory. Em cenários regulados (saúde, finanças, jurídico), a opacidade do substrato é um risco a endereçar explicitamente no design do sistema.

Armadilha 6: Confundir benchmarks LOCOMO e LongMemEval

O score de 66,9% / 68,4% no paper (LOCOMO, LLM-as-judge) e o score de 93,4% no blog (LongMemEval, algoritmo atualizado) são benchmarks diferentes com metodologias diferentes. Não são comparáveis lado a lado — confundir os dois inflaciona artificialmente a impressão de progresso do framework.

Armadilha 7: Assumir paridade entre SDK Python e SDK TypeScript

O SDK TypeScript suporta menos LLMs (OpenAI, Anthropic, Groq) e menos vector stores do que o SDK Python (~16 LLMs, ~20 vector stores). Projetos full-stack que dependem de paridade devem checar a documentação antes de comprometer com uma configuração que funciona em Python mas não em TypeScript.

Pipeline de extração em detalhe

A pergunta natural sobre qualquer extração automática é: como eu sei o que foi descartado? O Mem0 expõe o conceito de memory operations — cada chamada a memory.add devolve uma lista estruturada das operações realizadas: ADD, UPDATE, DELETE, ou NONE. Isso é a única janela de observabilidade sobre o que o LLM interno decidiu preservar.

result = memory.add(messages, user_id="joao")
print(result["results"])
# Exemplo de output:
# [
#   {"id": "...", "memory": "João prefere Python a JavaScript", "event": "ADD"},
#   {"id": "...", "memory": "João usa macOS", "event": "UPDATE"},
# ]

O fato que não aparece no output foi silenciosamente descartado como “não saliente”. Não há log de rejeições — a única forma de auditar o que foi perdido é comparar manualmente o conteúdo da conversa com o estado de memory.get_all() antes e depois da chamada. Em ambientes regulados isso é uma lacuna de design: a ausência de trilha de auditoria de descarte é um risco operacional.

Entity linking embutido (pós-2025)

Versões recentes do Mem0 incorporaram entity linking diretamente ao pipeline de extração — sem depender de Neo4j externo. Na prática, isso significa que “João usa FastAPI” e “ele prefere async” são associados à mesma entidade João automaticamente, sem configuração explícita de grafo. O mecanismo é opaco (roda dentro do pipeline LLM), mas resolve o gap de coerência entre fatos sobre o mesmo usuário sem exigir infraestrutura extra.

Integrações além do chatbot de saúde

O caso do chatbot de saúde pessoal é o exemplo canônico, mas o Mem0 foi desenhado para cenários mais amplos:

Assistente de código com memória de preferências:

# Ao iniciar sessão de pair programming
memories = memory.search("code style preferences", user_id="dev_joao")
system_context = "\n".join([m["memory"] for m in memories])
# Injeta: "João usa type hints, prefere f-strings, evita one-liners"

Suporte ao cliente com histórico de produto:

# Ao abrir ticket
customer_history = memory.search(query, user_id=customer_id)
# Recupera: "Relatou problema X em 2024-11, resolvido com Y. Tem plano Pro."

Agente de pesquisa com acumulação de contexto:

# Cada sessão adiciona descobertas relevantes
memory.add([{"role": "assistant", "content": paper_summary}], user_id="researcher_01")
# Próxima sessão parte do estado acumulado, não do zero

A API de duas chamadas (memory.add / memory.search) funciona em qualquer um desses contextos sem mudança de interface — a diferença está nos dados e nos user_ids, não no código.

Posicionamento competitivo

A decisão entre Mem0, Letta, e Zep raramente é técnica — é contextual:

Pergunta-chave	Mem0	Letta	Zep
O agent precisa gerenciar a própria memória?	Não (pipeline transparente)	Sim (self-editing)	Não (pipeline KG)
Memória precisa de dimensão temporal?	Não	Não	Sim (bi-temporal)
Precisa auditar cada fato armazenado?	Parcial (memory ops)	Sim (ADE)	Sim (timestamps)
Substrato legível por humanos?	Não (vector store)	Não (banco)	Sim (KG navegável)
Benchmark independente disponível?	Auto-reportado	Ausente	Publicado

O Mem0 ganha em simplicidade de onboarding e na ausência de servidor para gerenciar — pip install mem0ai e duas chamadas de API. O custo é transparência e auditabilidade. Para projetos iniciais ou equipes sem recursos para operar infraestrutura adicional, esse trade-off faz sentido. Para produção regulada, o balanço pesa diferente.

Como explicar em inglês

Interview quote

“Mem0 is a drop-in memory layer: you call memory.add after each conversation turn and memory.search before generating a response. An internal LLM extracts salient facts and stores them in a vector store — the agent never needs to decide what to remember.”

Português	Inglês
camada de memória universal	universal memory layer
extração de fatos salientes	salient fact extraction
vector store	vector store
grafo de entidades	entity graph / knowledge graph
memory layer drop-in	drop-in memory layer
benchmark auto-reportado	self-reported benchmark
entity linking embutido	built-in entity linking
custo de extração	extraction cost (tokens)
memory opaca para revisão humana	opaque memory (not human-auditable)
integração de primeira linha	first-class integration

O que vem a seguir

Mem0 resolve o problema de persistência de fatos factual-episódicos com uma API de duas chamadas — simples, mas sem dimensão temporal. Saber que “João prefere respostas curtas” é útil; saber que “João preferia respostas curtas até março e desde então quer detalhes técnicos” é um nível diferente de raciocínio. É exatamente essa lacuna — memória com consciência de tempo — que a próxima nota endereça. O Zep e Graphiti implementam um knowledge graph bi-temporal onde cada fato carrega timestamps de validade e o sistema suporta queries como “qual era o estado de X em determinada data”. Para casos enterprise onde a evolução da memória ao longo do tempo é material (conformidade, auditoria, análise longitudinal de usuário), Zep representa um salto qualitativo sobre a abordagem vetorial do Mem0.

Veja também

06 - O LLM Wiki Pattern (gist do Karpathy) — abordagem alternativa, markdown-led, sem extração via LLM
09 - Panorama — onde Mem0 se posiciona no mapa
13 - basic-memory — alternativa local/markdown
14 - Letta (ex-MemGPT) — alternativa hierarchical, stateful agent
16 - Zep e Graphiti — alternativa KG temporal
21 - Comparativo crítico — onde o 93,4% aparece em contexto comparado
22 - Críticas, limitações e armadilhas — auditoria de claims auto-reportados

Referências

Chhikara, P.; Khant, D.; Aryan, S.; Singh, T.; Yadav, D. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv:2504.19413, aceito em ECAI 2025. https://arxiv.org/abs/2504.19413
Repositório oficial: https://github.com/mem0ai/mem0 (Apache-2.0; ~54k stars em abril de 2026, ~60,3k em julho de 2026). Ver também /releases para changelog (confirma ausência de menções a Neo4j/graph store externo nas releases recentes e a introdução do algoritmo single-pass ADD-only).
Site oficial: https://mem0.ai/
Página de pesquisa com benchmarks atualizados: https://mem0.ai/research (25 de abril de 2026).
Blog oficial — State of AI Agent Memory 2026 (1 de abril de 2026): https://mem0.ai/blog/state-of-ai-agent-memory-2026
Documentação: https://docs.mem0.ai/ — em particular docs.mem0.ai/integrations, docs.mem0.ai/components/llms/overview e docs.mem0.ai/components/vectordbs/overview.
Pricing: https://mem0.ai/pricing.
Repositório de exemplos: https://github.com/mem0ai/mem0/tree/main/examples — inclui cookbooks com LangGraph, CrewAI, AutoGen e outros frameworks.
Changelog do SDK: https://github.com/mem0ai/mem0/releases — fonte primária para verificar remoção de suporte a Neo4j e outras mudanças de interface que afetam replicação do paper.

Codex Technomanticus

Explorador

Mem0 — vetorial + grafo

Mem0

O que é

Por que importa

Como funciona

Exemplo concreto: chatbot de saúde pessoal

Uso incorreto: `memory.search` sem isolar por `user_id`

Fluxo de extração de fatos

Anatomia técnica

Comparativo de posicionamento: Mem0 vs Letta

Quando usar / quando não usar

Armadilhas comuns

Pipeline de extração em detalhe

Integrações além do chatbot de saúde

Posicionamento competitivo

Como explicar em inglês

O que vem a seguir

Veja também

Referências

Visão de gráfico

Sumário

Backlinks

Codex Technomanticus

Explorador

Mem0 — vetorial + grafo

Mem0

O que é

Por que importa

Como funciona

Exemplo concreto: chatbot de saúde pessoal

Uso incorreto: memory.search sem isolar por user_id

Fluxo de extração de fatos

Anatomia técnica

Comparativo de posicionamento: Mem0 vs Letta

Quando usar / quando não usar

Armadilhas comuns

Pipeline de extração em detalhe

Integrações além do chatbot de saúde

Posicionamento competitivo

Como explicar em inglês

O que vem a seguir

Veja também

Referências

Visão de gráfico

Sumário

Backlinks

Uso incorreto: `memory.search` sem isolar por `user_id`