Cinco Bugs Mataram agentmemory em Sete Dias

Fabio Akita removeu agentmemory da produção após sete dias, abriu cinco relatórios de bug reproduzíveis contra o projeto de 15.7K estrelas, e lançou ai-memory—uma substituição por SQLite FTS5 e markdown—na mesma semana.

A arquitetura do agentmemory: um servidor MCP em TypeScript emparelhado com uma máquina iii separada em Rust, quatro portas abertas, três processos, e índices BM25 em memória persistidos em uma loja KV remota. Passados 10.000 observações, o arquivo de índice BM25 (mem:index:bm25.bin) degrada silenciosamente para aproximadamente 96 bytes no reinício, forçando uma reconstrução completa que custa cinco minutos de tempo de inicialização (issue #309). Cada escrita passa por um debounce de IndexPersistence de cinco segundos; quando a chamada upstream state::set expira aos 30 segundos, o processo Node sai e a RAM em buffer desaparece—uma janela de perda de dados garantida a cada timeout (issue #204).

Dois bugs adicionais agravaram o problema. O código lê configuração através de process.env em um caminho e getMergedEnv() em outro, produzindo incompatibilidades de configuração (issue #456). O hook do Claude Code lia data.tool_output, mas Claude Code emite tool_response. A incompatibilidade silenciosamente descartou aproximadamente 47% de todas as chamadas de ferramentas por seis semanas (issue #539). Um quinto bug causou a máquina Rust usar o diretório de trabalho do chamador como seu caminho de base, espalhando lojas de estado separadas entre terminais no Windows (issue #303). Os bugs são estruturais—a arquitetura requer reescrever metade do sistema para fechá-los.

ai-memory aposta contra complexidade em cada camada. Armazenamento é markdown simples commitado em git. Indexação é SQLite FTS5. Implantação é um único binário ou container sem dependências de serviço externo. Hooks disparam automaticamente em chamadas de ferramentas de agentes—sem comandos write_note acionados pelo usuário necessários. Decaimento de memória funciona em um cronograma sem intervenção do operador.

O design é retirado diretamente do gist da LLM Wiki de Andrej Karpathy. A abordagem index.md de Karpathy funciona em escala moderada (aproximadamente 100 fontes, centenas de páginas) e evita infraestrutura de RAG baseada em embeddings. Akita implementa um modelo de três camadas (captura bruta para consolidação de wiki para schema) com três operações (ingest / query / lint), executando localmente sem um pipeline vetorial.

O modo de falha que ai-memory visa é handoff entre agentes. Akita roda Claude Code como seu orquestrador primário, dispara Codex contra o mesmo diretório de trabalho quando Claude para, e então retorna ao Claude para implementação cuidadosa. Sem memória externa compartilhada, cada mudança de agente requer um ciclo write-then-read manual HANDOFF.md. Todos os três agentes lidam com compactação em sessão independentemente—Claude Code roda microcompact em gaps temporais, autocompact em um limiar de token, e um sessionMemoryCompact experimental; Codex usa auto_compact_token_limit por modelo; opencode ancora compactação com um buffer de 20.000 tokens—mas nenhum sobrevive cruzando limites de agentes.

Akita não publicou números de latência para recuperação FTS5 versus alternativas de vector-DB, pontuações de recall, ou resultados comparativos contra basic-memory, mem0, e ferramentas de knowledge-graph. ai-memory é novo o suficiente que o mecanismo de sincronização entre agentes—estado compartilhado em tempo real entre uma sessão Claude Code ativa e um processo Codex executando simultaneamente—permanece não testado sob concorrência significativa. Nenhuma figura em escala de produção foi divulgada.

Perda silenciosa de observação em agentmemory é arquitetural—três processos com persistência de KV remota—não misconfiguraçãoDa. A abordagem single-binary SQLite do ai-memory troca escalabilidade horizontal por confiabilidade local que workflows multi-agente solo e de pequena equipe precisam. Valide a qualidade de recuperação FTS5 contra seu próprio corpus de memória antes de se comprometer com o stack.