La mayoría de interfaces de chat con IA que has usado no tienen memoria de verdad. Tienen una ventana de contexto, que es algo muy distinto. Lo que dijiste antes en la misma conversación sigue delante del modelo. Lo que dijiste en la conversación de ayer, desapareció. Al día siguiente empiezas de cero y el asistente se presenta como un desconocido.
Hermes Agent es diferente. Tiene una capa de memoria real — separada del contexto de conversación — que aprende cosas sobre ti con el tiempo, las lleva de una sesión a otra y de una plataforma a otra, y hace que el bot se comporte como la misma entidad cada vez que hablas con él. Este artículo explica cómo funciona todo eso, qué decisiones importan, y qué cambió la interfaz de memoria conectable de v0.7.0.
Memoria a corto plazo vs memoria a largo plazo
Primero, la distinción que importa.
La memoria a corto plazo en Hermes es la ventana de contexto de la sesión. Es un fragmento del historial de conversación que el agente está manteniendo, gestionado con una estrategia proactiva de compresión: cuando el contexto se acerca al límite del modelo, Hermes ejecuta un paso de resumen que colapsa los turnos más antiguos en un resumen estructurado, manteniendo los intercambios más recientes intactos. La compresión se ha ido afinando en varias versiones — resúmenes estructurados con actualizaciones iterativas en la v0.4.0, protección de cola por presupuesto de tokens, endpoint de resumen configurable y soporte de modelo de respaldo. En conversaciones largas, esto mantiene al agente rápido y barato sin perder contexto importante.
La memoria a largo plazo es la parte interesante. Es un almacén de hechos, preferencias, correcciones y modelos de usuario que vive fuera de la conversación. Cuando le dices al bot "me llamo Alice" por Telegram hoy, ese hecho se escribe en la memoria a largo plazo. Mañana, cuando le preguntes algo por Slack, ese hecho se recupera y se inyecta en el contexto antes de que el agente vea tu mensaje. El modelo sigue recibiendo solo lo que cabe en su ventana, pero la ventana viene preparada con las cosas que debería saber sobre ti.
La memoria a corto plazo es un buffer. La memoria a largo plazo es una persona.
Honcho: qué es y por qué importa
El proveedor de memoria a largo plazo por defecto en Hermes es Honcho, una librería construida específicamente para memoria nativa de IA. El trabajo de Honcho es funcionar detrás del agente y hacer tres cosas concretas:
- 1.Observar. Cada mensaje del usuario y cada respuesta del agente alimentan a Honcho como un flujo de eventos. Honcho construye un modelo interno del usuario a partir de ese flujo — no historial de chat en crudo, sino hechos y preferencias estructurados inferidos de la conversación.
- 2.Razonar sobre el usuario. Honcho ejecuta una pequeña capa "dialéctica" que intenta construir una imagen coherente de quién eres, qué quieres y qué has corregido. No es simple extracción de palabras clave — es un modelo mental continuo del usuario.
- 3.Inyectar. En cada nuevo turno, Honcho produce un breve fragmento de contexto resumiendo lo que cree que importa sobre el usuario, que Hermes añade al principio del system prompt. El fragmento cambia a medida que Honcho aprende más.
Hay dos detalles que vale la pena señalar porque son fáciles de pasar por alto.
Primero, las escrituras en Honcho son asíncronas. El agente no se bloquea esperando una escritura de memoria. Responde, y la capa de memoria procesa el intercambio en segundo plano. Esto significa que las conversaciones largas no pagan un impuesto de latencia por las actualizaciones de memoria, y una caída del backend de memoria no para al bot — pierdes las actualizaciones durante la caída, pero el asistente sigue hablando.
Segundo, la recuperación de Honcho se mantiene fuera del prefijo de sistema cacheado. La función de prompt caching de Anthropic (usada intensamente en modelos como Claude Sonnet 4.6) necesita que el system prompt sea estable entre turnos para que la caché acierte. El fragmento inyectado por Honcho cambia turno a turno, así que Hermes lo añade deliberadamente después de la sección de sistema cacheada. La caché sigue funcionando para las partes estáticas; la capa de memoria dinámica sigue funcionando para las partes que cambian. Este es el tipo de equilibrio mecánico que no aparece en las notas de versión pero decide si tu factura mensual es de 50 o de 500 dólares.
Aislamiento multiusuario en modo gateway
El gateway de Hermes por defecto ejecuta múltiples usuarios a través del mismo proceso de agente. La memoria a largo plazo tiene que ser por usuario, o las alergias de Alice acaban en las sugerencias de cocina de Bob. La versión v0.3.0 añadió aislamiento multiusuario para Honcho dentro del gateway, lo que en la práctica significa:
- •Cada ID de usuario del gateway se mapea a un peer distinto de Honcho, y las escrituras de memoria van acotadas por peer.
- •Las sesiones de chat grupal heredan sesiones por usuario por defecto, así que un canal compartido sigue escribiendo flujos de memoria separados para cada participante.
- •El aislamiento de memoria por perfil (v0.5.0/v0.6.0) implica que si ejecutas varios perfiles de Hermes en la misma máquina, la memoria de cada perfil es un universo separado. Cambiar de perfil no filtra una persona a otra.
Nada de esto es visible para los usuarios. Todo ello es la razón por la que el bot no se acuerda accidentalmente de la persona equivocada.
La interfaz de memoria conectable (v0.7.0)
Durante las primeras cinco versiones de Hermes, Honcho estaba cableado. En la v0.7.0 la capa de memoria se refactorizó en una interfaz de proveedores — una pequeña ABC de Python que cualquier backend de memoria puede implementar. El cambio es arquitectónicamente modesto y prácticamente enorme.
La interfaz te permite intercambiar backends de memoria sin tocar el núcleo de Hermes:
- •Honcho es el proveedor de referencia (y sigue siendo el predeterminado). Es completo, ejecuta un modelo de usuario real y gestiona correctamente el aislamiento multiusuario.
- •Supermemory se añadió en la v0.8.0 como segundo proveedor de primera clase, con soporte multi-contenedor, modos de búsqueda configurables y plantillas de identidad.
- •mem0, OpenViking, RetainDB, Hindsight y ByteRover tienen plugins de memoria comunitarios en el sistema de plugins de Hermes, con distintos niveles de integración.
- •También puedes escribir el tuyo. La ABC es pequeña: implementa
write(),recall(), algunos hooks de ciclo de vida, y regístralo como plugin.
El proveedor de memoria integrado — el predeterminado sin dependencias si no has configurado nada — es un almacén de hechos respaldado por SQLite que cubre lo básico: escribir hechos, recuperarlos por relevancia, acotar por usuario. No es tan inteligente como Honcho, pero no necesita ningún servicio externo, y para un asistente personal en un VPS de 5 dólares suele ser todo lo que hace falta.
Lo que esto desbloquea en silencio
La memoria conectable es el tipo de cambio arquitectónico que parece trabajo de mantenimiento en las notas de versión. "Se refactorizó la memoria en una interfaz de proveedores" no es un titular. Lo que realmente hace es desacoplar la pregunta de "qué debería recordar un asistente de IA sobre ti" de la pregunta de "cómo funciona Hermes".
Ahora puedes reemplazar Honcho con un backend de memoria ajustado a tu caso de uso — un almacén vectorial para quien quiera búsqueda semántica sobre una base de conocimiento personal, una base de datos de grafos para quien quiera relaciones explícitas entre entidades, un almacén SQLite puramente local para quien no quiera que ningún dato de memoria salga de su máquina, un servicio de memoria interno de empresa para equipos. El agente no cambia. Solo cambia lo que hay detrás de la interfaz memory.
Esa es la abstracción correcta para un proyecto que quiere seguir existiendo dentro de unos años. La memoria es personal, y el backend de memoria correcto para ti no tiene por qué ser el correcto para nadie más. El trabajo de Hermes es ser un buen vecino de la capa de memoria que le enchufes, y apartarse de su camino.