Ejecutas hermes update, reinicias el agente y le preguntas qué pasó con el refactor de ayer. Se queda un momento en blanco y responde que no tiene registro de nada. Abres config.yaml: memory.provider: honcho sigue justo ahí, y el bloque completo de memory.honcho está intacto. Lo único que falta es el código: el proveedor se ha mudado fuera del repositorio core, y tu actualización solo sustituyó la mitad que vivía en el core.

No se ha perdido nada. Lo que tienes delante es el tipo de fallo más desagradable que hay: una config que apunta a una implementación que ya no existe. El PR #114569, fusionado en main el 18 de septiembre de 2026, está hecho exactamente para ese estado: cuando Hermes detecta que el proveedor de memoria configurado no está, lo vuelve a instalar desde el plugin catalog con el pin revisado. Aquí tienes cómo toma la decisión, qué camino sigue la instalación, qué pasa cuando no puede instalar y si tú tienes que hacer algo.

Qué se mantiene igual: nombre, config y datos

La parte tranquilizadora de esta migración es que solo se mueve el código. Cuando un plugins/memory/<name> integrado pasa a ser un plugin independiente del catalog:

• el nombre del proveedor se mantiene (memory.provider: honcho sigue funcionando);
• la sección de config se mantiene (ninguna clave bajo memory.<name> se toca);
• el directorio de datos se mantiene (todo lo que tu agente recordaba sigue donde estaba);
• los nombres de las tools se mantienen (las instrucciones que guarda en su memoria sobre cómo usar la memoria no necesitan reaprenderse).

El único cambio es que el código ahora vive bajo HERMES_HOME/plugins/<name>. En teoría, el efecto visible para el usuario debería haber sido una reinstalación silenciosa. Este PR es lo que hace que esa teoría se cumpla.

Dos hooks: hermes update y el agent init

El nuevo módulo hermes_cli/memory_provider_migration.py expone un único punto de entrada, migrate_home(). Hace tres cosas: leer memory.provider de ese home, comprobar si el nombre todavía resuelve en alguno de los sitios donde Hermes busca (el directorio integrado, los plugins de usuario de ese home, un entry point) y, solo cuando no resuelve en ningún sitio, buscar una entrada del catalog con el mismo nombre. Las tres cosas tienen que encajar antes de instalar nada.

Dos puntos de llamada distintos cubren dos costumbres de actualización distintas:

• hermes update lo ejecuta para cada home de profile que comparte el virtualenv. Es el sitio natural: la actualización ya está reconstruyendo dependencias, y las dependencias de los plugins se vuelven a aplicar bajo los pins del core.
• El agent init lo ejecuta cuando load_memory_provider devuelve None —es decir, cuando el proveedor no se puede cargar en absoluto— una vez por proceso y por nombre. Este hook existe para los usuarios de escritorio, que actualizan desde la app y nunca lanzan hermes update a mano.

La instalación en sí pasa por el camino normal de instalación de plugins: el pin revisado de la entrada del catalog, la kill list, las restricciones de dependencias y el enable-on-install. Nada recibe un atajo por el hecho de ser automático, y la fuente revisada nunca se sustituye por una personalizada.

Aquí importa un interruptor. Como este paso instala código, respeta security.allow_lazy_installs (activado por defecto). Si lo desactivaste por motivos de seguridad, la migración automática no ocurrirá, y el log lo dice en lugar de dejar la memoria muerta en silencio.

Cuando no puede instalar: un comando de verdad, no una amnesia silenciosa

El mejor hábito de ingeniería de este cambio es que el fallo es visible e inmediatamente accionable. Tres caminos, tres salidas:

Situación	Comportamiento
El catalog no tiene ninguna entrada para ese proveedor	Un único aviso que nombra el comando exacto hermes plugins install <source> que hay que ejecutar, o que sugiere otro memory.provider
El catalog lo tiene, pero la instalación falla (red, uv, kill list)	El propio texto de error del instalador, más el mismo one-liner
security.allow_lazy_installs está desactivado	Una línea de log que indica que la config impidió la instalación automática

Antes de esto, el informe era una línea de nivel DEBUG y nada más, y por eso el síntoma visible para el usuario era simplemente «el agente de repente no recuerda nada». Dentro de la función hay además una regla deliberadamente contenida: nunca lanza una excepción. El comentario lo dice sin rodeos: que la memoria esté caída no puede llevarse por delante ni la actualización ni al agente.

Un pequeño arreglo de sintaxis de instalación del que depende la migración

El mismo PR hace que hermes plugins install owner/repo#subdir se parsee correctamente. Antes, el # quedaba pegado a la URL de clonado, así que ningún plugin que se distribuya en un subdirectorio de su repo principal podía instalarse de esa forma.

Esa sintaxis no es académica. Honcho distribuye su plugin dentro de su repositorio principal, así que su source después de la migración es plastic-labs/honcho#hermes-plugin-honcho; el de supermemory es supermemoryai/hermes-supermemory. El PR verificó todo el camino con una instalación real: con el honcho y el supermemory integrados borrados de un checkout de pruebas, memory.provider: honcho configurado y un AIAgent() de verdad, el agent init instaló plugins/honcho desde el repo del mantenedor con sus dependencias (honcho-ai, httpx) resueltas dentro de los pins del core, y lo cargó. El panel de configuración de escritorio de honcho siguió renderizando sus 33 campos, la CLI hermes honcho seguía detectándose y un segundo arranque no hizo absolutamente nada.

Qué hacer ahora: una comprobación de cinco minutos

Este PR son cimientos: por sí solo no quita nada del core. Pero la dirección es pública: los proveedores de memoria integrados van camino de los repos de sus mantenedores y del catalog (el PR menciona la conversación con los mantenedores de Hindsight, Honcho y Supermemory). Así que merece la pena saber en qué punto estás:

1. Mira qué proveedor ejecutas: hermes config get memory.provider. Si es uno de los integrados (honcho, supermemory, mem0 y compañía), apunta el nombre.
2. Comprueba si ahora mismo está integrado o es un plugin independiente: hermes plugins list. Después de una futura actualización, verlo instalado desde el repo del mantenedor es lo esperado, no un problema.
3. Si alguna actualización te deja al agente amnésico, ejecuta primero la línea hermes plugins install del log. Cuando la memoria vuelva, revisa hermes doctor para ver la salud de la base de datos de estado y del WAL: el diagnóstico de WAL grande que tratamos en la guía del live writer es el punto por el que empezar.

Si prefieres ver antes el panorama completo, la guía del plugin catalog y la referencia de hermes plugins explican cómo se revisan e instalan las entradas del catalog. Y si usas Honcho para el routing de sesiones y workspaces, los ajustes de esa guía de routing siguen funcionando sin cambios después de la migración.

Estado de la release

Estos commits se fusionaron en main el 18 de septiembre de 2026, y el tag más reciente es la v0.21.3 (nombre del tag v2026.9.14, publicado el 14 de septiembre), así que los hooks de migración todavía no están en ninguna release etiquetada. Las instalaciones git que ejecutan hermes update ya los tienen; los usuarios de imagen Docker y de la nube los recibirán con el próximo tag. Comprueba dónde estás:

hermes --version
hermes update

Como contexto, la página de la release v0.21.3 señala que las notas completas y curadas de todo lo posterior a la v0.21.0 llegan con la v0.22.0: cuenta con que el traslado del proveedor de memoria sea una de las secciones que merezca la pena leer allí.

La lección

Lo interesante no es la instalación automática, sino la clase de fallo que deja al descubierto: cuando una config referencia una implementación que se ha movido a otro sitio, el usuario no ve un error, ve desaparecer una capacidad en silencio. Hay tres hábitos que merece la pena copiar del arreglo: tratar «falta la implementación» como un estado de primera clase que conviene detectar, encaminar la reparación automática por la ruta ya revisada en lugar de por un atajo y, cuando la reparación es imposible, imprimir un comando que alguien pueda ejecutar de verdad, desde un código que tiene garantizado no llevarse por delante ni la actualización ni al agente.