Ever handed Hermes a long task and then kept checking in every ten minutes to type “keep going”? Ever had the agent declare “done” — but you didn’t quite trust it, so you ran the tests yourself to verify? Ever wished Hermes would turn what it just did into a reusable skill, without waiting for its internal counter to decide it’s time?

On August 6, 2026, three new commands landed on Hermes Agent’s main branch that address exactly these pain points:

• /heartbeat — attach a recurring “alarm” to the current session. When the session is idle and the interval elapses, the prompt is injected as a normal user turn, so the agent keeps watching on its own.
• /refine — trigger the memory/skill self-improvement review on demand (no more waiting for the automatic counters), with optional focus instructions.
• /goal gate — attach deterministic quality gates to a persistent goal: a shell command must exit 0 before the goal can be judged done. An LLM’s “it’s finished” is no longer the final word.

All three are adapted from Prime Intellect’s Prime-Agent (/heartbeat, the Continual Harness, and --autonomous-gate), but the Hermes implementations plug into its own durable state — the memory + skill stores and SessionDB. Important: these commands were merged into main on 2026-08-06 and the official docs already cover them, but they are not yet in any formal release (the latest release is still v0.20.0). Everything in this article is verified against the official docs and the commit messages; you can try them today on a nightly build or wait for the next release.

If you have not used /goal yet, start with our Herald release deep dive and the hidden tricks roundup, which covers the basics of /goal.

1. /heartbeat: let the session wake itself up and work

/heartbeat gives the current session one recurring instruction. Whenever the session is idle and the interval has elapsed, the instruction is injected as a plain user-role message — same conversation, same context, same prompt cache. Nothing is swapped.

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

Once set, the session “wakes up” ten minutes later and executes it. The official docs give a very relatable example: you are coding in the same session while Hermes watches 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.

Commands and subcommands

Command	What it does
/heartbeat every <interval> <prompt>	Set (or replace) the session’s heartbeat. Intervals: 90s, 10m, 2h, 1d (minimum 60s).
/heartbeat or /heartbeat status	Show the heartbeat, its interval, and time to next fire.
/heartbeat pause	Stop firing without clearing.
/heartbeat resume	Resume (re-anchors the timer — no instant stale fire).
/heartbeat clear	Remove the heartbeat.

/hb is an alias. It works on the CLI and every gateway platform (Telegram, Discord, Slack, …); on Slack write /hermes heartbeat ....

Key behavior details

• Idle-only. A heartbeat never interrupts a running turn; a tick that comes due while the agent is busy fires at the next idle poll.
• Missed ticks coalesce. If the session was busy (or the process wasn’t running) across several intervals, you get one heartbeat turn, never a backlog.
• User messages win. A queued real user message always takes priority; the heartbeat waits for the input queue to drain.
• Cache-safe. The injected prompt is an ordinary user message — no system-prompt mutation, no toolset change, prompt caching stays intact.
• Don’t-invent-work guard. The injected prompt tells the agent to reply briefly and stop when nothing meaningful changed, so an idle heartbeat doesn’t generate busywork.
• Persistence. State lives in SessionDB.state_meta keyed by heartbeat:<session_id> — it survives /resume and context-compression rotation. Firing requires the owning process (CLI session or gateway) to be running; for schedules that must survive anything, use cron.

/heartbeat vs cron: which one do I want?

	/heartbeat	hermes cron
Runs in	This conversation — full context, memory of the discussion	A fresh isolated session per tick
Survives process restart	State survives (SessionDB); firing resumes next time the session is driven	Yes — fully durable scheduler
How many	One per session	Unlimited jobs
Best for	“Keep an eye on X in this thread while we work”	Standing jobs, reports, watchdogs, deliveries

Rule of thumb: if the recurring prompt needs the conversation’s context, use /heartbeat. If it’s a self-contained job, use cron. They complement each other.

2. /refine: run the self-improvement review when you want it

Hermes ships a background self-improvement mechanism: every N turns (roughly 10 turns on the memory side, 10 iterations on the skill side), it spawns a background review between turns that distills the conversation into durable memory-store entries or skill-store skills. Great mechanism — but the timing is fixed. You can’t tell it “do this now, immediately.”

/refine is that “now”:

/refine

With no arguments, it fires the exact same background review as the automatic trigger — but on a snapshot, leaving your live conversation and prompt cache untouched, and reports the results when done.

The more interesting variant takes focus instructions:

/refine save the deploy workflow as a skill

The focus text is appended to the review prompt so the background fork prioritizes what you asked for. The review runs in a background thread against a snapshot of the conversation history — “learn while you keep chatting” works fine.

This is Prime-Agent’s Continual Harness concept mapped onto Hermes: Hermes’ equivalent durable state is the memory + skill stores, so the review fork is the natural landing point. Automatic post-turn reviews pass None as focus and their prompts are byte-identical to before — the new command changes nothing about the automatic reviews, it just adds a manual entry point.

Practical use cases:

• Just got a complex deployment flow working: /refine save the deploy workflow as a skill, let it distill the steps into a reusable skill in the background.
• Notice your prompting style keeps tripping the agent at the same kind of step: /refine review how I phrase change requests, steer the review at that specific pain point.
• End of a long session: run a blanket /refine to archive the whole conversation’s takeaways.

3. /goal gate: make “done” a machine verdict, not a prose judgment

By default, /goal completion is decided by a judge model reading the conversation — that’s already good, but “prose” is probabilistic by nature. A quality gate is stronger: a deterministic shell command that must exit 0, or the goal cannot be judged done at all.

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

How gates run, each turn

1. Gates run before the judge. If any gate fails, the judge is not called — a red gate is deterministic evidence the goal isn’t done. The gate’s exit code and output tail (last ~3 KB) become the continuation prompt, so the agent iterates against the actual failure instead of a vibe.
2. All gates pass → normal judging. The LLM judge then decides done/continue/wait exactly as before.
3. Unchanged workspace → no re-run. If a gate failed and nothing changed in the workspace since (tracked via a git fingerprint of HEAD + working-tree status), the gate is not re-run — the recorded failure is replayed and the attempt count advances. A stuck agent can’t burn wall-clock re-running an identical red suite. Outside a git repo, gates simply always re-run.
4. Retries are bounded. Each gate defaults to 3 retries and a 5-minute timeout. When a gate exhausts its retries, the goal auto-pauses (like the turn budget) with a message telling you to fix it manually, remove the gate, or /goal resume.

Commands

Command	What it does
/goal gate add <command>	Add a quality gate.
/goal gate or /goal gate list	List the goal’s gates and their pass/fail state.
/goal gate remove <N>	Remove the Nth gate (1-based).
/goal gate clear	Remove all gates.

Gates persist with the goal in SessionDB.state_meta (they survive /resume and context compression), and gate management is safe mid-run — gates only execute at turn boundaries.

How do gates compose with Completion Contracts?

Completion Contracts (introduced in v0.18.0) make the agent declare its own completion criteria and prove it met them — they shape what the agent aims for. Quality gates work at the mechanism level: they make “done” mechanically checkable. The two compose:

• use a contract to shape what the agent aims for,
• use gates to make “done” mechanically checkable,
• when both are set, gates run first — mechanical checks always beat prose verdicts.

Combined with /subgoal and /goal wait <pid> [reason] (park the loop on a background process and auto-resume when it exits), the /goal family is now a complete “execute autonomously + verify autonomously” system.

4. Putting it together: a full hands-free workflow

Stitch all three together and a classic “sleep now, review in the morning” session looks like this:

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

The session then runs itself: work → gate check → on failure, iterate against the real error output → once green, the judge declares done → the heartbeat reports every 30 minutes (you glance when you feel like it) → finally /refine turns the debugging experience into a skill. You just read the results the next morning.

To go further, attach the same combination to a gateway (say, Telegram) and pair it with our webhook business-notifications guide to push “done/failed” events to your team — a full hands-free CI companion.

5. Caveats and boundaries

• The process must be alive. Both /heartbeat and /goal loops depend on their owning process (CLI session or gateway). For fully durable, cross-process scheduling, use hermes cron.
• Gates need a workspace they can fingerprint. The unchanged-workspace skip relies on the git fingerprint; outside a git repo, gates simply re-run every turn.
• Don’t use heartbeat as a cron replacement. It is “watch this thread with context”, not a general scheduler; one heartbeat per session is deliberate.
• Release status. The three commands are on main (merged 2026-08-06), not yet in a formal release. Until you upgrade to a build that includes them, /heartbeat, /refine, and /goal gate will report unknown commands — expected behavior.

Conclusion

Individually, /heartbeat, /refine, and /goal gate are small. Together they complete the last three pieces of the hands-free autonomy puzzle: watch, learn, verify. Combined with the existing /goal, /subgoal, Completion Contracts, and cron, Hermes moves from “you command, it executes” to “you define the rules, it works, improves, and proves it is done by itself.”

For more frontier-feature coverage like this, follow our blog; for the complete capability map, the official docs are the authoritative source.