Hermes /loop: recurring agent wake-ups with real stop conditions

Step-by-Step Breakdown

1. Update Hermes first — the feature is very recent

   Run hermes update before anything else. He is explicit that /loop is a recent addition and that an installation even slightly behind on commits simply will not have it. This is the single most likely reason the walkthrough fails to reproduce.

2. Create a profile for the loop

   He creates a profile called loop demo. Provider is set to custom, pointed at the local llama.cpp server, with the local Qwen 3.8 27B model and a current working directory. Nothing here is loop-specific yet — it is an ordinary Hermes profile.

3. Add the loop settings to the profile config

   Creating the profile writes a config file, and the loop behaviour is configured in its own section of that file (see Loop settings below). This is where the pacing and the hard stop live — the interval floor, the maximum number of wake-ups, and the self-paced backoff range.

4. Build something that actually changes state on its own schedule

   To demo a loop honestly you need a moving target. He writes a small shell script that simulates a deployment pipeline walking through four stages — queued, building, deploying, live — with a 60-second sleep between each, writing the current stage to a status file. The loop watches that file.

5. Start the fake deployer, then start Hermes alongside it

   The script runs in one terminal; Hermes is launched in parallel in another. The agent is not driving the deployment — it is observing something external, which is precisely the case /loop exists for.

6. Give the loop one prompt with an embedded stop condition

   The instruction is: check the status file every 30 seconds and report the stage; when the stage reads live, end the reply with loop complete. That trailing token is the stop condition — Hermes confirms the loop is set, tells you when the first wake-up will fire, and then runs unattended.

7. Walk away

   Five wake-ups later the loop closes itself. Each tick it read the status file fresh, reported the stage in one line, and went back to sleep: queued → building → deploying → live → loop complete. No terminal was touched after the initial prompt.

Loop settings shown in the profile config

These are the four knobs he walks through on screen. The behaviour is described exactly as demonstrated; check hermes's own documentation for the precise key spellings before you paste anything into a config file.

• Minimum interval — a floor on firing frequency. Set to 30 seconds in the demo, meaning the loop will never wake more often than that no matter what the prompt asks for.
• Maximum ticks — the hard stop. Set to 100 wake-ups; on hitting it the loop pauses itself rather than running forever. This is your runaway-cost backstop.
• Backoff floor and ceiling — the self-paced range. It starts checking every 30 seconds, and if nothing is changing it slows itself down to once every 2 minutes. A watcher on a quiet target costs progressively less.

The four stop conditions

This is the part that makes /loop more than a timer:

• A fixed number of runs — run exactly N times, then stop.
• A natural-language condition — "stop when the deploy is live". This is what the demo uses, expressed as a token the agent emits when it judges the condition met.
• A judge model — a separate model evaluates after every single wake-up whether the job is done.
• Agent's own judgement — let the agent decide when it is finished. This is the presenter's stated preference.

Gotchas & Caveats

• An out-of-date install silently lacks the feature. /loop is recent enough that this is the expected failure. Run hermes update first and confirm the version.
• The read tool deduplicates unchanged content. On the fifth wake-up the agent noticed it was re-reading a file whose content had not changed and switched, on its own, to checking the file's modification time with stat instead. Worth knowing if you are building a watcher whose target changes rarely — reading a file is not a reliable change signal, and a timestamp check is the sturdier probe.
• A loop watching nothing still costs tokens. The backoff ceiling is what bounds that, and the maximum-ticks value is what stops a forgotten loop from running indefinitely. Set both deliberately.

/loop vs /goal vs cron — the distinction that matters

All three look similar and solve genuinely different problems. This is the clearest articulation of the difference we have seen:

• /loop is timer-driven. Use it when something external is changing on its own schedule and you want the agent watching it.
• /goal is judge-driven. Use it when you have a specific objective and want the agent hammering on it until it is done.
• cron is for work that must survive your terminal closing. It runs outside any session entirely.

His rule of thumb: watching something → loop. Fixing something → goal. Scheduling something unattended → cron.

Commands & Code Shown

hermes update

hermes update

Purpose: Pulls Hermes up to the latest commits.

When to use: Before attempting /loop at all. The feature is new enough that a slightly stale install will not expose it, and the failure mode is a missing command rather than a helpful error.

/loop

/loop

Purpose: Starts a recurring, timer-driven wake-up that re-reads state fresh on each tick and stops on the condition you specify.

When to use: Watching an external process you do not control — a deployment, a build queue, a file that a different system writes.

stat

stat <file>

Purpose: Reads a file's metadata, including modification time.

When to use: As a change probe when the read tool's deduplication makes repeated file reads unreliable — which is exactly what the agent worked out for itself mid-run.

Key Takeaways

• The stop condition is the feature. A recurring timer is trivial; a recurring timer that knows when to stop — by tick count, by natural-language condition, by judge model, or by the agent's own call — is what turns polling into delegation.
• Fresh reads every tick are the point. Each wake-up re-reads the current state of the world rather than reasoning over a stale context, which is what makes it usable for genuinely time-dependent work.
• It runs fully local. The entire demo is Qwen 3.8 27B on llama.cpp with no API key — see best free models for Hermes and Hermes setup.
• Pick the right primitive. Watching → /loop; fixing → /goal; must survive the terminal closing → cron.
• Bound it before you walk away. Maximum ticks and the backoff ceiling are the two settings that keep an unattended loop from becoming an unattended bill.