Por Canuto  

La fragmentación de la memoria en los agentes de inteligencia artificial podría empezar a ceder. Una nueva propuesta basada en Hermes y MentisDB plantea una interfaz común para conectar backends de memoria portables entre frameworks, con soporte para recuperación semántica, compresión de contexto, delegación y cierre limpio de sesión.
***

  • Hermes propone una interfaz llamada MemoryProvider que cubre más etapas del ciclo de vida que otras abstracciones usadas hoy en IA agente.
  • MentisDB ya fue adaptado como proveedor nativo para Hermes sin modificar el framework, mediante un plugin de unas 250 líneas.
  • La propuesta aspira a convertirse en un estándar comunitario para que backends de memoria funcionen entre LangChain, AutoGen, LlamaIndex y otros entornos.

La memoria sigue siendo uno de los puntos más fragmentados dentro del ecosistema de agentes de inteligencia artificial. Cada framework importante ha creado su propia abstracción, pero esas piezas no suelen hablar entre sí. Ese aislamiento dificulta construir backends reutilizables y obliga a los desarrolladores a rehacer integraciones según la plataforma elegida.

En ese contexto, el texto Toward a Standard Agent Memory Protocol — Lessons from Hermes and MentisDB plantea que el framework Hermes, desarrollado por Nous Research, ya contiene una de las interfaces abiertas más completas para memoria de agentes. La propuesta sostiene que ese diseño podría servir como base para un estándar comunitario llamado agent-memory-protocol.

La idea central es simple, pero ambiciosa. Un backend de memoria que implemente una sola interfaz debería poder operar, sin grandes cambios, en distintos frameworks de agentes. De concretarse, esto reduciría la dependencia de integraciones hechas a la medida y abriría la puerta a memorias más portables, duraderas y observables.

Para los lectores menos familiarizados con este campo, la “memoria” de un agente no se limita al historial de chat. También incluye la capacidad de recordar decisiones pasadas, recuperar hechos relevantes de sesiones anteriores, registrar eventos importantes y condensar contexto antes de que se pierda por límites de ventana o compresión.

La publicación divide su argumento en tres partes. Primero, explica por qué la abstracción MemoryProvider de Hermes destaca frente a las alternativas actuales. Luego muestra cómo MentisDB puede funcionar como proveedor nativo de memoria para Hermes. Finalmente, presenta una ruta más simple para usar MentisDB como herramienta MCP dentro del mismo framework.

Por qué las abstracciones actuales se quedan cortas

Según la explicación, varias soluciones ampliamente usadas cubren solo una fracción del problema. En LangChain, por ejemplo, la abstracción BaseMemory se centra en dos métodos: cargar variables de memoria y guardar contexto. Eso resuelve recuperación y persistencia, pero deja fuera otras necesidades operativas que aparecen en agentes más complejos.

Entre esas carencias están la exposición de herramientas al modelo, la gestión de eventos antes de comprimir el contexto, la identificación de límites de sesión o la observación de tareas delegadas a subagentes. En la práctica, eso obliga a los equipos a conectar esas piezas manualmente, proyecto por proyecto.

Semantic Kernel ofrece plugins más ricos, pero no orientados de forma específica al ciclo de vida de la memoria. AutoGen, por su parte, se apoya en buffers conversacionales en proceso. Sustituirlos, de acuerdo con la publicación, puede requerir bifurcar el agente o alterar componentes internos del framework.

Frente a ese panorama, Hermes es presentado como una excepción. Su clase abstracta MemoryProvider no se limita a recordar y guardar. También contempla inicialización, precarga semántica, compresión, observabilidad, límites de sesión, puentes de escritura y apagado limpio.

Esa amplitud es la base del argumento. No se trata solo de almacenar recuerdos, sino de insertar la memoria en momentos precisos del ciclo operativo del agente. Esa diferencia, en teoría, permite que un backend externo haga su trabajo sin depender de hacks específicos para cada framework.

Cómo funciona la interfaz MemoryProvider

La interfaz propuesta se organiza por bloques. Primero están los elementos de identidad y ciclo de vida obligatorio. Allí figuran el nombre del proveedor, una verificación de disponibilidad al arranque, la inicialización por sesión y la exposición de esquemas de herramientas en formato compatible con OpenAI.

Después aparecen operaciones por turno que pueden usarse de forma opcional. Entre ellas destacan system_prompt_block, prefetch, queue_prefetch, sync_turn y handle_tool_call. En conjunto, estas piezas permiten inyectar contexto relevante, preparar búsquedas en segundo plano y persistir el contenido de cada intercambio entre usuario y asistente.

También incluye hooks optativos para eventos críticos. on_turn_start permite disparar tareas profundas cada cierto número de turnos. on_session_end marca el cierre de una sesión. on_pre_compress ofrece una última oportunidad para extraer hechos importantes antes de que mensajes antiguos sean descartados. on_memory_write sincroniza escrituras del almacén interno. on_delegation observa el resultado de subtareas ejecutadas por subagentes. shutdown cierra conexiones y libera recursos.

La publicación resume seis principios de diseño detrás de esta arquitectura. El primero es la inyección de instantánea congelada. La memoria se carga una vez al inicio y se incorpora al prompt del sistema, pero las escrituras posteriores no alteran ese prompt en mitad de la sesión. Eso preserva la reutilización de caché de prefijo del modelo.

El segundo principio ubica la precarga en el límite del turno, no en la llamada a la API. Así, el contexto recuperado se inserta para el siguiente intercambio sin contaminar el historial persistido. El tercero es un puente de escritura integrado, útil para reflejar automáticamente los cambios en archivos internos como MEMORY.md hacia un backend externo.

Los otros tres principios son la extracción previa a la compresión, la observabilidad de delegación y la degradación elegante con un solo proveedor externo activo. Esta última busca que fallos en el backend no derriben al agente. Si algo sale mal, la memoria incorporada permanece como red de seguridad.

Comparación con LangChain, Semantic Kernel y AutoGen

La comparación incluida en el texto es directa. MemoryProvider de Hermes cubre recuperación, persistencia, exposición de herramientas al modelo, precarga asíncrona, hook antes de compresión, puente de escritura, observabilidad de delegación, cierre de sesión, aislamiento ante fallas y alcance multiusuario con user_id y agent_identity.

En la tabla presentada, LangChain queda limitado a recuperación y persistencia, sin hooks para compresión ni delegación. Semantic Kernel aparece con capacidades parciales, pero sin una interfaz específica para memoria. AutoGen figura con un buffer conversacional que tampoco resuelve esos puntos de ciclo de vida.

La publicación agrega que, con pequeñas extensiones para soporte asíncrono nativo y un esquema estandarizado de configuración, esta interfaz podría servir como base de una especificación compartida entre LangChain, AutoGen, LlamaIndex y otros frameworks.

Esa aspiración no es menor. En un mercado donde cada entorno promueve sus propias abstracciones, estandarizar la capa de memoria equivaldría a desacoplar una pieza crítica del resto del stack. El efecto podría ser comparable al que tuvieron estándares de plugins o APIs en otras capas del software.

MentisDB como proveedor nativo de Hermes

La segunda parte del texto aterriza la propuesta con una integración concreta. MentisDB puede operar como proveedor nativo de memoria en Hermes mediante un plugin ubicado en ~/.hermes/plugins/mentisdb/__init__.py, acompañado de un archivo plugin.yaml. La publicación subraya que esto se logra sin modificar el código del framework.

Los requisitos previos son tener corriendo localmente el daemon mentisdbd, usar Python 3.11 o superior y contar con httpx instalado en el entorno virtual de Hermes. A partir de allí, el plugin implementa el ciclo de vida completo definido por MemoryProvider.

Entre sus funciones se incluyen la precarga semántica inyectada antes de cada turno, una precarga en segundo plano para el turno siguiente, la sincronización del contenido del usuario y del asistente, la exposición de herramientas mentisdb_recall y mentisdb_store, y el reflejo automático de escrituras del almacén interno hacia MentisDB.

Además, el plugin registra mensajes de usuario antes de la compresión, guarda un resumen compacto al final de la sesión y persiste resultados de delegación entre agentes. También define un bloque de prompt del sistema que explica al modelo que su memoria de largo plazo está respaldada por MentisDB y cómo usar sus herramientas.

La activación descrita es sencilla. El usuario ejecuta el asistente “hermes memory setup”, elige mentisdb, define la URL del daemon y la chain key. Luego el sistema guarda la configuración en ~/.hermes/.env y ~/.hermes/config.yaml. Tras reiniciar Hermes, el backend queda activo y puede verificarse con “hermes memory status”.

Una opción más simple mediante MCP

La tercera parte describe una alternativa sin integración total de ciclo de vida. Como MentisDB habla el protocolo MCP de forma nativa en el puerto 9471, Hermes puede conectarse a él como servidor MCP con solo agregar su URL en ~/.hermes/config.yaml.

En este modo, el modelo descubre herramientas como mentisdb_append_thought, mentisdb_search, mentisdb_recent_context y mentisdb_bootstrap. La ventaja es la simplicidad. No hace falta escribir plugin ni tocar el framework. La desventaja es que no se habilitan sincronización automática de turnos, observación de compresión ni manejo explícito de límites de sesión.

El texto recomienda esta vía para búsquedas o escrituras rápidas bajo demanda. Para uso productivo, en cambio, señala que la integración nativa como proveedor es la opción correcta. La diferencia clave es que el proveedor participa del ciclo de vida del agente, mientras las herramientas MCP solo se invocan cuando el modelo decide usarlas.

También se ofrecen opciones para limitar qué herramientas expone Hermes y para usar HTTPS si el daemon de MentisDB tiene TLS configurado. El procedimiento incluye arrancar mentisdbd, verificar el endpoint de salud y reiniciar Hermes para que detecte las herramientas disponibles.

Lo que podría venir después

La publicación adelanta que el plugin de proveedor nativo podría enviarse como pull request al repositorio de Hermes, con la intención de que venga incluido de forma predeterminada junto a otras integraciones ya presentes como Honcho, Mem0 y Hindsight.

En paralelo, los autores afirman que quieren trabajar con la comunidad de agentes para formalizar la interfaz MemoryProvider como una especificación compartida. La meta es que un backend de memoria implementado una sola vez funcione en cualquier framework compatible, sin adaptaciones mayores.

MentisDB es presentado como implementación de referencia para ese posible estándar. Si la idea prospera, la memoria podría convertirse en una capa intercambiable dentro del desarrollo de agentes de IA. Eso reduciría fricción para los equipos y facilitaría construir sistemas multiagente con recuerdos persistentes entre sesiones y plataformas.

Por ahora, se trata de una propuesta técnica con un ejemplo funcional, no de un estándar adoptado por toda la industria. Aun así, su relevancia radica en que aborda un cuello de botella concreto en el diseño de agentes. Si los frameworks quieren ser realmente interoperables, la memoria parece uno de los lugares más urgentes para empezar.


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