A maior parte dos agentes de IA roda um turno por vez. Você digita, eles respondem, eles esperam. O loop, quem roda é você. O agente não passa de uma chamada de função.
O Hermes Agent tem esse modo — é o padrão. Mas ele também traz outro modo, chamado /goal, em que o loop quem roda é o agente. Você define um objetivo mais critérios de sucesso, e o agente propõe, executa, avalia, tenta de novo e continua até um judge LLM separado concordar que os critérios foram atendidos. A v0.14.0 (16 de maio de 2026) acrescentou /subgoal pra você poder empilhar critérios extras num loop em andamento sem reiniciar (#25449).
Este post abre o capô do que tá rolando, quando essa é a ferramenta certa e quais são os modos de falha que fazem dela a errada.
O modo padrão (pra fins de contraste)
Cada sessão de chat no Hermes é um turno por mensagem do usuário. O agente lê sua mensagem, chama tools se precisar, depois devolve uma resposta. Se a tarefa não terminou, você precisa cutucar: "continua", "tenta de novo", "e o X?". O loop externo é você que faz.
Isso vai bem pra trabalho exploratório — "explica esse código", "rascunha uma nota", "acha um bug pra mim". Você quer que o agente pause depois de cada passo pra poder redirecionar.
Vai mal pra tarefas em que a condição de sucesso é concreta e o caminho até lá é iterativo. "Refatora esse módulo até o pytest passar" é uma tarefa de trinta turnos se você guiar cada turno. Com /goal vira um comando só.
O que o /goal faz de verdade
/goal Make all tests in tests/api/ pass. Don't change the test assertions. Done when pytest exits 0.
Quando você manda isso, três coisas acontecem:
- 1.O texto do objetivo vira o prompt-alvo do worker. Em cada turno seguinte, o modelo worker recebe uma system message que inclui o objetivo e a melhor tentativa atual.
- 2.Uma chamada de LLM "judge" separada roda depois de cada turno do worker. O judge vê o objetivo, o estado atual e a conclusão proposta. Ele devolve ou "done" (loop sai) ou "continua, ainda falta isso".
- 3.O loop continua até o judge dizer done — ou até você parar com
/stop, ou até bater no limite de iterações configurado.
O judge é a peça chave. Não é a mesma chamada de LLM do worker, e ele não vê a cadeia de raciocínio — só o objetivo e o estado atual. Essa separação é o que faz o /goal funcionar: um modelo worker que já se convenceu de que sua resposta tá certa é um juiz ruim. Uma chamada fresca de LLM sem contexto é bem melhor.
Esse padrão, dentro do codebase do Hermes, é chamado de "loop de Ralph", do pseudocódigo canônico while not done: do(work); ralph = judge(work). A extensão /subgoal da v0.14.0 deixa o usuário injetar novos critérios de judge num loop em andamento.
/subgoal — adicionando critérios em pleno voo
Você abriu um /goal pra refatorar um módulo. Três loops depois, você percebe que também quer que a refatoração mantenha a complexidade ciclomática abaixo de 10 por função. Não quer parar o loop e recomeçar.
/subgoal Each function must have cyclomatic complexity <= 10.
Da próxima vez que o judge rodar, ele leva essa restrição nova em conta. Se a melhor tentativa atual falhar nela, o loop continua. Se passar, o loop sai.
Esse é o tipo de feature que parece bobinha numa bullet de release notes — "critérios definidos pelo usuário acoplados a um /goal ativo" — e acaba virando coluna de sustentação pra quem usa o loop de verdade. Os objetivos reais vão sendo refinados enquanto você observa o agente trabalhar. Sem o /subgoal, o único jeito de refinar era /stop + redefinir + /goal de novo, perdendo o estado em andamento.
Exemplos práticos
Refatorar até os testes passarem
/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
O worker tenta refatorações, o judge checa as duas condições. Quando as duas estão no verde, o loop sai.
Iterar numa 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
O worker mexe no CSS, o judge tira um screenshot pelo tool de browser e confere. Dá pra rodar muitas iterações sem você ficar de babá.
Achar um 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.
O judge aqui tá conferindo se as duas partes do entregável existem — repro e explicação — não só se uma ou outra apareceu. /subgoal te deixa adicionar uma restrição tipo "a explicação tem que referenciar o ciclo de request/response correspondente" se o primeiro rascunho ficou vago demais.
Quando não usar
/goal é a ferramenta errada pra tarefas em que:
- •A condição de sucesso é nebulosa. "Deixa mais elegante" — o judge não consegue notar isso de forma consistente, então o loop oscila ou carimba qualquer coisa. Aqui usa turno-a-turno.
- •Você quer ver o trabalho enquanto ele acontece. Cada iteração roda até o fim antes do judge disparar, então você não tem a mesma visibilidade por turno. Se revisar no meio importa, usa turno-a-turno ou
/handoff. - •Custo importa mais que velocidade. Cada iteração de loop é uma chamada de worker mais uma chamada de judge. Pra um objetivo de 10 iterações, você paga 20 chamadas de LLM. Vale o ouro pra refatoração ; é desperdício pra "como eu chamo essa variável".
- •Você não pensou direito nos critérios de sucesso. Critério lixo → loop lixo.
/goalrecompensa especificidade, e o agente vai explorar qualquer ambiguidade.
Como /goal se combina com /handoff
A v0.14.0 também soltou o /handoff, que transfere uma sessão viva entre modelos sem perder contexto (#23395). Os dois se compõem: você consegue passar um goal em andamento de um modelo rápido pra um de raciocínio profundo quando o goal esbarra em algo que o rápido não resolve. O judge continua avaliando os mesmos critérios ; só o worker ficou melhor.
O mesmo vale pra /sessions (#20805) — você consegue interromper um goal, passear em outra sessão e retomar o goal depois. O estado do loop fica em checkpoint.
Onde isso encaixa no stack do agente
Três formas diferentes de trabalho autônomo, em ordem crescente de quanto você dirige o agente:
- 1.Turno-a-turno — você dirige, o agente responde. Conversacional.
- 2.
/goal— você define critérios, o agente roda em loop até cumprir. Autonomia com fronteiras. - 3.Agendamento por cron — o agente roda sem supervisão num horário, com entrega pra plataformas de mensageria. Autonomia sem fronteiras no tempo.
/goal é a do meio. É o alcance certo pra uma categoria de tarefa que antes exigia ou babá pesada ou um script feito sob medida. O /subgoal da v0.14.0 deixa o loop direcionável em pleno voo, e é isso que tira o recurso da prateleira de "interessante" e bota na de "ferramenta do dia a dia".