memweave, uma biblioteca Python open-source de Sachin Sharma, apareceu no Towards Data Science esta semana, se apresentando como memória de agente sem infraestrutura — sem Pinecone, sem Weaviate, sem banco de dados vetorial gerenciado. Só uma pasta de arquivos markdown e um índice SQLite. O timing é interessante: a maior parte da infraestrutura de memória de agente no mercado tem perseguido escala — stores vetoriais, bancos de grafos, embeddings distribuídos — enquanto a maioria dos agentes na prática não precisa de escala. Precisam de persistência, inspecionabilidade e um sinal de recuperação que não tropece em consultas de correspondência exata. memweave aposta que o padrão tem estado errado.

A arquitetura são três peças. Arquivos markdown numa pasta são a fonte da verdade, legíveis e editáveis tanto por humanos quanto por agentes. SQLite contém um índice derivado com FTS5 para matching BM25 por palavras-chave, a extensão sqlite-vec para similaridade de embeddings acelerada por SIMD, e um cache de embeddings indexado por SHA-256 do conteúdo para que reescritas não disparem chamadas de API redundantes. A recuperação é híbrida por padrão em 0.7 × vetorial mais 0.3 × BM25, seguida de re-ranking MMR para diversidade. Um decaimento temporal reduz o peso de memórias mais antigas conforme a idade do arquivo, com arquivos persistentes (sem prefixo de data) envelhecendo diferente dos datados tipo YYYY-MM-DD.md. Namespaces de agente vêm de subdiretórios. O readme aponta para notebooks executáveis — um demo de clube de leitura e um agente de notas de reunião — mas sem benchmarks publicados, o que vale sinalizar: a biblioteca é nova e não foi testada em escala.

Por baixo da biblioteca há um argumento real sobre do que a memória de agente realmente precisa. A maioria dos agentes opera sobre milhares de entradas, não milhões; SQLite mais sqlite-vec lida com isso sem salto de rede. O padrão híbrido BM25+vetorial também é provavelmente correto: embeddings sozinhos falham em casos de correspondência exata como "qual é minha API key para o serviço X" onde o usuário literalmente escreveu a string; BM25 sozinho falha na formulação semântica. Mas a alavanca operacional é a que merece atenção: rodar git diff memory/ mostra o que o agente aprendeu entre execuções, commit por commit. Essa é uma primitiva de depuração que nenhum banco vetorial te dá, e é exatamente o que você quer quando está tentando reconstruir por que um agente tomou uma decisão específica às 3 da manhã. Controle de versão como operação de primeira classe sobre a memória, não como pensamento posterior colado via exports de banco de dados.

O padrão é copiável mesmo que a biblioteca em si não sirva. Para qualquer agente cuja memória não esteja fundamentalmente em escala de milhões de entradas — que é a maioria dos agentes que os devs realmente entregam — o template que vale roubar é: tratar uma pasta de markdown como fonte da verdade, derivar um índice que possa ser reconstruído do zero a qualquer momento, recuperação híbrida em vez de vetoriais puros, e versionar a memória para poder auditar o que mudou. A ressalva honesta: na escala onde bancos vetoriais realmente ganham seu lugar — corpus de documentos massivos, produção multi-tenant com milhões de memórias por usuário — essa abordagem provavelmente quebra, e o autor não rodou os benchmarks para mostrar o modo de falha. Para agentes pessoais, agentes de pesquisa, ferramentas internas — a maioria chata-mas-real do que se constrói — o padrão lo-fi é o bom ponto de partida. Leia os dois demos de notebook, decida se encaixa, e roube a ideia de qualquer jeito.