¿Alguna vez le has dado a Hermes una tarea larga y luego has vuelto cada diez minutos a escribir «sigue»? ¿Alguna vez el agente ha declarado «listo» — pero no te fiabas del todo, así que ejecutaste tú mismo los tests para comprobarlo? ¿Alguna vez has deseado que Hermes convirtiera lo que acaba de hacer en un skill reutilizable, sin esperar a que su contador interno decida que ha llegado el momento?

El 6 de agosto de 2026, tres comandos nuevos aterrizaron en la rama main de Hermes Agent que abordan exactamente estos puntos débiles:

• /heartbeat — adjunta una «alarma» periódica a la sesión actual. Cuando la sesión está inactiva y transcurre el intervalo, el prompt se inyecta como un turno de usuario normal, de modo que el agente sigue vigilando por su cuenta.
• /refine — dispara la revisión de automejora de memoria/skills bajo demanda (sin esperar más a los contadores automáticos), con instrucciones opcionales de focus.
• /goal gate — adjunta quality gates deterministas a un goal persistente: un comando de shell debe terminar con exit code 0 antes de que el goal pueda darse por terminado. El «ya está» de un LLM ya no es la última palabra.

Los tres están adaptados de Prime-Agent de Prime Intellect (/heartbeat, el Continual Harness y --autonomous-gate), pero las implementaciones de Hermes se conectan a su propio estado duradero: los memory + skill stores y SessionDB. Importante: estos comandos se fusionaron en main el 2026-08-06 y la documentación oficial ya los cubre, pero aún no están en ningún release formal (el último release sigue siendo v0.20.0). Todo lo que aparece en este artículo está verificado contra la documentación oficial y los mensajes de commit; puedes probarlos hoy mismo en una nightly build o esperar al próximo release.

Si todavía no has usado /goal, empieza con nuestro análisis a fondo del release Herald y con el resumen de trucos ocultos, que cubre los fundamentos de /goal.

1. /heartbeat: deja que la sesión se despierte sola y trabaje

/heartbeat le da a la sesión actual una instrucción periódica. Siempre que la sesión esté inactiva y el intervalo haya transcurrido, la instrucción se inyecta como un mensaje normal con rol de usuario: misma conversación, mismo contexto, mismo prompt cache. No se intercambia nada.

/heartbeat every 10m Check the deployment and report meaningful changes

Una vez configurado, la sesión «se despierta» diez minutos después y lo ejecuta. La documentación oficial ofrece un ejemplo muy identificable: estás programando en la misma sesión mientras Hermes vigila la CI:

You: /heartbeat every 15m Check whether the CI run for PR #1234 finished; summarize the result when it does

  ♥ Heartbeat set (every 15m): Check whether the CI run for PR #1234 finished; ...

[15 minutes of you working on other things in the same session]

Hermes: [Heartbeat — recurring instruction, fires every 15m]
  💻 gh pr checks 1234   (1.2s)
  CI is still running (14/37 checks complete). Nothing to report yet.

Comandos y subcomandos

Comando	Qué hace
/heartbeat every <interval> <prompt>	Establece (o reemplaza) el heartbeat de la sesión. Intervalos: 90s, 10m, 2h, 1d (mínimo 60s).
/heartbeat o /heartbeat status	Muestra el heartbeat, su intervalo y el tiempo hasta la próxima activación.
/heartbeat pause	Detiene la activación sin borrarlo.
/heartbeat resume	Reanuda (reancla el temporizador: sin disparos obsoletos instantáneos).
/heartbeat clear	Elimina el heartbeat.

/hb es un alias. Funciona en la CLI y en todas las plataformas gateway (Telegram, Discord, Slack, …); en Slack escribe /hermes heartbeat ....

Detalles clave de comportamiento

• Solo en inactividad. Un heartbeat nunca interrumpe un turno en curso; un tick que vence mientras el agente está ocupado se dispara en la siguiente comprobación de inactividad.
• Los ticks perdidos se fusionan. Si la sesión estuvo ocupada (o el proceso no estaba en marcha) durante varios intervalos, recibes un turno de heartbeat, nunca una acumulación.
• Los mensajes del usuario ganan. Un mensaje real del usuario en cola siempre tiene prioridad; el heartbeat espera a que la cola de entrada se vacíe.
• Seguro para la caché. El prompt inyectado es un mensaje de usuario ordinario: sin mutación del system prompt, sin cambios en el toolset; el prompt caching permanece intacto.
• Protección contra trabajo inventado. El prompt inyectado le dice al agente que responda brevemente y se detenga cuando nada relevante haya cambiado, para que un heartbeat en inactividad no genere trabajo innecesario.
• Persistencia. El estado vive en SessionDB.state_meta con la clave heartbeat:<session_id>: sobrevive a /resume y a la rotación por context compression. Para que se dispare, el proceso propietario (sesión CLI o gateway) debe estar en marcha; para programaciones que deban sobrevivir a cualquier cosa, usa cron.

/heartbeat vs cron: ¿cuál me conviene?

	/heartbeat	hermes cron
Se ejecuta en	Esta conversación — contexto completo, memoria de la discusión	Una sesión nueva y aislada por cada tick
Sobrevive al reinicio del proceso	El estado sobrevive (SessionDB); el disparo se reanuda la próxima vez que se conduzca la sesión	Sí: programador totalmente duradero
Cuántos	Uno por sesión	Trabajos ilimitados
Ideal para	«Vigila X en este hilo mientras trabajamos»	Trabajos permanentes, informes, watchdogs, entregas

Regla práctica: si el prompt periódico necesita el contexto de la conversación, usa /heartbeat. Si es un trabajo autocontenido, usa cron. Se complementan entre sí.

2. /refine: ejecuta la revisión de automejora cuando tú quieras

Hermes incluye un mecanismo de automejora en segundo plano: cada N turnos (unas 10 vueltas en el lado de la memoria, 10 iteraciones en el lado de los skills), lanza una revisión en segundo plano entre turnos que destila la conversación en entradas duraderas del memory store o en skills del skill store. Buen mecanismo — pero el momento es fijo. No puedes decirle «hazlo ahora, inmediatamente».

/refine es ese «ahora»:

/refine

Sin argumentos, dispara exactamente la misma revisión en segundo plano que el disparador automático — pero sobre una instantánea, dejando intactas tu conversación en vivo y tu prompt cache, e informa de los resultados al terminar.

La variante más interesante acepta instrucciones de focus:

/refine save the deploy workflow as a skill

El texto de focus se añade al prompt de la revisión para que el fork en segundo plano priorice lo que pediste. La revisión corre en un hilo en segundo plano contra una instantánea del historial de la conversación: «aprende mientras sigues charlando» funciona de maravilla.

Este es el concepto del Continual Harness de Prime-Agent aplicado a Hermes: el estado duradero equivalente de Hermes son los memory + skill stores, así que el fork de revisión es el punto de aterrizaje natural. Las revisiones automáticas post-turno pasan None como focus y sus prompts son idénticos byte a byte a los anteriores: el comando nuevo no cambia nada de las revisiones automáticas, solo añade un punto de entrada manual.

Casos de uso prácticos:

• Acabas de conseguir que un flujo de despliegue complejo funcione: /refine save the deploy workflow as a skill, deja que destile los pasos en un skill reutilizable en segundo plano.
• Notas que tu estilo de prompting sigue haciendo tropezar al agente en el mismo tipo de paso: /refine review how I phrase change requests, orienta la revisión hacia ese punto débil concreto.
• Al final de una sesión larga: ejecuta un /refine general para archivar las conclusiones de toda la conversación.

3. /goal gate: que el «listo» sea un veredicto de máquina, no un juicio en prosa

Por defecto, la finalización de /goal la decide un judge model que lee la conversación — ya es bueno, pero la «prosa» es probabilística por naturaleza. Una quality gate es más fuerte: un comando de shell determinista que debe terminar con exit code 0; si no, el goal no puede darse por terminado en absoluto.

/goal Fix the flaky session tests
/goal gate add scripts/run_tests.sh tests/hermes_cli/test_goals.py

Cómo se ejecutan las gates, en cada turno

1. Las gates se ejecutan antes que el judge. Si alguna gate falla, el judge no se invoca: una gate en rojo es evidencia determinista de que el goal no está terminado. El exit code de la gate y la cola de su salida (últimos ~3 KB) se convierten en el prompt de continuación, de modo que el agente itera contra el fallo real en lugar de contra una corazonada.
2. Todas las gates pasan → juicio normal. El judge LLM decide entonces listo/continuar/esperar exactamente igual que antes.
3. Workspace sin cambios → sin re-ejecución. Si una gate falló y desde entonces nada cambió en el workspace (se rastrea mediante un git fingerprint del HEAD + el estado del working tree), la gate no se vuelve a ejecutar: se reproduce el fallo registrado y el contador de intentos avanza. Un agente atascado no puede quemar tiempo real re-ejecutando una suite en rojo idéntica. Fuera de un repositorio git, las gates simplemente se re-ejecutan siempre.
4. Los reintentos están limitados. Cada gate tiene por defecto 3 reintentos y un timeout de 5 minutos. Cuando una gate agota sus reintentos, el goal se pausa automáticamente (como con el turn budget) con un mensaje que te dice que lo arregles manualmente, quites la gate o ejecutes /goal resume.

Comandos

Comando	Qué hace
/goal gate add <command>	Añade una quality gate.
/goal gate o /goal gate list	Lista las gates del goal y su estado de aprobado/fallido.
/goal gate remove <N>	Elimina la gate número N (numeración desde 1).
/goal gate clear	Elimina todas las gates.

Las gates persisten junto con el goal en SessionDB.state_meta (sobreviven a /resume y a la context compression), y su gestión es segura a mitad de ejecución: las gates solo se ejecutan en los límites de turno.

¿Cómo se combinan las gates con los Completion Contracts?

Completion Contracts (introducidos en v0.18.0) obligan al agente a declarar sus propios criterios de finalización y a demostrar que los cumplió: dan forma a lo que el agente persigue. Las quality gates operan a nivel de mecanismo: hacen que el «listo» sea comprobable mecánicamente. Ambos se combinan:

• usa un contract para dar forma a lo que el agente persigue,
• usa gates para que el «listo» sea comprobable mecánicamente,
• cuando ambos están activos, las gates se ejecutan primero: las comprobaciones mecánicas siempre ganan a los veredictos en prosa.

Combinada con /subgoal y /goal wait <pid> [reason] (deja el bucle aparcado en un proceso en segundo plano y reanúdalo automáticamente cuando salga), la familia /goal es ahora un sistema completo de «ejecutar autónomamente + verificar autónomamente».

4. Juntándolo todo: un workflow totalmente sin supervisión

Une los tres y una sesión clásica de «duerme ahora, revisa por la mañana» queda así:

# ① Set the goal: make the test suite green and add a regression test
/goal Make scripts/run_tests.sh fully green and add a regression test for the session-close bug

# ② Attach quality gates: not done until the suite passes
/goal gate add scripts/run_tests.sh
/goal gate add git diff --exit-code --stat   # and require actual changes

# ③ Heartbeat: report progress every 30 minutes on its own
/heartbeat every 30m Summarize current goal progress and what you will do next; if nothing changed, reply briefly

# ④ At the end, distill the experience into a skill
/refine save the troubleshooting steps for session-close bugs as a skill

La sesión se ejecuta entonces sola: trabajo → comprobación de gates → si falla, itera contra la salida de error real → cuando está en verde, el judge declara el final → el heartbeat informa cada 30 minutos (echas un vistazo cuando te apetece) → finalmente /refine convierte la experiencia de depuración en un skill. Tú solo lees los resultados a la mañana siguiente.

Para ir más lejos, adjunta la misma combinación a un gateway (por ejemplo, Telegram) y combínala con nuestra guía de notificaciones de negocio por webhook para enviar eventos de «listo/fallido» a tu equipo: un compañero de CI totalmente sin supervisión.

5. Advertencias y límites

• El proceso debe estar vivo. Tanto el bucle de /heartbeat como el de /goal dependen de su proceso propietario (sesión CLI o gateway). Para programación totalmente duradera entre procesos, usa hermes cron.
• Las gates necesitan un workspace que puedan identificar. El salto por workspace sin cambios depende del git fingerprint; fuera de un repositorio git, las gates simplemente se re-ejecutan en cada turno.
• No uses el heartbeat como sustituto de cron. Es «vigila este hilo con contexto», no un programador general; un heartbeat por sesión es deliberado.
• Estado del release. Los tres comandos están en main (fusionados el 2026-08-06), todavía no en un release formal. Hasta que actualices a una build que los incluya, /heartbeat, /refine y /goal gate reportarán comandos desconocidos: comportamiento esperado.

Conclusión

Individualmente, /heartbeat, /refine y /goal gate son pequeños. Juntos completan las últimas tres piezas del rompecabezas de la autonomía sin supervisión: vigilar, aprender, verificar. Combinado con los ya existentes /goal, /subgoal, Completion Contracts y cron, Hermes pasa de «tú ordenas, él ejecuta» a «tú defines las reglas, y él trabaja, mejora y demuestra por sí mismo que ha terminado».

Para más cobertura de funcionalidades de vanguardia como esta, sigue nuestro blog; para el mapa completo de capacidades, los docs oficiales son la fuente autorizada.