Hast du Hermes schon einmal eine lange Aufgabe gegeben und dann alle zehn Minuten nachgeschaut, um „weiter so“ zu tippen? Hat der Agent schon einmal „fertig“ verkündet – aber du hast ihm nicht ganz vertraut und die Tests selbst ausgeführt, um es zu überprüfen? Hast du dir gewünscht, dass Hermes das, was es gerade getan hat, in ein wiederverwendbares Skill umwandelt, ohne auf seinen internen Zähler zu warten, der entscheidet, dass es an der Zeit ist?

Am 6. August 2026 sind drei neue Befehle auf dem main-Branch von Hermes Agent gelandet, die genau diese Schwachstellen adressieren:

• /heartbeat – hängt der aktuellen Session einen wiederkehrenden „Alarm“ an. Wenn die Session im Leerlauf ist und das Intervall verstrichen ist, wird der Prompt als normaler User-Turn injiziert, sodass der Agent von selbst weiter beobachtet.
• /refine – stößt das Self-Improvement-Review für Memory/Skills auf Abruf an (kein Warten mehr auf die automatischen Zähler), optional mit focus-Anweisungen.
• /goal gate – hängt deterministische Quality Gates an ein persistentes Goal: Ein Shell-Befehl muss mit Exit-Code 0 enden, bevor das Goal als erledigt beurteilt werden kann. Ein „ist fertig“ eines LLM ist nicht länger das letzte Wort.

Alle drei sind von Prime Intellects Prime-Agent adaptiert (/heartbeat, das Continual Harness und --autonomous-gate), aber die Hermes-Implementierungen greifen auf seinen eigenen dauerhaften Zustand zu – die Memory- und Skill-Stores sowie SessionDB. Wichtig: Diese Befehle wurden am 2026-08-06 in main gemergt und die offizielle Dokumentation deckt sie bereits ab, aber sie sind noch in keinem offiziellen Release enthalten (das neueste Release ist weiterhin v0.20.0). Alles in diesem Artikel ist gegen die offizielle Dokumentation und die Commit-Messages verifiziert; du kannst sie heute auf einem Nightly Build ausprobieren oder auf das nächste Release warten.

Falls du /goal noch nicht verwendet hast, starte mit unserem Deep Dive zum Herald-Release und der Übersicht verborgener Tricks, die die Grundlagen von /goal abdeckt.

1. /heartbeat: Die Session weckt sich selbst auf und arbeitet

/heartbeat gibt der aktuellen Session genau eine wiederkehrende Anweisung. Immer wenn die Session im Leerlauf ist und das Intervall verstrichen ist, wird die Anweisung als gewöhnliche Nachricht mit User-Rolle injiziert – gleiche Konversation, gleicher Kontext, gleicher Prompt-Cache. Es wird nichts ausgetauscht.

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

Nach dem Setzen „wacht“ die Session zehn Minuten später auf und führt die Anweisung aus. Die offizielle Dokumentation nennt ein sehr nachvollziehbares Beispiel: Du codierst in derselben Session, während Hermes die CI beobachtet:

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.

Befehle und Unterbefehle

Befehl	Funktion
/heartbeat every <interval> <prompt>	Setzt (oder ersetzt) den Heartbeat der Session. Intervalle: 90s, 10m, 2h, 1d (Minimum 60s).
/heartbeat oder /heartbeat status	Zeigt den Heartbeat, sein Intervall und die Zeit bis zum nächsten Auslösen.
/heartbeat pause	Stoppt das Auslösen, ohne zu löschen.
/heartbeat resume	Setzt fort (verankert den Timer neu – kein sofortiges veraltetes Auslösen).
/heartbeat clear	Entfernt den Heartbeat.

/hb ist ein Alias. Er funktioniert auf der CLI und auf jeder Gateway-Plattform (Telegram, Discord, Slack, …); in Slack schreibst du /hermes heartbeat ....

Wichtige Verhaltensdetails

• Nur im Leerlauf. Ein Heartbeat unterbricht nie einen laufenden Turn; ein Tick, der fällig wird, während der Agent beschäftigt ist, feuert beim nächsten Leerlauf-Poll.
• Verpasste Ticks werden zusammengefasst. War die Session über mehrere Intervalle beschäftigt (oder lief der Prozess nicht), bekommst du einen Heartbeat-Turn, nie einen Rückstau.
• User-Nachrichten gewinnen. Eine in der Warteschlange stehende echte User-Nachricht hat immer Vorrang; der Heartbeat wartet, bis die Eingabe-Warteschlange abgearbeitet ist.
• Cache-sicher. Der injizierte Prompt ist eine gewöhnliche User-Nachricht – keine Mutation des System-Prompts, keine Toolset-Änderung, das Prompt Caching bleibt intakt.
• Keine-Beschäftigung-Erfinden-Wächter. Der injizierte Prompt weist den Agenten an, kurz zu antworten und aufzuhören, wenn sich nichts Wesentliches geändert hat – so erzeugt ein Heartbeat im Leerlauf keine Beschäftigungstherapie.
• Persistenz. Der Zustand liegt in SessionDB.state_meta unter dem Schlüssel heartbeat:<session_id> – er übersteht /resume und die Rotation durch Context Compression. Zum Auslösen muss der zugehörige Prozess (CLI-Session oder Gateway) laufen; für Zeitpläne, die alles überstehen müssen, nimmst du cron.

/heartbeat vs. cron: Was will ich?

	/heartbeat	hermes cron
Läuft in	Dieser Konversation – mit vollem Kontext und Erinnerung an die Diskussion	Einer frischen, isolierten Session pro Tick
Übersteht Prozess-Neustart	Zustand überlebt (SessionDB); das Auslösen wird fortgesetzt, sobald die Session wieder gesteuert wird	Ja – vollständig dauerhafter Scheduler
Wie viele	Eine pro Session	Unbegrenzt viele Jobs
Am besten für	„X in diesem Thread im Auge behalten, während wir arbeiten“	Daueraufgaben, Reports, Watchdogs, Zustellungen

Faustregel: Wenn der wiederkehrende Prompt den Kontext der Konversation braucht, nimm /heartbeat. Ist es ein in sich abgeschlossener Job, nimm cron. Sie ergänzen sich.

2. /refine: Das Self-Improvement-Review ausführen, wann du willst

Hermes bringt einen Hintergrund-Self-Improvement-Mechanismus mit: Alle N Turns (ungefähr 10 Turns auf der Memory-Seite, 10 Iterationen auf der Skill-Seite) startet er zwischen den Turns ein Background Review, das die Konversation zu dauerhaften Einträgen im Memory-Store oder Skills im Skill-Store destilliert. Großartiger Mechanismus – aber das Timing ist fest. Du kannst ihm nicht sagen: „mach das jetzt, sofort.“

/refine ist genau dieses „jetzt“:

/refine

Ohne Argumente feuert es exakt dasselbe Background Review wie der automatische Auslöser – aber auf einem Snapshot, sodass deine Live-Konversation und dein Prompt-Cache unangetastet bleiben – und meldet die Ergebnisse, wenn es fertig ist.

Die interessantere Variante nimmt focus-Anweisungen entgegen:

/refine save the deploy workflow as a skill

Der Focus-Text wird an den Review-Prompt angehängt, sodass der Hintergrund-Fork priorisiert, worum du gebeten hast. Das Review läuft in einem Hintergrund-Thread gegen einen Snapshot des Konversationsverlaufs – „lerne, während du weiter plauderst“ funktioniert einwandfrei.

Das ist das Continual-Harness-Konzept von Prime-Agent, auf Hermes übertragen: Hermes’ Äquivalent zum dauerhaften Zustand sind die Memory- und Skill-Stores, also ist der Review-Fork der natürliche Landepunkt. Automatische Post-Turn-Reviews übergeben None als Focus, und ihre Prompts sind byte-identisch zu vorher – der neue Befehl ändert nichts an den automatischen Reviews, er fügt nur einen manuellen Einstiegspunkt hinzu.

Praktische Anwendungsfälle:

• Gerade einen komplexen Deployment-Ablauf zum Laufen gebracht: /refine save the deploy workflow as a skill – lass die Schritte im Hintergrund zu einem wiederverwendbaren Skill destillieren.
• Du bemerkst, dass dein Prompting-Stil den Agenten immer wieder an derselben Art von Schritt stolpern lässt: /refine review how I phrase change requests – lenke das Review auf genau diesen Schmerzpunkt.
• Am Ende einer langen Session: Führe ein pauschales /refine aus, um die Erkenntnisse der gesamten Konversation zu archivieren.

3. /goal gate: „fertig“ als Maschinen-Urteil statt Prosa-Einschätzung

Standardmäßig entscheidet ein Judge Model, das die Konversation liest, ob ein /goal erledigt ist – das ist schon gut, aber „Prosa“ ist naturgemäß probabilistisch. Ein Quality Gate ist stärker: ein deterministischer Shell-Befehl, der mit Exit-Code 0 enden muss, sonst kann das Goal überhaupt nicht als erledigt beurteilt werden.

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

So laufen Gates in jedem Turn ab

1. Gates laufen vor dem Judge. Scheitert ein Gate, wird der Judge nicht aufgerufen – ein rotes Gate ist deterministischer Beweis, dass das Goal nicht erledigt ist. Der Exit-Code des Gates und das Ende seiner Ausgabe (die letzten ~3 KB) werden zum Continuation-Prompt, sodass der Agent gegen den tatsächlichen Fehler iteriert statt gegen ein Bauchgefühl.
2. Alle Gates bestehen → normale Beurteilung. Der LLM-Judge entscheidet dann genau wie zuvor über done/continue/wait.
3. Unveränderter Workspace → kein erneuter Lauf. Wenn ein Gate fehlgeschlagen ist und sich seitdem nichts im Workspace geändert hat (verfolgt über einen Git-Fingerprint aus HEAD + Working-Tree-Status), wird das Gate nicht erneut ausgeführt – der aufgezeichnete Fehlschlag wird abgespielt und der Versuchszähler erhöht sich. Ein festhängender Agent kann keine Echtzeit damit verbrennen, eine identische rote Testsuite erneut laufen zu lassen. Außerhalb eines Git-Repos laufen Gates einfach immer erneut.
4. Retries sind begrenzt. Jedes Gate hat standardmäßig 3 Retries und ein Timeout von 5 Minuten. Wenn ein Gate seine Retries erschöpft, pausiert das Goal automatisch (wie beim Turn Budget) mit einer Nachricht, die dich auffordert, es manuell zu beheben, das Gate zu entfernen oder /goal resume auszuführen.

Befehle

Befehl	Funktion
/goal gate add <command>	Fügt ein Quality Gate hinzu.
/goal gate oder /goal gate list	Listet die Gates des Goals und ihren Pass/Fail-Status auf.
/goal gate remove <N>	Entfernt das N-te Gate (1-basiert).
/goal gate clear	Entfernt alle Gates.

Gates werden zusammen mit dem Goal in SessionDB.state_meta persistiert (sie überstehen /resume und Context Compression), und die Gate-Verwaltung ist auch während eines laufenden Goals sicher – Gates werden nur an Turn-Grenzen ausgeführt.

Wie kombinieren sich Gates mit Completion Contracts?

Completion Contracts (eingeführt in v0.18.0) zwingen den Agenten, seine eigenen Abschlusskriterien zu erklären und zu beweisen, dass er sie erfüllt hat – sie formen, worauf der Agent hinarbeitet. Quality Gates arbeiten auf Mechanismen-Ebene: Sie machen „fertig“ mechanisch überprüfbar. Beides kombiniert sich:

• einen Contract nutzen, um zu formen, worauf der Agent hinarbeitet,
• Gates nutzen, um „fertig“ mechanisch überprüfbar zu machen,
• wenn beides gesetzt ist, laufen die Gates zuerst – mechanische Checks schlagen immer Prosa-Urteile.

Zusammen mit /subgoal und /goal wait <pid> [reason] (die Loop an einem Hintergrundprozess parken und bei dessen Beendigung automatisch fortfahren) ist die /goal-Familie jetzt ein komplettes „autonom ausführen + autonom verifizieren“-System.

4. Alles zusammen: ein kompletter Hands-Free-Workflow

Setze alle drei zusammen, und eine klassische „schlaf jetzt, review am Morgen“-Session sieht so aus:

# ① 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

Die Session treibt sich dann selbst an: arbeiten → Gate-Check → bei Fehlschlag gegen die echte Fehlerausgabe iterieren → sobald alles grün ist, erklärt der Judge das Goal für erledigt → der Heartbeat berichtet alle 30 Minuten (du wirfst einen Blick, wann immer du willst) → schließlich macht /refine aus der Debugging-Erfahrung ein Skill. Du liest am nächsten Morgen einfach die Ergebnisse.

Um noch weiter zu gehen, hänge dieselbe Kombination an ein Gateway (etwa Telegram) und kombiniere sie mit unserem Webhook-Guide für Business-Notifications, um „done/failed“-Events an dein Team zu pushen – ein kompletter Hands-Free-CI-Begleiter.

5. Einschränkungen und Grenzen

• Der Prozess muss laufen. Sowohl /heartbeat- als auch /goal-Loops hängen von ihrem zugehörigen Prozess ab (CLI-Session oder Gateway). Für vollständig dauerhafte, prozessübergreifende Zeitplanung nutze hermes cron.
• Gates brauchen einen Workspace, den sie fingerabdrücken können. Der Überspringen-Mechanismus für unveränderte Workspaces beruht auf dem Git-Fingerprint; außerhalb eines Git-Repos laufen Gates einfach in jedem Turn erneut.
• Nutze den Heartbeat nicht als cron-Ersatz. Er ist „diesen Thread mit Kontext beobachten“, kein allgemeiner Scheduler; ein Heartbeat pro Session ist eine bewusste Entscheidung.
• Release-Status. Die drei Befehle sind auf main (gemergt am 2026-08-06), aber noch in keinem offiziellen Release. Bis du auf einen Build upgradest, der sie enthält, werden /heartbeat, /refine und /goal gate „unknown command“ melden – erwartetes Verhalten.

Fazit

Für sich genommen sind /heartbeat, /refine und /goal gate klein. Zusammen vervollständigen sie die letzten drei Puzzleteile der Hands-Free-Autonomie: beobachten, lernen, verifizieren. In Kombination mit dem bestehenden /goal, /subgoal, Completion Contracts und cron bewegt sich Hermes von „du befiehlst, es führt aus“ zu „du definierst die Regeln, es arbeitet, verbessert sich und beweist von selbst, dass es fertig ist.“

Für weitere Berichte über Frontier-Features wie diese folge unserem Blog; für die vollständige Fähigkeiten-Landkarte ist die offizielle Dokumentation die maßgebliche Quelle.