MentisDB 0.8.2 suma memoria temporal, deduplicación y CLI para agentes de IA

MentisDB 0.8.2 incorpora cuatro funciones clave para memoria agéntica que ya estaban presentes en competidores como Mem0, Graphiti, Zep, Letta y Cognee: validez temporal, deduplicación automática, alcances multinivel y una CLI. La actualización también introduce el esquema V3 con migración automática, manteniendo su enfoque local, determinista y sin llamadas a LLM ni dependencias de nube.
***

• La versión 0.8.2 añade consultas “as_of”, relaciones temporales append-only y migración automática al esquema V3.
• MentisDB ahora puede deduplicar recuerdos casi idénticos con similitud de Jaccard, sin embeddings ni llamadas a modelos.
• La actualización incorpora alcances User, Session y Agent, además de una CLI REST para inspección y scripting.

MentisDB, una capa de memoria duradera de código abierto para agentes de IA, lanzó su versión 0.8.2 con cuatro funciones que buscaban cerrar las principales brechas detectadas frente a sistemas rivales como Mem0, Graphiti, Zep, Letta y Cognee. La actualización suma memoria temporal, deduplicación automática, recuperación por alcance y una interfaz de línea de comandos, todo bajo una misma premisa: operar en local, sin llamadas a modelos de lenguaje y sin introducir dependencias de nube.

De acuerdo con la publicación oficial del proyecto, el objetivo de esta versión fue emparejar capacidades que ya se habían convertido en estándar dentro del segmento de memoria agéntica. En esa lista aparecen los hechos temporales, la fusión de registros duplicados, la visibilidad por niveles y alguna forma de interacción por CLI. MentisDB afirma que ahora cubre esos cuatro frentes sin romper su esquema histórico de verificabilidad append-only.

Para quienes siguen de cerca el desarrollo de agentes de IA, el anuncio resulta relevante porque la memoria persistente se ha vuelto una de las piezas más críticas del stack. No basta con que un agente genere respuestas; también debe recordar hechos, distinguir qué sigue siendo válido, evitar repetir lo mismo y saber qué información puede ver cada actor dentro de un entorno multiagente.

La actualización no altera la filosofía central del proyecto. MentisDB sigue almacenando recuerdos en un registro encadenado por hash, con recuperación híbrida léxica, semántica y de grafo, y funcionando totalmente en local. Esa arquitectura busca ofrecer trazabilidad y consistencia en contextos donde la mutación silenciosa de datos puede introducir errores difíciles de auditar.

Memoria temporal y consultas en un punto del tiempo

La primera gran novedad de MentisDB 0.8.2 es la validez temporal de aristas. En la práctica, esto permite manejar hechos que cambian con el tiempo, como la ubicación de una oficina o un cargo laboral. Según explica la fuente, cada ThoughtRelation ahora incluye las marcas valid_at e invalid_at, que pueden establecerse explícitamente cuando se conocen los límites temporales o asignarse automáticamente al momento del append.

La función se apoya además en el parámetro as_of para búsquedas clasificadas. Con ese filtro, un agente puede consultar el estado de la memoria en una fecha concreta, excluyendo pensamientos añadidos después de ese momento y también aquellos que hayan sido sustituidos, corregidos o invalidados por otros pensamientos ya presentes antes de la marca temporal seleccionada.

Uno de los aspectos técnicos más llamativos es que el conjunto de elementos invalidados se construye una sola vez al abrir la cadena y luego se actualiza de forma incremental con cada append. Eso deja la búsqueda en tiempo de consulta en O(1), al menos para ese componente del proceso, y evita el uso de modelos externos para inferir cambios temporales.

Esta mejora implicó un cambio de esquema a V3. ThoughtRelation pasó de tres a cinco campos, y las cadenas V0, V1 y V2 migran automáticamente al abrirse, incluyendo una reconstrucción completa de la cadena hash. La migración se persiste para que futuras aperturas no repitan el proceso. El proyecto subraya que evaluó mutar el campo invalid_at de pensamientos previos al añadir relaciones Supersedes o Corrects, pero descartó esa opción porque rompería el modelo append-only verificable.

Deduplicación automática sin embeddings ni llamadas a LLM

La segunda novedad apunta a un problema común en sesiones largas: los agentes vuelven a registrar hechos ya conocidos. Eso hace que recuerdos prácticamente idénticos compitan por espacio dentro de la recuperación, reduzcan la relevancia y consuman ancho de banda de contexto. Para resolverlo, MentisDB 0.8.2 introduce una deduplicación opt-in basada en similitud de Jaccard sobre tokens léxicos normalizados.

El sistema se activa con la variable de entorno MENTISDB_DEDUP_THRESHOLD=0.85 o mediante la llamada db.with_dedup_threshold(Some(0.85)). Cada pensamiento nuevo se compara contra los últimos 64 pensamientos de la cadena, un valor que también puede ajustarse con MENTISDB_DEDUP_SCAN_WINDOW=64, y si la mejor coincidencia supera el umbral, se crea de forma automática una relación Supersedes hacia el pensamiento anterior.

El resultado es que el pensamiento reemplazado se filtra de los resultados de búsqueda. No hay llamadas a LLM, no hay embeddings y no hay dependencia de infraestructura externa. La lógica se sostiene en matemática de conjuntos de tokens y, según la descripción del proyecto, opera en microsegundos.

MentisDB defendió la elección de Jaccard por dos razones. La primera es que se trata de un método determinista y rápido, que no requiere cargar modelos, GPU ni tolerar variaciones entre ejecuciones. La segunda es que, para duplicados casi exactos, la similitud de Jaccard sería más precisa que la similitud coseno en textos cortos. Como ejemplo, el proyecto señala que un umbral de 0.85 puede detectar reformulaciones cercanas, pero deja pasar elaboraciones reales, como la diferencia entre “The sky is blue” y “The sky is blue on clear days”, con una Jaccard aproximada de 0.57.

Alcances de memoria para entornos multiagente

La tercera mejora introduce MemoryScope, un sistema de visibilidad multinivel pensado para entornos donde no toda la memoria debe ser compartida por igual. En arquitecturas con varios agentes, una nota temporal de sesión puede no tener sentido como recuerdo persistente de usuario, y una estrategia privada de un agente no debería filtrarse a otros actores que usan la misma cadena.

MentisDB 0.8.2 define tres niveles. User, que es el predeterminado, usa la etiqueta scope:user y es visible para todos los agentes que compartan la misma identidad de usuario. Session usa scope:session y restringe la visibilidad a la sesión que creó el pensamiento. Agent usa scope:agent y la deja solo para el agente creador.

En lugar de añadir un nuevo campo estructural a Thought, el proyecto optó por implementar estos alcances como etiquetas. La decisión fue deliberada. Añadir un nuevo campo habría requerido un esquema V4 y otra ronda de migraciones. Las etiquetas ya existían, ya participaban en el filtrado de búsquedas y la convención scope: se consideró fácil de auditar.

La API permite usar este sistema tanto en el append como en la búsqueda, y la superficie REST acepta el parámetro scope con valores como “session”. La capa MCP también transmite el alcance mediante etiquetas. En términos prácticos, esto acerca a MentisDB a funciones que antes estaban mejor cubiertas por alternativas como Mem0 y Letta.

CLI, migraciones y filosofía técnica

La cuarta novedad visible para usuarios y desarrolladores es una herramienta CLI con tres subcomandos: add, search y agents. Hasta ahora, la interacción fuera de una sesión de agente dependía del panel web. Con la nueva versión, el daemon puede consultarse desde terminal vía REST, usando ureq para HTTP síncrono, sin runtime async ni dependencia de Tokio.

El daemon se conecta por defecto a http://127.0.0.1:9472 y devuelve salida JSON. El proyecto destacó que esto facilita inspección rápida, depuración y scripting, especialmente cuando se combina con herramientas de shell como jq. Un ejemplo mostrado es canalizar resultados de búsqueda para extraer el contenido de pensamientos relacionados con despliegues.

Además de las funciones nuevas, el anuncio dedicó atención a la seguridad de migración. La versión 0.8.2 marca la tercera migración de esquema en la historia de MentisDB, siguiendo la secuencia V0 a V1, V1 a V2 y V2 a V3. Entre las lecciones aprendidas, el equipo resaltó un problema con la ruta rápida de empty-Vec en bincode. Cuando una estructura Rust contiene Vec<T> y los datos serializados tienen cero elementos, el deserializador puede aceptar cambios de diseño en T y continuar en los mismos offsets de bytes, produciendo datos incorrectos en silencio.

La solución adoptada fue verificar siempre que schema_version == MENTISDB_CURRENT_VERSION después de una deserialización exitosa por la ruta rápida. Más allá de ese detalle, el proyecto insistió en cuatro principios que guían la versión 0.8.2: cero llamadas a LLM en append y consulta, integridad append-only, cero dependencias nuevas para funciones centrales y compatibilidad retroactiva por defecto.

Eso implica que la deduplicación sigue siendo opcional, los alcances se predeterminan a User, las aristas temporales se inicializan en None y las cadenas antiguas migran de forma transparente. La actualización puede instalarse con cargo install mentisdb o desde el código fuente con cargo install –path . –locked. Las cadenas V0, V1 y V2 migran a V3 en la primera apertura, mientras que los sidecars vectoriales y los registros de skills no se ven afectados.

En cuanto a la hoja de ruta, la publicación oficial señaló que la versión 0.8.3 se enfocará en calidad de recuperación. Allí aparecen expansión de lemas de verbos irregulares, reranking ligero y cortes DF BM25 por campo. Ese paquete busca corregir la brecha de stemming que, según el proyecto, explica cerca de 38% de los fallos restantes en LoCoMo. Más adelante, MentisDB apunta a soporte para ontologías personalizadas y procedencia de episodios, descritas como las dos brechas competitivas que aún quedan abiertas.

En un momento en que muchos sistemas de memoria para agentes dependen de servicios externos o de inferencia costosa, MentisDB intenta posicionarse con una propuesta distinta. Su apuesta no es prometer más inteligencia en la capa de memoria, sino más control, más auditabilidad y menos complejidad operativa. Para equipos que desarrollan agentes locales o infraestructuras verificables, esa propuesta puede ser tan importante como las funciones nuevas que acaban de llegar.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín