La mayoría de los agentes de IA van turno a turno. Tú escribes, ellos responden, esperan. El bucle lo llevas tú. El agente es solo una llamada a función.
Hermes Agent tiene ese modo — es el por defecto. Pero también trae otro modo, llamado /goal, donde el bucle lo lleva el agente. Tú pones un objetivo y unos criterios de éxito; el agente propone, ejecuta, evalúa, reintenta y sigue hasta que un judge LLM aparte da por cumplidos los criterios. v0.14.0 (16 de mayo de 2026) añadió /subgoal para que puedas apilar criterios extra sobre un bucle ya en marcha sin reiniciarlo (#25449).
Este artículo desmonta qué pasa de verdad por debajo, cuándo es la herramienta correcta y los modos de fallo que la convierten en la incorrecta.
El modo por defecto (para contrastar)
Cada sesión de chat en Hermes es un turno por mensaje de usuario. El agente lee tu mensaje, llama tools si toca, devuelve una respuesta. Si la tarea no está hecha, tienes que darle un empujón: "sigue", "vuelve a intentarlo", "¿y X?". El bucle exterior eres tú.
Esto va perfecto para trabajo exploratorio — "explícame este código", "redacta una nota", "encuéntrame un bug". Quieres que el agente pause tras cada paso para que tú reorientes.
No va para tareas con condición de éxito concreta y camino iterativo. "Refactoriza este módulo hasta que pytest pase" es una tarea de treinta turnos si tú vas conduciendo turno a turno. Con /goal es un comando solo.
Qué hace /goal en realidad
/goal Make all tests in tests/api/ pass. Don't change the test assertions. Done when pytest exits 0.
Cuando mandas eso, pasan tres cosas:
- 1.El texto del objetivo se convierte en el prompt diana del worker. En cada turno siguiente, el modelo worker recibe un mensaje de sistema que incluye el objetivo y el mejor intento actual.
- 2.Tras cada turno del worker corre una llamada LLM aparte de "judge". El judge ve el objetivo, el estado actual y el intento de completion. Devuelve "done" (el bucle sale) o "sigue, falta esto".
- 3.El bucle continúa hasta que el judge dice done — o hasta que lo paras con
/stop, o hasta que choca contra el límite de iteraciones configurado.
El judge es la pieza clave. No es la misma llamada LLM que el worker, y no ve la cadena de pensamiento — solo el objetivo y el estado actual. Esa separación es lo que hace funcionar a /goal: un modelo worker que ya se ha convencido de que su respuesta es correcta es un juez malísimo. Una llamada LLM fresca sin contexto lo hace mucho mejor.
Este patrón, interno al codebase de Hermes, se llama "bucle Ralph" por el pseudocódigo canónico while not done: do(work); ralph = judge(work). La extensión /subgoal de v0.14.0 deja que el usuario inyecte nuevos criterios para el judge en un bucle ya en marcha.
/subgoal — añadir criterios sobre la marcha
Arrancaste un /goal para refactorizar un módulo. Tres bucles dentro te das cuenta de que también quieres que la refactorización mantenga la complejidad ciclomática por debajo de 10 por función. No te apetece parar el bucle y volver a empezar.
/subgoal Each function must have cyclomatic complexity <= 10.
La próxima vez que corra el judge, mete esa nueva restricción en la ecuación. Si el mejor intento actual la suspende, el bucle sigue. Si pasa, el bucle sale.
Esta es la clase de función que parece pequeña en un bullet de release notes — "criterios añadidos por el usuario apilados a un /goal activo" — y resulta ser una viga maestra para cualquiera que use el bucle de verdad. Los objetivos reales se refinan mientras observas trabajar al agente. Sin /subgoal, la única forma de refinar era /stop + redefinir + /goal otra vez, perdiendo el estado en marcha.
Ejemplos prácticos
Refactorizar hasta que pasen los tests
/goal Refactor src/api/users.py so the User class follows the new naming convention in src/conventions.md. Don't break any existing tests. Done when:
1. pytest exits 0
2. The User class matches the convention rules in conventions.md
El worker prueba refactorizaciones, el judge comprueba las dos condiciones. Cuando las dos están en verde, el bucle sale.
Iterar sobre una UI
/goal Make the button on /pricing more prominent. Done when:
1. The button is the largest interactive element above the fold on desktop
2. It uses the primary brand color (#FF5A50)
3. Existing Lighthouse accessibility score doesn't drop
El worker edita el CSS, el judge saca una captura con la tool de browser y comprueba. Caben muchas iteraciones sin tener que estar tú vigilando.
Cazar un bug
/goal Find the cause of the intermittent test failure in tests/auth/test_session.py::test_logout_clears_cookie. Done when you produce a minimal failing repro and a one-paragraph explanation.
El judge aquí está comprobando que las dos partes del entregable existan — repro y explicación — no si aterrizó una u otra. /subgoal te deja añadir una restricción tipo "la explicación debe referenciar el ciclo request/response correspondiente" si el primer borrador es demasiado vago.
Cuándo no usarlo
/goal es la herramienta equivocada para tareas donde:
- •La condición de éxito es borrosa. "Hazlo más elegante" — el judge no puede puntuar eso de forma consistente, así que el bucle oscila o sella con goma de buzón. Aquí ve a turno a turno.
- •Quieres ver el trabajo según ocurre. Cada iteración corre hasta completarla antes de que dispare el judge, así que no obtienes la misma visibilidad por turno. Si la revisión a media corriente importa, usa turno a turno o
/handoff. - •El coste te importa más que la velocidad. Cada iteración del bucle es una llamada al worker más una al judge. Para un objetivo de 10 iteraciones, pagas 20 llamadas LLM. Vale la pena para refactorizar; es despilfarro para "¿cómo llamo a esta variable?".
- •No te has parado a pensar los criterios de éxito. Criterios basura → bucle basura.
/goalpremia la concreción y el agente explotará cualquier ambigüedad.
Cómo se entiende /goal con /handoff
v0.14.0 también lanzó /handoff, que transfiere una sesión viva entre modelos sin perder contexto (#23395). Los dos se combinan: puedes pasarle un goal-en-marcha de un modelo rápido a uno de razonamiento profundo cuando el objetivo choca con algo que el rápido no resuelve. El judge sigue puntuando los mismos criterios; el worker simplemente ha mejorado.
Lo mismo con /sessions (#20805) — puedes interrumpir un goal, irte a otra sesión a curiosear y retomar el goal después. El estado del bucle queda en checkpoint.
Dónde encaja esto en el stack del agente
Tres formas distintas de trabajo autónomo, ordenadas por cuánto conduces tú al agente:
- 1.Turno a turno — tú conduces, el agente responde. Conversacional.
- 2.
/goal— pones criterios, el agente entra en bucle hasta cumplirlos. Autonomía acotada. - 3.Programación con cron — el agente corre sin supervisión en un horario, con entrega a plataformas de mensajería. Autonomía sin tope en el tiempo.
/goal es la de en medio. Es el alcance justo para una clase de tareas que antes pedían o vigilancia pesada o un script a medida. /subgoal de v0.14.0 hace el bucle gobernable sobre la marcha, y eso es lo que lo convierte de curiosidad en herramienta diaria.