Un nuevo análisis técnico sobre OpenClaw y MentisDB sugiere que la carrera por definir un estándar de memoria para agentes de IA ya no es teórica. La comparación con Hermes muestra coincidencias importantes, pero también diferencias de diseño que podrían influir en cómo se conectarán herramientas, memorias persistentes y protocolos MCP en la próxima generación de sistemas de IA.
***
- OpenClaw usa un registro de capacidades para memoria, en contraste con el modelo de herencia ABC de Hermes.
- MentisDB puede integrarse con OpenClaw como herramienta MCP en menos de dos minutos o como backend nativo en TypeScript.
- El análisis concluye que Hermes y OpenClaw convergen en 11 requisitos esenciales para un futuro estándar de memoria de agentes.
La discusión sobre cómo dotar de memoria persistente a los agentes de inteligencia artificial está entrando en una etapa más concreta. Un nuevo análisis centrado en OpenClaw y su integración potencial con MentisDB plantea que varias de las piezas técnicas que parecían opcionales ya empiezan a perfilarse como requisitos básicos para cualquier estándar serio de memoria de agentes.
El texto, titulado MentisDB × OpenClaw — Memory Integration Guide and Protocol Comparison, compara la arquitectura de OpenClaw con la de Hermes, otro framework analizado previamente por el mismo equipo. La conclusión principal es que ambos sistemas resuelven el problema de la memoria conectable, pero lo hacen con filosofías, lenguajes y compensaciones técnicas distintas.
Para lectores menos familiarizados con el tema, la memoria en un agente de IA no se refiere solo al historial inmediato de una conversación. También abarca mecanismos para recuperar contexto antiguo, conservar decisiones, registrar preferencias del usuario y escribir información duradera que pueda reutilizarse semanas o meses después.
Ese punto resulta especialmente importante en plataformas donde un agente opera a través de varios canales, usuarios y dispositivos. En ese contexto, la memoria deja de ser una función decorativa y pasa a ser una capa de infraestructura, tan crítica como el sistema de herramientas o el enrutamiento de mensajes.
Qué es OpenClaw y por qué su diseño importa
OpenClaw es descrito como una pasarela de IA personal. A diferencia de Hermes, que se presenta principalmente como un agente auto-mejorable accesible desde terminal, OpenClaw funciona como un demonio multicanal que corre en segundo plano y enruta mensajes entre Claude y una larga lista de servicios de mensajería.
Entre esas plataformas figuran WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Matrix, Zalo, WeChat y QQ, entre otras. La propuesta es que el usuario hable con la IA desde aplicaciones cotidianas, mientras OpenClaw se encarga de traducir protocolos, despachar herramientas, manejar memoria y entregar respuestas.
Al momento del análisis, la versión citada era 2026.4.20. El historial del proyecto superaba los 17.000 commits, y los 12 más recientes correspondían a los últimos días, incluyendo ajustes de rendimiento en integración continua, refactorización de pruebas y utilidades compartidas para fixtures.
Ese ritmo de desarrollo se usa como argumento para subrayar que no se trata de un prototipo experimental. Según el análisis, OpenClaw debe operar de forma confiable durante sesiones de semanas o meses, a menudo con múltiples usuarios al mismo tiempo cuando funciona en modo gateway. Por eso, la memoria se presenta como un componente esencial.
La arquitectura de memoria de OpenClaw frente a Hermes
La diferencia central entre OpenClaw y Hermes está en el patrón de integración. Mientras Hermes define memoria a partir de una clase base abstracta o ABC que los proveedores deben heredar, OpenClaw adopta un registro de capacidades. En lugar de subclasificar una interfaz única, el plugin registra callbacks específicos.
Ese enfoque divide la memoria en cuatro espacios reemplazables de forma independiente. El primero es promptBuilder, que construye el bloque del prompt del sistema y orienta al modelo sobre cuándo consultar la memoria. La guía por defecto indica que, antes de responder sobre trabajo previo, decisiones o preferencias del usuario, debe ejecutarse memory_search.
El segundo componente es flushPlanResolver, invocado antes de la compresión de contexto para decidir qué pensamientos deben escribirse de manera duradera en MEMORY.md. El texto lo compara con el hook on_pre_compress() de Hermes, aunque señala una diferencia relevante: en OpenClaw el resolvedor devuelve un plan declarativo, y luego el sistema lo ejecuta.
Los otros dos bloques son runtime, donde vive el motor real de búsqueda e indexación mediante la interfaz MemorySearchManager, y publicArtifacts, que permite listar artefactos de memoria visibles externamente, por ejemplo en un panel del gateway. Este último no tiene equivalente en Hermes.
El runtime espera una implementación de MemorySearchManager. El SDK de OpenClaw define métodos como search, warmSession, status y close. Los resultados de búsqueda incluyen campos tipados como corpus, ruta, título opcional, tipo, puntuación, fragmento y líneas de origen.
Actualmente, OpenClaw soporta tres backends. El backend builtin usa SQLite por agente, ubicado en ~/.openclaw/state/memory/{agentId}.sqlite, con FTS5 y vector opcional. El backend qmd usa Quantum Memory Daemon como sidecar local, con recuperación vectorial, reranking y expansión de consultas. El backend honcho se conecta al servicio en la nube de Honcho, orientado a memoria multiusuario y multidispositivo.
Cinco puntos donde la memoria entra en el ciclo del agente
El análisis identifica cinco momentos de integración en el ciclo de conversación de OpenClaw. El primero es el ensamblado del prompt del sistema, donde promptBuilder() inyecta la guía de recuperación. El objetivo es que el modelo sepa cuándo llamar a herramientas de memoria antes de responder.
El segundo es el registro de herramientas. OpenClaw expone memory_search y memory_get desde su extensión principal de memoria, de modo que ambas aparecen dentro del catálogo nativo de herramientas del agente. Eso conecta directamente la memoria con la capacidad operativa del modelo.
El tercer punto es el calentamiento de sesión. OpenClaw llama a warmSession(sessionKey) al inicio de la sesión, y las implementaciones pueden aprovechar ese momento para sincronizar índices en segundo plano. El cuarto es la sincronización disparada por búsqueda, donde una llamada a memory_search puede activar una resincronización asíncrona para turnos posteriores.
El quinto momento es la compresión de contexto. Antes de que los mensajes se descarten, flushPlanResolver decide qué contenido debe escribirse de forma duradera. Luego un turno silencioso del agente ejecuta ese plan y lo agrega a MEMORY.md en modo append-only, protegido por guardian.
Uno de los puntos más relevantes del documento es el rol de MCP. A diferencia de Hermes, donde MCP es una entre varias rutas de integración, OpenClaw lo trata como un mecanismo principal de registro de herramientas. Su configuración soporta transporte por stdio o HTTP, y esas herramientas MCP se materializan en el catálogo nativo durante el arranque.
Cómo encaja MentisDB dentro de OpenClaw
El documento sostiene que MentisDB puede funcionar como herramienta MCP en OpenClaw en menos de dos minutos. El flujo parte con la instalación del demonio mediante cargo install mentisdb, seguido del inicio de mentisdbd y una verificación de salud en el puerto 9471, que debería devolver un estado OK.
Luego basta con añadir cuatro líneas de YAML en la configuración de OpenClaw para registrar el servidor MCP de MentisDB por HTTP con transporte streamable-http y un tiempo de espera de 5.000 milisegundos. Después de guardar y reiniciar el gateway, OpenClaw descubre automáticamente las herramientas expuestas.
Entre las herramientas listadas en el ejemplo aparecen mcp_mentisdb_mentisdb_search, mcp_mentisdb_mentisdb_append_thought, mcp_mentisdb_mentisdb_recent_context y mcp_mentisdb_mentisdb_bootstrap. Desde ese momento, quedan disponibles en cualquier conversación del agente, sin importar si ocurre por Telegram, WhatsApp, Slack u otro canal soportado.
El texto también muestra opciones para limitar el conjunto de herramientas expuestas, priorizar MentisDB al inicio de cada conversación agregando una instrucción en el prompt del sistema o en MEMORY.md, y habilitar una URL HTTPS en lugar de una dirección local. El objetivo es ofrecer una integración rápida, sin escribir código adicional.
Para integraciones más profundas, el análisis propone un backend nativo de memoria en TypeScript. La estructura del plugin incluye un directorio bajo ~/.openclaw/plugins/memory-mentisdb con package.json, openclaw.plugin.json y un subdirectorio src que contiene index.ts y manager.ts.
En ese esquema, manager.ts implementa la interfaz MemorySearchManager. La búsqueda se realiza mediante peticiones POST a /v1/search sobre la URL base de MentisDB, usando una chain_key y transformando los pensamientos recuperados en resultados de memoria con corpus, path, tipo, puntaje y snippet.
El método warmSession puede verificar la disponibilidad del demonio a través de /health. El método status devuelve un estado de disponibilidad con la etiqueta MentisDB. También se incluye una función appendThought para escribir observaciones mediante POST a /v1/thoughts, con contenido, tipo de pensamiento, chain_key y etiquetas opcionales.
En index.ts, el plugin registra la capacidad de memoria. Allí se define un bloque de prompt que instruye al modelo a usar memory_search antes de responder sobre decisiones pasadas, trabajo previo o preferencias del usuario. Además, el flushPlanResolver toma los últimos cinco mensajes del usuario, recorta su contenido y prepara escrituras etiquetadas como Observation.
El runtime también puede ejecutar un onTurnComplete para persistir cada turno terminado, concatenando el mensaje del usuario con la respuesta del asistente. Finalmente, publicArtifacts permite listar un artefacto visible como “MentisDB chain”, asociado a la cadena usada por la integración. La activación del backend se completa desde YAML con variables de entorno como MENTISDB_URL y MENTISDB_CHAIN.
Qué cambia en el debate sobre un estándar de memoria
La comparación entre Hermes, OpenClaw y el estándar propuesto ocupa la parte más estratégica del documento. Según el análisis, ambos frameworks ya cubren el núcleo del protocolo: recuperación y persistencia, inyección en prompt, exposición de herramientas, prefetch asíncrono, hook de precompresión, manejo de fallos y alcance multiusuario.
OpenClaw añade artefactos públicos y convierte a MCP en un componente de primera clase. Hermes, por su parte, aporta un hook de observabilidad de delegación llamado on_delegation() y una abstracción más rica para asistentes de configuración. El documento remarca que ninguno es un superconjunto estricto del otro.
Una de las revisiones más importantes es el abandono de la idea de que un estándar debería parecerse a una ABC en Python. A la luz de OpenClaw, el equipo concluye que eso sería demasiado restrictivo. Un protocolo agnóstico al lenguaje debería definir eventos, orden de ejecución y argumentos, no imponer si la implementación usa herencia o registro de capacidades.
También cambia de forma notable la posición sobre MCP. Lo que antes se veía como una ruta opcional ahora es planteado como una parte imprescindible del futuro estándar. El argumento es que MCP se está convirtiendo rápidamente en el protocolo universal de herramientas, con adopción por actores como Anthropic, GitHub Copilot, Cursor, Claude Desktop y ahora OpenClaw.
Otro ajuste consiste en tratar la observabilidad de delegación como una extensión opcional, no obligatoria. Hermes la necesita más por su orientación a orquestación multiagente. OpenClaw, en cambio, opera en un contexto de gateway donde esa capacidad no es central. El análisis considera que eso demuestra que el hook es real, pero de nicho.
El texto también rechaza la idea de que solo deba existir un proveedor de memoria. Aunque Hermes y OpenClaw hoy funcionan con un proveedor o un slot principal a la vez, eso es presentado como una decisión práctica de implementación y no como un principio universal. Se menciona que algunos casos de uso podrían combinar recuperación local rápida con almacenamiento remoto de largo plazo.
Como resultado, el análisis redefine 11 requisitos obligatorios para un protocolo de memoria conforme. Entre ellos figuran verificación de disponibilidad sin llamadas de red, inicialización de sesión con contexto de usuario, bloque de prompt del sistema, esquemas de herramientas compatibles con OpenAI, despacho de herramientas, prefetch asíncrono, sincronización de turno, extracción precompresión, límite de sesión, interoperabilidad con MCP y aislamiento de fallos.
Además, se enumeran cuatro capacidades opcionales: puente de escritura integrado, observabilidad de delegación, listado de artefactos públicos y esquema de configuración para asistentes de setup. Según la fuente, esa convergencia entre Hermes y OpenClaw, desarrollados por equipos diferentes, en lenguajes distintos y para despliegues distintos, es precisamente lo que sugiere que ya existen bases reales para un estándar común.
De cara a los próximos pasos, el equipo afirma que planea publicar el backend nativo como un paquete npm bajo el nombre @mentisdb/openclaw-plugin. También prevé enviarlo al registro de plugins de OpenClaw junto con un plugin Python MemoryProvider para Hermes, mientras abre una discusión en GitHub para recoger comentarios de ambas comunidades antes de redactar una especificación formal.
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
Artículos Relacionados
Computación Cuántica
AES-128 sigue siendo seguro ante computadoras cuánticas, afirma experto en criptografía
Hardware
PrismML lanza Ternary Bonsai, modelos de IA de 1,58 bits con mayor precisión y menor memoria
Curiosidades
KindBio busca cultivar órganos en animales sin cerebro para enfrentar la escasez de trasplantes
Estados Unidos