memweave, una librería Python open-source de Sachin Sharma, apareció en Towards Data Science esta semana, presentándose como memoria de agente sin infraestructura — sin Pinecone, sin Weaviate, sin base de datos vectorial administrada. Solo una carpeta de archivos markdown y un índice SQLite. El timing es interesante: la mayor parte de la infraestructura de memoria de agente en el mercado ha estado persiguiendo escala — stores vectoriales, bases de grafos, embeddings distribuidos — mientras que la mayoría de los agentes en la práctica no necesitan escala. Necesitan persistencia, inspeccionabilidad y una señal de recuperación que no se arrastre en las consultas de coincidencia exacta. memweave apuesta a que el default ha estado equivocado.

La arquitectura son tres piezas. Archivos markdown en una carpeta son la fuente de verdad, legibles y editables tanto por humanos como por agentes. SQLite contiene un índice derivado con FTS5 para matching BM25 por palabras clave, la extensión sqlite-vec para similitud de embeddings acelerada por SIMD, y una caché de embeddings indexada por SHA-256 del contenido para que las reescrituras no disparen llamadas API redundantes. La recuperación es híbrida por defecto en 0.7 × vectorial más 0.3 × BM25, seguida de re-ranking MMR para diversidad. Un decaimiento temporal baja el peso de las memorias más viejas según la edad del archivo, con archivos persistentes (sin prefijo de fecha) envejeciendo distinto que los fechados tipo YYYY-MM-DD.md. Los namespaces de agente vienen de subdirectorios. El readme apunta a notebooks ejecutables — un demo de club de lectura y un agente de notas de reunión — pero sin benchmarks publicados, cosa que vale señalar: la librería es nueva y no está probada a escala.

Debajo de la librería hay un argumento real sobre lo que la memoria de agente realmente necesita. La mayoría de los agentes operan sobre miles de entradas, no millones; SQLite más sqlite-vec maneja eso sin salto de red. El default híbrido BM25+vectorial también es probablemente correcto: los embeddings solos fallan en casos de coincidencia exacta como "cuál es mi API key para el servicio X" donde el usuario literalmente escribió la cadena; BM25 solo falla en la formulación semántica. Pero la palanca operacional es la que hay que mirar: correr git diff memory/ muestra qué aprendió el agente entre corridas, commit por commit. Esa es una primitiva de depuración que ninguna base vectorial te da, y es exactamente lo que querés cuando estás tratando de reconstruir por qué un agente tomó una decisión específica a las 3 de la mañana. Control de versiones como operación de primera clase sobre la memoria, no como pensamiento posterior pegado vía exports de base de datos.

El patrón es copiable incluso si la librería en sí no encaja. Para cualquier agente cuya memoria no esté fundamentalmente en escala de millones de entradas — que es la mayoría de los agentes que los desarrolladores realmente envían — la plantilla que vale robar es: tratar una carpeta de markdown como fuente de verdad, derivar un índice que se pueda reconstruir desde cero en cualquier momento, recuperación híbrida en lugar de vectoriales puros, y versionar la memoria para poder auditar qué cambió. La advertencia honesta: a la escala donde las bases vectoriales realmente se ganan el lugar — corpus de documentos masivos, producción multi-tenant con millones de memorias por usuario — este enfoque probablemente se rompe, y el autor no ha corrido los benchmarks para mostrar el modo de fallo. Para agentes personales, agentes de investigación, herramientas internas — la mayoría aburrida-pero-real de lo que se construye — el patrón lo-fi es el buen punto de partida. Leé los dos demos de notebook, decidí si calza, y robá la idea de todos modos.