Recurring Loops: Keep a Prompt Running in Your Session

The /loop command re-runs a prompt (or a slash command) on a recurring cadence inside your current session. Each wakeup is a real agent turn: Hermes reads the current state fresh — the latest CI result, the newest queue depth, the file as it is now — does the work, reports back, and goes quiet until the next tick. Where /goal is judge-driven ("keep working until this objective is achieved"), /loop is timer-driven: "do this again every N minutes until something says stop."

When to Use It

/loop shines whenever you want to keep an eye on something during a work session:

• Polling external state. "Watch the deploy / the CI run / the queue and tell me when it changes." This is the canonical use case.
• Iterate-until-green. "Run the tests, fix what fails, repeat until they pass."
• Monitoring during a work session. Keep an eye on error rates or a long job's progress while you do something else in the same conversation.
• Periodic housekeeping. Re-run a lint pass or a status summary every few minutes.

For work that must run unattended — overnight, on a real schedule, surviving restarts of your terminal — a cron job is the better fit. /loop lives inside a session; cron lives outside all of them. And when you have a single objective with a clear definition of done, /goal is usually the right choice.

Two Cadence Modes

• Fixed interval — you set the clock. Give an interval (30s, 5m, 2h) and the loop fires on that schedule. Use it when the thing you're watching changes on its own timeline: /loop 2m poll the build at ci.example.com/job/42.
• Self-paced — Hermes sets the clock. Omit the interval and the loop starts at the floor (1 minute by default), backing off exponentially — 2m, 4m, 8m, up to a 15 minute ceiling — while your replies keep coming back unchanged. The moment a reply differs from the last one, cadence snaps back to the floor. Change detection is a local digest comparison, so idle waits cost nothing extra: /loop keep an eye on the migration and summarize progress.

The rule of thumb: a fixed interval when an external clock drives the work; self-pacing when the work drives the rhythm.

Stopping a Loop

A loop ends when any of these fires:

• The agent decides it's done — the wakeup prompt teaches it to end its reply with LOOP_COMPLETE on its own line when the task is finished or moot.
• A run cap: --times N stops after N wakeups.
• An evidence-based condition: --until <condition> — after each wakeup, the same auxiliary judge that powers /goal checks the reply against your condition; if it rules the condition unachievable, the loop pauses with the reason instead of re-firing.
• /loop stop (or /loop pause to keep it around).
• The backstop budget loops.max_ticks (default 100) pauses the loop so an unattended session can't burn tokens forever.

Commands and Surfaces

The full command set is [interval] <prompt> [--times N] [--until <cond>] to start, plus /loop status, /loop pause, /loop resume, /loop stop — and /proactive as an alias for Claude Code parity. It works on the CLI, the TUI (hermes --tui), the web dashboard chat, the desktop app, and every gateway platform (Telegram, Discord, Slack, WhatsApp, and more). There is one loop per session, and setting a new /loop replaces the old one.

Mixing With /goal

Both features inject synthetic turns at idle boundaries, so they follow one rule: an active goal owns the session. While a /goal is actively driving, loop wakeups defer, resuming once the goal finishes or parks itself on a wait barrier. A parked goal plus a /loop is a natural combo: the goal waits on the big async thing while the loop keeps a heartbeat on something else. A real user message always wins over both — wakeups only fire while the session is idle. Loop state survives /resume and context compression, and a wakeup is a normal user-role turn with no system-prompt mutation, so prompt caching stays intact.

Configuration

Tuning lives in ~/.hermes/config.yaml under loops: — min_interval_seconds (30), max_ticks (100), self_paced_floor_seconds (60), and self_paced_ceiling_seconds (900). Remember that token cost scales with cadence: every tick is a full agent turn, so match the interval to how often the state actually changes and prefer self-pacing for idle waits.

Key Takeaways

• /loop re-runs a prompt on a recurring cadence inside your session, with each wakeup a real agent turn.
• Use it for polling, monitoring, and iterate-until-green work; cron handles unattended schedules.
• Choose fixed-interval or self-paced cadence (exponential backoff) to fit the work.
• Loops stop via LOOP_COMPLETE, --times, --until, /loop stop, or the max_ticks backstop.
• An active /goal takes priority over loop wakeups, so the two compose cleanly.