Hermes Agent no recuerda tus conversaciones: cómo arreglarlo

Tu agente debía recordar

El lunes le contaste a Hermes Agent sobre tu proyecto. El miércoles se presenta como si nunca os hubierais visto. La promesa de la memoria persistente es la razón por la que elegiste un agente autoalojado en lugar de ChatGPT, y ahora parece la misma herramienta amnésica pero con más pasos de configuración.

La buena noticia es que el sistema de memoria de Hermes Agent es lo bastante simple como para diagnosticarlo desde fuera. MEMORY.md y USER.md son archivos markdown planos en disco. Si el agente no recuerda, está pasando una de cuatro cosas, y cada una tiene una solución concreta.

Cómo funciona realmente la memoria de Hermes Agent

Antes de diagnosticar, ayuda conocer la forma de lo que está roto.

Hermes Agent escribe dos tipos de memoria en el directorio de datos (normalmente ~/.hermes/memories/):

• MEMORY.md - notas curadas por el agente sobre tus proyectos, preferencias y flujos de trabajo. Está acotado a unos 2.200 caracteres, para que el modelo se vea obligado a priorizar.
• USER.md - un perfil estable de quién eres, tu rol, tu stack y tu estilo de comunicación.

Al inicio de cada sesión, el agente lee ambos archivos y los inyecta en el prompt del sistema. Durante la sesión, los actualiza automáticamente según lo que hayáis hablado. Cuando termina la sesión, los archivos siguen en disco.

Esa última frase es toda la promesa. Si los archivos no están en disco tras un reinicio, la memoria no está persistiendo. Si están y el agente sigue olvidando, hay otro problema. Son dos bugs distintos.

Para un recorrido más amplio del propio sistema de memoria, consulta cómo funcionan la memoria y las skills de Hermes Agent. Este post solo trata los modos de fallo.

Causa 1: El volumen de datos no está montado

Es, con diferencia, la causa más común. Síntoma: el agente funciona bien durante toda una conversación, recuerda todo lo que le dijiste hace cinco minutos, luego el contenedor se reinicia y se olvida de que existes.

Lo que pasa: los archivos de memoria se escriben dentro de la capa escribible del contenedor en vez de en un volumen persistente. Cuando haces docker stop y docker start, la capa escribible sobrevive. Cuando haces docker rm (o docker compose down, o el host se reinicia y recrea el contenedor), la capa escribible se destruye y MEMORY.md se muere con ella.

Comprueba primero: ¿existe realmente el directorio de memoria en tu host?

ls -la ~/.hermes/memories/

Si ese directorio está vacío o falta después de que el agente lleve un rato en marcha, el contenedor no está escribiendo ahí.

El arreglo: monta ~/.hermes como volumen. En docker run:

docker run -v ~/.hermes:/root/.hermes ...

En docker-compose.yml:

services:
  hermes:
    volumes:
      - ~/.hermes:/root/.hermes

Tras el cambio, recrea el contenedor (no solo lo reinicies) y verifica que el directorio de memorias se va poblando en el host mientras usas el agente. La guía de Docker de Hermes Agent cubre el docker-compose completo.

Causa 2: Volumen montado pero permisos mal

Montaste el volumen, el directorio existe en el host, pero los archivos siguen vacíos o los logs del agente mencionan "permission denied" al intentar escribir.

El contenedor y el host comparten el mismo espacio numérico de UID, y por defecto nada reconcilia esos números. Si tu agente corre como UID 1000 dentro del contenedor y el directorio del host es propiedad de root, la escritura falla en silencio. En Fedora, RHEL y otras distros con SELinux, la escritura se deniega incluso cuando los permisos Unix estándar la permitirían, y Docker no te avisará.

Comprueba la propiedad:

ls -ln ~/.hermes/memories/

Arreglo, Docker plano: haz que el directorio del host sea escribible por el mismo UID que usa el contenedor:

sudo chown -R $(id -u):$(id -g) ~/.hermes

Arreglo, hosts con SELinux: añade la etiqueta :Z al montaje del volumen para que Docker lo reetiquete para acceso desde el contenedor:

volumes:
  - ~/.hermes:/root/.hermes:Z

Arreglo, Docker rootless: el "root" del contenedor está mapeado a tu UID del host vía user namespaces, no al UID 0 real. El chown de arriba ya cubre este caso, pero el modelo mental confunde a la gente cuando intenta hacer sudo sobre el archivo y sigue fallando.

Causa 3: La ventana de contexto está llena, no el archivo de memoria

Síntoma: MEMORY.md está en disco, contiene las notas de tu proyecto, un cat muestra el contenido, y el agente actúa como si no recordara. Esto no es un bug de memoria. Es un bug de ventana de contexto disfrazado de memoria.

Hermes Agent lee MEMORY.md y USER.md en el prompt del sistema al inicio de la sesión, pero también arrastra el historial de la conversación actual en la misma ventana de contexto. Si el tamaño combinado supera el límite del modelo, los tokens más antiguos se truncan primero. Incluso antes del límite duro, aparece el efecto "lost in the middle": los modelos recuperan información de forma fiable al inicio y al final del contexto, y mucho menos de forma fiable en el medio.

Así que el archivo de memoria puede estar presente y correcto, pero en el turno 30 de una conversación larga, al modelo le llega una versión truncada o enterrada en el medio y se comporta como si nunca la hubiera visto.

Diagnósticos:

• Compara las ventanas de contexto de los modelos. Consulta el modelo que tienes configurado. Un modelo con ventana pequeña llegará antes a este límite que uno de 200k o 1M de tokens.
• Comprueba el tamaño de MEMORY.md. Si ronda el tope de 2.200 caracteres, está bien. Si una versión antigua de Hermes lo dejó crecer hasta 20k, recórtalo.
• Fíjate en la longitud de la sesión actual. Las sesiones únicas largas son más propensas a esto que las cortas y frecuentes.

Arreglos:

• Cambia a un modelo con más ventana de contexto en tu configuración.
• Recorta MEMORY.md a mano si ha crecido por encima de su tope.
• Reinicia la sesión periódicamente. Hermes lee la memoria en fresco al iniciar sesión, así que una sesión nueva carga MEMORY.md y USER.md en un contexto limpio.

El mismo modo de fallo se describe desde otro ángulo en la guía de troubleshooting de Telegram bajo "los mensajes llegan pero el agente ignora el contenido". Es el mismo bug de fondo en distintos canales.

Causa 4: Confusión entre memoria por chat y memoria global

Algunas configuraciones ejecutan un proceso de Hermes Agent por cada chat de Telegram, otras comparten memoria entre chats. Si le contaste algo al agente en un DM privado y no lo sabe cuando cambias a un grupo, estás ante un desajuste de alcance, no un bug de persistencia.

Diagnósticos:

• Revisa tu config. Si hay un patrón de directorio de datos por chat, la memoria está aislada por chat por diseño.
• Si estás en un setup autoalojado con un único ~/.hermes compartido entre chats, la memoria es global y deberías buscar la causa en otro sitio.
• Si estás ejecutando varios procesos de Hermes contra el mismo home para atender chats distintos, tienes otro problema muy distinto: dos escritores sobre el mismo MEMORY.md se pisan y el archivo acaba en un estado que ninguno de los dos escribió. No lo hagas.

Arreglo: decide qué modelo quieres y configúralo en consecuencia. La mayoría de operadores autoalojados quieren memoria global (un tú, un agente, todos los chats). Los despliegues multiusuario o multitenant suelen querer aislamiento por chat. Los dos son válidos, pero no son intercambiables.

Recuperación tras un reinicio mal hecho

Si MEMORY.md está corrupto, truncado a cero bytes o contiene contenido ilegible tras un crash o un apagado brusco, la ruta de recuperación es directa porque es un simple archivo markdown.

1. Para el agente antes de tocar el archivo. Un agente en marcha puede sobrescribir tu intento de recuperación.
2. Busca backups. Si seguiste las recomendaciones para migrar Hermes Agent a otra máquina, ya tienes snapshots periódicos de ~/.hermes. Restaura el snapshot bueno más reciente.
3. Edita a mano si hace falta. MEMORY.md es markdown. Ábrelo en un editor de texto, borra la sección corrupta y guarda. No hay ningún esquema que cumplir.
4. Arranca el agente y confirma que la memoria recuperada aparece en la siguiente sesión.

Si no tenías backups, este es el momento de montarlos. Un tar czf hermes-backup-$(date +%F).tar.gz ~/.hermes diario en cron tarda segundos y te compra una ruta de recuperación real para el próximo incidente.

Cuándo dejar de debuggear y delegar la infraestructura

Todos los arreglos de este post son pequeñas correcciones de cómo está cableado el contenedor. Ninguno es difícil por separado. Lo que quema tiempo es descubrirlos justo el día en que el agente se olvida de un proyecto de dos semanas a mitad de conversación, y darte cuenta de que el volumen no estaba montado, los permisos estaban mal y no hay ningún backup al que recurrir.

Si prefieres no volver a ver un "permission denied" en un log de Hermes, Hermify ejecuta un Hermes Agent gestionado en Telegram con los mismos MEMORY.md y USER.md, montados como corresponde, con backup nocturno y restaurables con un clic. Tu memoria sigue siendo tuya (los archivos están cifrados en reposo y son descargables), y el debug de montajes de volumen deja de ser tu problema.

Para una visión más amplia de cómo se resuelve el compromiso de despliegue, consulta hosting de Hermes Agent frente a autoalojarlo.

Empieza con Hermify y sáltate el checklist de persistencia de memoria por completo.

Fuentes

• Referencia de memoria de Hermes Agent
• Guía de Docker de Hermes Agent
• Problemas de permisos de volúmenes de Docker con contenedores no-root
• La ventana de contexto es RAM, no almacenamiento (Mem0)
• Ventanas de contexto de LLM y truncado (Redis)