Panorama de implementações

TL;DR

Em abril de 2026 há aproximadamente uma dúzia de implementações relevantes de memória de agentes circulando entre conferências, papers, threads no X e repositórios populares. Elas se agrupam em três famílias: (1) inspiradas no LLM Wiki Pattern do Karpathy — LLM-knowledge-base (Wendel), OpenKB, graphify, basic-memory, NicholasSpisak/second-brain, Apify Second Brain Builder; (2) frameworks de produção — Letta (ex-MemGPT), Mem0, Zep/Graphiti, MemPalace, Cognee, LangMem, SuperMemory; (3) acadêmicas — A-MEM. Esta nota é o gateway da Wave 5 da trilha: mapeia o terreno, oferece tabela síntese com hedges nos números e um fluxograma de escolha. As notas seguintes (10–17) detalham implementação por implementação.

Dúvidas e lacunas desta nota

Dúvida gerada pelo conteúdo: O fluxograma de escolha pressupõe cenários razoavelmente claros (local-first? enterprise? já usa LangChain?), mas não trata o caso de sistemas híbridos — quando faz sentido combinar duas implementações (ex: basic-memory para vault pessoal + Mem0 para agente em produção), e como isso se arquiteta sem duplicar estado?

Lacuna potencial: A tabela cobre o corte de abril de 2026, mas não há critério explícito de quando uma implementação deve ser removida da lista por obsolescência — falta uma seção sobre como manter este panorama atualizado ao longo do tempo.

Esta nota tem data de validade

Tudo abaixo — tabela, scores, coluna de maturidade — é um instantâneo de abril de 2026. Se você está lendo isso meses depois, trate os números com ceticismo antes de decidir qualquer coisa: cheque o repositório primário de cada implementação antes de citar uma linha desta tabela em uma decisão real. Detalhes de como reavaliar em Como manter este panorama atualizado.

O que é

Imagine que você acabou de receber a tarefa de escolher — esta semana — qual framework de memória o time vai adotar para um agente que vai para produção em um mês. Você abre uma busca, encontra uma dúzia de nomes (Letta, Mem0, Zep, MemPalace, basic-memory…), cada um com um blog post dizendo que é a melhor opção, e nenhum critério óbvio para desempatar. É exatamente esse momento de afogamento que esta nota existe para evitar.

Esta nota é um mapa de mercado, não um catálogo exaustivo. O recorte temporal é deliberado: abril de 2026, momento em que o campo já tem benchmarks consolidados, surveys formais (ver 20 - Surveys) e o primeiro workshop dedicado em venue top-tier (MemAgents no ICLR 2026). Ferramentas surgem e somem rápido — três meses atrás MemPalace ainda não existia publicamente; daqui a três meses pode haver outras três que valem a pena. O objetivo aqui não é congelar uma lista definitiva, mas oferecer um esqueleto de orientação que o leitor possa reabrir periodicamente para reatualizar.

A trilha trata cada implementação relevante em nota própria a partir da 10 em diante. Esta nota — a 09 — funciona como índice anotado: explica como elas se relacionam, o que cada família resolve, quais sinalizam maturidade técnica e quais ainda são novidade promissora sem track-record. Quando uma decisão arquitetural precisa ser tomada — qual framework adotar, ou se vale construir do zero — esta página é o ponto de partida; as notas seguintes são o aprofundamento.

Por que importa

Orienta a escolha de ferramenta sem afogamento. A lista de implementações de memória cresceu rápido em 2025–2026; sem um mapa, é fácil escolher pela primeira que apareceu no feed.
Situa cada implementação na trilha. Cada linha da tabela tem uma nota dedicada; esta página é o índice navegável.
Separa hype recente de maturidade técnica. “Lançada em abril” e “estável em produção” não são sinônimos. A coluna de maturidade na tabela explicita esse corte.
Dá vocabulário comparativo. Termos como LongMemEval, self-host, audit trail, memory palace, knowledge graph têm significado preciso e vêm das fontes primárias — não são marketing.

As três famílias — visão geral

graph TD
    subgraph F1 [Família 1: Karpathy-inspired]
        K1[LLM-knowledge-base<br/>Wendel]
        K2[OpenKB]
        K3[graphify]
        K4[basic-memory]
    end

    subgraph F2 [Família 2: Produção]
        P1[Letta / ex-MemGPT]
        P2[Mem0]
        P3[Zep / Graphiti]
        P4[MemPalace]
        P5[Cognee]
        P6[LangMem]
        P7[SuperMemory]
    end

    subgraph F3 [Família 3: Acadêmica]
        A1[A-MEM]
    end

    LLMWiki([LLM Wiki Pattern<br/>Karpathy gist]) --> F1
    MemGPT([MemGPT / Park et al.<br/>2023]) --> F2
    NeurIPS([NeurIPS 2025]) --> F3

    F1 -->|inspira| F2
    F3 -->|alimenta| F2

Família 1 — Karpathy-inspired: Implementações que seguem diretamente o gist do Karpathy — markdown como substrato central, loop Ingest/Query/Lint explícito, filosofia de legibilidade humana. Tendem a ser self-host, mais simples e mais fáceis de entender em profundidade. O trade-off é menos automação: quem implementa toma mais decisões explicitamente. Ideal para quem quer dominar o pattern ou tem requisitos de privacidade/portabilidade fortes.

Família 2 — Frameworks de produção: Implementações que abstraem o loop em SDK ou serviço. Oferecem mais automação (extração de fatos automática, compactação, integrações com outros frameworks), ao custo de mais dependência e mais opacidade. O espectro vai do mais transparente (Letta, open-source, self-hostável) ao mais opaco (SuperMemory, SaaS proprietário). Ideal para quem quer velocidade de integração sem reinventar a roda.

Família 3 — Acadêmica: Implementações originadas em pesquisa, com foco em técnica de ponta em vez de ergonomia de produção. A-MEM é a mais relevante em 2026 (NeurIPS 2025). Código de pesquisa: útil para estudar a fronteira, não recomendado para produção sem porte significativo.

Como funciona — tabela síntese

Os números mudam frequentemente

Pricing, scores de benchmark e contagem de integrações são instantâneos de abril de 2026. Antes de citar qualquer linha em texto público, verifique a fonte primária listada em Referências. Cada implementação tem nota própria com tratamento mais detalhado.

Implementação	Família	Substrato	LongMemEval	Custo	Maturidade	Quando usar
LLM-knowledge-base (Wendel)	Karpathy-inspired	Markdown + Python (`kb/`)	n/a	self-host	beta	implementação direta do gist, em PT, com hybrid search (BM25 + RRF) e healing automático
OpenKB	Karpathy-inspired	Markdown wiki + PageIndex	n/a	self-host (Apache-2.0)	alpha	compilar corpus documental longo em wiki markdown; PageIndex para PDFs longos; chat com sessões persistidas
graphify	Karpathy-inspired	Knowledge graph (NetworkX, sem embeddings)	n/a	self-host (MIT)	beta	mixed-media (código, docs, vídeo, imagem); skill nativa para Claude Code/Cursor/Codex
basic-memory	Karpathy-inspired	Markdown + SQLite	n/a	open-source (AGPL-3.0)	estável	melhor integração markdown via MCP server; arquivos legíveis em Obsidian
Letta (ex-MemGPT)	Production	Hierarchical (RAM/disco, paginação)	não publicado	freemium / cloud paga	estável	self-editing memory, herdeiro do MemGPT, ecossistema maduro
Mem0	Production	Vetor + grafo	≈ 93,4% (auto-reportado)	tiers freemium	estável	rede ampla de integrações (LangChain, LangGraph, CrewAI, LlamaIndex, AutoGen, Agno e outras — verificar lista atual)
Zep/Graphiti	Production	Knowledge graph temporal (bi-temporal)	+ 18,5% sobre full-context com GPT-4o	tiers cloud	estável	enterprise, audit trail, raciocínio temporal
MemPalace	Production	Memory palace + SQLite	96,6% R@5 raw / ≥ 99% com LLM reranking	grátis local	recente (abr/2026)	local-first, MCP, sem cloud obrigatório
Cognee	Production	Pipeline modular (KG + vetor)	não publicado	open-source + cloud	em consolidação	quando se quer pipeline ETL de memória declarativo
LangMem	Production	Plug-in para LangChain/LangGraph	não publicado	open-source	em consolidação	quando o stack já é LangChain
SuperMemory	Production	Vetor + UI proprietária	não publicado	SaaS	em consolidação	uso pessoal com interface pronta
A-MEM	Acadêmica	Zettelkasten linkado dinamicamente	benchmark LoCoMo, não LongMemEval	research code	research	estudar a fronteira (NeurIPS 2025)

O símbolo "≈" e "+" não são casuais

”≈ 93,4%” significa “score auto-reportado pelos autores em uma versão específica do benchmark”. ”+ 18,5%” é melhoria sobre baseline, não score absoluto. As duas grandezas não são diretamente comparáveis — quem reporta uma usa convenção diferente de quem reporta a outra. Detalhes em 21 - Comparativo crítico.

Detalhes contextuais sobre LongMemEval

LongMemEval é o benchmark padrão da indústria para avaliar memória de longo prazo em LLM agents. Foi proposto em ICLR 2025 e o repositório oficial é github.com/xiaowu0162/LongMemEval. Ele isola cinco capacidades de memória — information extraction, multi-session reasoning, temporal reasoning, knowledge updates e abstention — em um conjunto de tarefas com histórico longo de sessões. É a referência preferida quando o objetivo é comparar implementações de forma minimamente justa.

Três observações importantes ao ler scores:

Quem não publicou scores. Letta, Cognee, LangMem e SuperMemory não divulgaram, no momento da publicação desta nota, scores em LongMemEval. Isso não significa que sejam ruins — significa que falta evidência pública para comparação. É um sinal a considerar quando transparência importa (auditorias, decisões enterprise, defesa pública de escolha técnica).
Score de MemPalace em modo híbrido tem ressalvas. A versão hybrid v4 held-out atinge 98,4% R@5 e a versão com LLM reranking atinge ≥ 99% R@5. Esses números, embora reais, foram obtidos com tuning adicional — análise crítica detalhada em 22 - Críticas, limitações e armadilhas. Comparar 96,6% raw com 93,4% auto-reportado por Mem0 já não é apples-to-apples; comparar 99% híbrido é menos ainda.
A-MEM usa LoCoMo, não LongMemEval. O paper de Wujiang Xu et al. (NeurIPS 2025, arXiv 2502.12110) avalia em LoCoMo, benchmark distinto, com cinco categorias de pergunta e formulação diferente. Não é comparável diretamente com os números em LongMemEval. Detalhes em 19 - A-MEM — Zettelkasten dinâmico.

A regra prática é: scores são úteis para descartar ferramentas claramente fracas, não para escolher entre ferramentas próximas. Quando dois sistemas estão dentro de poucos pontos um do outro, custo, integração e ergonomia decidem mais do que benchmark.

Como escolher — fluxograma

flowchart TD
    Start([Caso de uso]) --> Q1{Local-first?<br/>Privacy-first?}
    Q1 -->|sim| Q2{Já usa Obsidian<br/>ou markdown puro?}
    Q2 -->|sim| BM[basic-memory<br/>MCP server, arquivos legíveis em Obsidian]
    Q2 -->|não| MP[MemPalace<br/>SQLite local, 29 MCP tools]
    Q1 -->|não| Q3{Enterprise<br/>com audit trail?}
    Q3 -->|sim| Q4{Precisa raciocinar<br/>sobre tempo?}
    Q4 -->|sim| ZG[Zep/Graphiti<br/>knowledge graph temporal]
    Q4 -->|não| LE[Letta<br/>hierarchical memory]
    Q3 -->|não| Q5{Stack já é<br/>LangChain/LangGraph/CrewAI?}
    Q5 -->|sim| M0[Mem0<br/>rede ampla de integrações]
    Q5 -->|não| Q6{Quer dominar<br/>profundamente o pattern?}
    Q6 -->|sim| WIKI[do zero seguindo<br/>o LLM Wiki Pattern]
    Q6 -->|não| BM

O fluxograma é heurístico, não normativo. Existem casos legítimos de combinar duas ferramentas — por exemplo, basic-memory para o vault pessoal e Mem0 para um agente em produção — e existem casos em que nenhuma das opções serve e o melhor é construir uma solução custom seguindo o gist do Karpathy. O ponto é eliminar paralisia: dado um caso de uso, o fluxograma aponta um candidato razoável de partida.

Maturidade técnica vs recência: lendo os sinais

Uma decisão arquitetural real exige distinguir “surgiu recentemente” de “está pronto para produção”. O campo de memória de agentes teve explosão de lançamentos em 2025–2026, e a velocidade de novidades cria pressão para adotar o que saiu mais recentemente — que não é o mesmo que o que está mais estável.

Sinais que indicam maturidade técnica real (não marketing):

Issues documentados e resolvidos. Um repositório com 200+ issues fechados, incluindo bugs não-triviais, é sinal de que o projeto passou por iteração real. Repositório com 3 issues abertos pode significar que ninguém está usando o suficiente para encontrar bugs.
Breaking changes documentadas. Changelogs que listam o que quebrou entre versões e como migrar indicam que o projeto está evoluindo com responsabilidade. Ausência de changelog em projeto “maduro” é sinal de alerta.
Casos de uso de produção com nome. “Usamos em produção para X” com nome da organização e contexto. Não depoimentos genéricos de “ótima ferramenta” em README.
Benchmark próprio publicado e replicável. O código de avaliação está no repo, alguém além da equipe pode rodar. Scores anunciados em blog sem código são marketing.
Provider agnostic. Funciona com OpenAI, Anthropic, e modelos locais (Ollama, LiteLLM). Lock-in em provider único é risco operacional.

Sinais de recência sem maturidade:

Lançado há menos de 6 meses sem releases relevantes depois do anúncio inicial.
README excelente, docs escassas, exemplos que não rodam out-of-the-box.
Issues respondidos com “working on it” por meses sem commit.
Benchmark feito pela própria equipe, não replicado por terceiros.
Nenhum caso de uso de produção mencionado (apenas “ideal para” e “pode ser usado para”).

MemPalace vs Letta: exemplo do contraste

Em abril de 2026, MemPalace tem benchmark impressionante (96,6% R@5) e interface elegante, mas é projeto de meses. Letta tem anos de iteração desde a publicação do MemGPT paper (Park et al., 2023), comunidade ativa, issues bem documentados e casos de uso verificáveis. Os dois são válidos — para propósitos diferentes: MemPalace para local-first pessoal com tolerância a instabilidades; Letta para produção que precisa de ecossistema maduro.

Família 1 em profundidade: o que “Karpathy-inspired” significa na prática

A inspiração no gist do Karpathy não é apenas filosófica — se traduz em escolhas arquiteturais específicas que todas as ferramentas da família 1 compartilham, com variações:

Característica	LLM-knowledge-base	OpenKB	graphify	basic-memory
Operação central	Ingest → Query → Lint	Compile → Chat	Graph build → Query	Write → Search → Read
Substrato de conteúdo	Markdown `.md`	Markdown wiki	Knowledge Graph (JSON)	Markdown `.md` + SQLite
Índice de busca	BM25 + RRF	PageIndex (PDFs)	NetworkX (grafo)	SQLite FTS + MCP tools
Automação de ingestão	Semi-manual	Manual (upload)	Automática (scraping)	MCP (agente escreve direto)
Conteúdo binário	Não nativo	PDFs nativos	Imagens, vídeos, código	Não nativo
Self-host obrigatório	Sim	Sim	Sim	Sim (open-source AGPL)
Legibilidade humana	Alta	Alta	Baixa (grafo JSON)	Alta (arquivos markdown)

A diferença mais significativa dentro da família 1 é a legibilidade do storage intermediário: LLM-knowledge-base e basic-memory mantêm arquivos markdown que qualquer humano pode abrir e ler; graphify armazena o grafo em JSON/NetworkX que é legível em princípio mas não em prática sem ferramenta de visualização. Isso não é crítica de graphify — é trade-off deliberado para suportar conteúdo mixed-media com traversal de grafo eficiente.

Quando NÃO usar implementação pronta

Quando o objetivo é dominar profundamente o LLM Wiki Pattern. Escrever do zero a partir do gist do Karpathy (06 - O LLM Wiki Pattern (gist do Karpathy)) é um exercício pedagógico sem substituto. Frameworks abstraem decisões que vale a pena tomar manualmente pelo menos uma vez.
Quando o caso é tão específico que adaptação custa mais que construir. Schema customizado, regras de retenção idiossincráticas, integrações exóticas — em algum ponto o esforço de domar uma framework supera o de escrever a coisa.
Quando o volume é baixo demais para justificar overhead. Para um conjunto pequeno de notas e um agente que o consulta esporadicamente, markdown puro + Claude Code com CLAUDE.md schema já resolve. Adicionar SQLite, vetor e grafo cria operação que não se paga.
Quando o requisito principal é auditoria forte. Algumas frameworks armazenam memórias em estruturas opacas (vetor + JSON ofuscado). Se o caso exige inspeção humana fácil, markdown legível (07 - Por que Obsidian e markdown como substrato) ganha de qualquer abstração.

Família 2 em profundidade: o espectro de produção

A família 2 cobre um espectro amplo — de projetos totalmente open-source e self-hostáveis até SaaS proprietários. O eixo mais útil para comparação é transparência vs conveniência:

graph LR
    subgraph Transparente_selfhost ["Transparente + Self-host"]
        L[Letta<br/>open-source, self-editável]
        Z[Zep/Graphiti<br/>open-source + cloud optional]
        MP[MemPalace<br/>SQLite local, sem cloud]
        CO[Cognee<br/>pipeline declarativo, open]
    end

    subgraph Hibrido ["Híbrido"]
        M0[Mem0<br/>freemium, open-source core]
        LM[LangMem<br/>plug-in LangChain, open]
    end

    subgraph Opaco_SaaS ["Opaco / SaaS"]
        SM[SuperMemory<br/>UI proprietária, SaaS]
    end

    Transparente_selfhost -->|"mais controle,<br/>mais operação"| x[ ]
    Hibrido -->|"equilíbrio"| x
    Opaco_SaaS -->|"menos controle,<br/>menos operação"| x

A escolha entre transparência e conveniência não é moral — é funcional. Para um caso de uso com requisito de auditoria forte (compliance, dados sensíveis), transparência é obrigação. Para um prototype rápido que precisa estar em ar em uma semana, conveniência ganha. A heurística: quanto mais crítica a memória para o negócio, mais você quer transparência — porque vai precisar depurar, auditar e migrar em algum momento.

Outro eixo relevante é integração de stack. LangMem faz sentido se você já tem LangGraph/LangChain; Mem0 tem a rede de integrações mais ampla; Letta tem SDK próprio. Adotar Mem0 num stack que não é LangChain-based é possível, mas você perde parte do valor das integrações.

Armadilhas comuns

Armadilha 1: Confundir LongMemEval score com qualidade real em produção

O benchmark mede capacidades específicas em distribuição específica; sistemas podem estar otimizados para o benchmark sem ganho proporcional em casos reais. A diferença entre 93% e 96% em LongMemEval pode ser irrelevante para o seu caso de uso — e a diferença entre “tem fallback de provider” e “não tem” pode ser crítica. Benchmark é condição necessária para descartar candidatos fracos; não é condição suficiente para escolher entre os bons. Análise crítica detalhada em 22 - Críticas, limitações e armadilhas.

Armadilha 2: Escolher por hype recente sem benchmark próprio

MemPalace é de abril de 2026 — promissor, benchmark impressionante, mas sem track-record em produção prolongada. Letta tem vários anos de iteração desde MemGPT, com comunidade, issues documentados e bugs já descobertos. As duas afirmações coexistem; o leitor decide o trade-off. A heurística é: para sistema crítico, preferir maturidade sobre novidade; para experimento ou prototipagem, novidade com benchmark forte é candidato válido.

Armadilha 3: Não checar fallback de provider

Se a memória depende exclusivamente de OpenAI ou Anthropic, mudanças de pricing, rate-limit ou descontinuação de modelo derrubam o sistema. Frameworks maduros oferecem providers configuráveis (LiteLLM, Ollama, modelos locais). Checar isso antes de adotar — especialmente em sistemas que rodarão por meses sem manutenção ativa — é obrigação, não detalhe.

Armadilha 4: Tratar a tabela como autoridade final

Esta nota é um instantâneo de abril de 2026. O campo se move rápido: “estável hoje” pode ser “deprecated em seis meses”. Antes de tomar uma decisão arquitetural real, abrir os repos e blogs primários para ver o que mudou desde esta nota é obrigatório — não opcional. A tabela é ponto de partida para orientação, não fonte de verdade para escolha definitiva.

Como manter este panorama atualizado

O panorama de implementações muda em ciclos de meses. A tabela acima representa um instantâneo de abril de 2026 — não uma lista permanente. Para reavaliar periodicamente sem reescrever esta nota inteira, o processo recomendado é:

Checar o repo primário de cada implementação listada. Commits recentes? Issues fechados? Release nos últimos 3 meses? Se não, marcá-la como “possivelmente inativa”.
Consultar fontes de curadoria. Vectorize.io, Atlan, DEV.to têm comparativos editoriais que atualizam com certa frequência. São fontes secundárias — úteis para descoberta, não para especificação técnica.
Checar MemAgents workshop (ICLR 2025 foi o primeiro; os anuais seguintes trazem novas implementações validadas academicamente).
Critério de remoção da lista: implementação sem commit há 6+ meses, issues críticos sem resposta, repositório arquivado. Implementações removidas deveriam ir para uma seção de Obsolescência com data e motivo — para não perder o registro histórico.

A lista de implementações é um artefato vivo

Esta nota tem status: seedling deliberadamente — é ponto de partida, não enciclopédia definitiva. Revisar anualmente com os critérios acima e atualizar o updated: no frontmatter é o ciclo de manutenção correto. Não esperar que fique “completa” — o campo nunca para de mover.

Como explicar em inglês

Interview quote

“The memory framework landscape in 2026 splits into three families: Karpathy-inspired tools that use markdown as substrate and prioritize human readability, production frameworks that abstract the write-manage-read loop behind an SDK, and research implementations that push the state of the art. The right choice depends on privacy requirements, existing stack, and whether you need deep understanding of the pattern or just fast integration.”

Português	Inglês
panorama de implementações	implementation landscape
framework de memória	memory framework
self-host	self-hosted
código de pesquisa	research code
rastro de auditoria	audit trail
grafo de conhecimento temporal	temporal knowledge graph
busca híbrida	hybrid search
benchmark de memória de longo prazo	long-term memory benchmark
família de implementações	implementation family
maturidade técnica	technical maturity

O que vem a seguir

Com o panorama do mercado em mãos e o vocabulário arquitetural da nota 08, as notas seguintes (10 a 17) aprofundam cada implementação individualmente — começando pela LLM-knowledge-base do Wendel, a implementação mais próxima do gist original do Karpathy e portanto o melhor ponto de partida para quem quer entender o pattern de dentro. Cada nota de implementação aplica o mapa arquitetural dos cinco componentes como lente de análise, tornando as comparações técnicas em vez de anedóticas.

Veja também

06 - O LLM Wiki Pattern (gist do Karpathy) — pattern que inspira a família 1
10 - LLM-knowledge-base — implementação canônica em PT
11 - OpenKB — CLI para wiki compilada com PageIndex
12 - graphify — graph-based, mixed-media
13 - basic-memory — MCP server, markdown legível em Obsidian
14 - Letta — framework production, hierarchical
15 - Mem0 — vetor + grafo, rede ampla de integrações
16 - Zep e Graphiti — KG temporal, enterprise
17 - MemPalace — memory palace local-first
19 - A-MEM — Zettelkasten dinâmico — research/Zettelkasten
20 - Surveys e estado da arte 2026 — fundamentação acadêmica
21 - Comparativo crítico — análise rigorosa de benchmarks
22 - Críticas, limitações e armadilhas — auditoria honesta do campo

Referências

LongMemEval (Wu et al., ICLR 2025) — repositório oficial em https://github.com/xiaowu0162/LongMemEval
Vectorize.io — Best AI Agent Memory Systems in 2026: https://vectorize.io/articles/langchain-memory-alternatives
Atlan — Best AI Agent Memory Frameworks 2026 (comparativo editorial)
DEV.to (Bhardwaj / Anajulia Bittencourt) — Mem0 vs Zep vs LangMem vs MemoClaw: AI Agent Memory Comparison 2026: https://dev.to/anajuliabit/mem0-vs-zep-vs-langmem-vs-memoclaw-ai-agent-memory-comparison-2026-1l1k
Mem0 blog — State of AI Agent Memory 2026: https://mem0.ai/blog/state-of-ai-agent-memory-2026
Graphlit — Survey of AI Agent Memory Frameworks (comparativo editorial)
Repositórios primários:
- https://github.com/wendeus0/LLM-knowledge-base (Wendel — direto do gist do Karpathy)
- https://github.com/VectifyAI/OpenKB (OpenKB — wiki compilada com PageIndex)
- https://github.com/safishamsi/graphify (knowledge graph, MIT)
- https://github.com/basicmachines-co/basic-memory (Markdown + SQLite, AGPL-3.0)
- https://github.com/letta-ai/letta (ex-MemGPT)
- https://github.com/mem0ai/mem0 (Mem0)
- https://github.com/getzep/graphiti (Graphiti, KG temporal)
- https://github.com/milla-jovovich/mempalace (MemPalace)
- https://github.com/agiresearch/A-mem e https://github.com/WujiangXu/AgenticMemory (A-MEM)
Zep blog — State of the Art Agent Memory (números de + 18,5% sobre baseline com GPT-4o): https://blog.getzep.com/state-of-the-art-agent-memory/
Karpathy gist do LLM Wiki Pattern (3 de abril de 2026) — referenciado em 06 - O LLM Wiki Pattern (gist do Karpathy)
Park, J. S. et al. (2023). Generative Agents. https://arxiv.org/abs/2304.03442 — base do ciclo observation/reflection/planning que fundamenta o mecanismo reflective self-improvement
MemAgents Workshop, ICLR 2025 — https://sites.google.com/view/memagents/home — primeiro workshop dedicado a memória de agentes em venue top-tier; surveya implementações e propõe taxonomia do campo

Codex Technomanticus

Explorador

Panorama de implementações (abril 2026)

Panorama de implementações

O que é

Por que importa

As três famílias — visão geral

Como funciona — tabela síntese

Detalhes contextuais sobre LongMemEval

Como escolher — fluxograma

Maturidade técnica vs recência: lendo os sinais

Família 1 em profundidade: o que “Karpathy-inspired” significa na prática

Quando NÃO usar implementação pronta

Família 2 em profundidade: o espectro de produção

Armadilhas comuns

Como manter este panorama atualizado

Como explicar em inglês

O que vem a seguir

Veja também

Referências

Visão de gráfico

Sumário

Backlinks