How the /loop Command in Hermes Agent Automates Status Checks
A hands-on look at Hermes Agent's /loop feature, which lets a local AI agent watch time-dependent tasks on a timer and report back automatically.
What is the /loop command in Hermes Agent?
The /loop command is a feature in Hermes Agent, an open-source agentic framework, that lets an AI agent monitor something on a recurring timer instead of waiting for a human to keep asking “check again.” You set a prompt once, and the agent wakes itself up at set intervals, reads the current state of whatever it’s watching, does the work, reports back, and goes quiet until the next cycle. It’s built for jobs where the world changes on its own schedule and someone just needs to keep an eye on it.
TL;DR
- Hermes Agent’s /loop feature turns a one-time prompt into a recurring check, waking the agent on a timer instead of requiring manual “check again” messages.
- The feature ships with configurable timing parameters including a minimum interval, a maximum number of wake-ups, and floor/ceiling values that control self-paced backoff when nothing is changing.
- Stop conditions are flexible: you can cap the loop at a fixed number of runs, give it a natural language condition like “stop when the deploy is live,” route it through a judge model, or let the agent decide on its own when the job is finished.
- A hands-on demo ran /loop against a locally hosted Qwen3.8 27B model served through llama.cpp, watching a simulated four-stage deployment pipeline (queued, building, deploying, live) with no cloud API involved.
- The agent read a status file every 30 seconds, reported each stage change, and automatically stopped once it detected the “live” state, closing the loop cleanly after five wake-ups.
- Midway through the demo, the agent adapted its own method, switching from reading the file directly to checking its modification timestamp once it noticed repeated reads were returning duplicate content.
- /loop is one of three related but distinct mechanisms in Hermes Agent: loop is timer-driven for watching, goal is judge-driven for fixing, and cron is for unattended jobs that need to survive a closed terminal.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
How does the /loop feature actually work?
At its core, /loop gives Hermes Agent a self-managed timer. Instead of a person triggering each check, the agent wakes up on a schedule, re-reads the current state fresh (a file, a command output, a piece of the filesystem), performs whatever task the prompt describes, and reports the result. Then it goes back to sleep until the next scheduled wake-up.
The behavior is controlled through a small set of parameters in the loop’s config:
- A minimum interval, which sets the fastest the loop is allowed to fire (for example, not faster than every 30 seconds).
- A max wakes value, which acts as a hard stop after a set number of cycles, so the loop doesn’t run forever by accident.
- Floor and ceiling values that control adaptive backoff. The loop can start checking frequently and then slow down automatically if nothing is changing, easing off toward a longer interval like once every couple of minutes.
This adaptive pacing matters because it means you don’t have to hand-tune the check frequency for every situation. The agent starts attentive and backs off on its own when there’s nothing new to report, which keeps it from wasting cycles hammering an unchanged file.
How do you set up a /loop profile in Hermes Agent?
Setting up a loop starts with creating a profile, the same way you would for any other Hermes Agent task. That means specifying the provider (which can be a custom, self-hosted endpoint), the model, its context settings, and the working directory. Once the profile exists, the loop-specific settings get added to that profile’s config file: the interval, the max wake count, and the floor/ceiling backoff values described above.
After the profile is configured and confirmed to be responding correctly, you launch Hermes Agent against it and give it a natural language prompt describing what to watch and what “done” looks like. In a demonstrated example, the agent was told to check a status file every 30 seconds, report the current stage, and end its reply with a specific phrase once it saw the deployment reach a “live” state, which also served as the signal for the loop to stop itself.
One practical note from the demo: Hermes Agent needs to be current for /loop to be available at all, since it’s a recent addition. Anyone testing it should update their installation first, since older versions won’t have the command.
What does a real /loop run look like in practice?
To show the feature working against something real, a simple shell script was used to simulate a deployment pipeline moving through four stages: queued, building, deploying, and live, with a delay between each transition. This gave the agent something with genuine, unpredictable timing to watch, similar to how a real CI/CD pipeline behaves.
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
Once the loop prompt was set, the agent confirmed the loop was active, reported when the first wake-up would fire, and then handled everything from there without further input. On each wake-up, it read the status file fresh, reported whatever stage the deployment was in, and went back to sleep until the next check. Over the course of five wake-ups, it tracked the pipeline moving from queued through building and deploying, and finally reported “live,” at which point it appended the stop phrase and the loop shut down on its own.
Notably, partway through the run the agent changed its own approach: rather than reading the whole file each time, it started checking the file’s modification timestamp with a stat command. It made this switch after noticing that repeated reads of an unchanged file were being deduplicated, an adjustment it made without being told to.
How is /loop different from /goal and cron jobs in Hermes Agent?
Hermes Agent has three mechanisms that can look similar on the surface but are meant for different problems:
/loop is timer-driven. It’s the right tool when something external is changing on its own schedule and the job is simply to watch it and report, not to force any particular outcome.
/goal is judge-driven. It’s meant for situations where there’s a specific objective and the agent should keep working, retrying, and adjusting until that objective is verifiably met, rather than checking on a fixed interval.
cron is for tasks that need to keep running even if a terminal session closes. It operates outside any active session entirely, making it suited to long unattended jobs rather than interactive monitoring.
A simple way to decide between them: if you’re watching something, use loop. If you’re fixing or completing something, use goal. If the job needs to survive after you’ve closed your terminal, use cron.
Is the /loop feature useful for local model setups?
The demo ran entirely against a locally hosted model served through llama.cpp, with no cloud API key involved at any point. That matters for anyone running agentic workflows on their own hardware, since it shows the loop mechanism doesn’t depend on a hosted model provider to function. As long as the local model can be served through an OpenAI-compatible or custom endpoint that Hermes Agent can point to, the same timer-driven monitoring behavior applies.
For workflows like watching a deployment pipeline, monitoring a log file for a specific error, or checking whether a long-running job has finished, this removes the need to keep a terminal open and manually re-prompt a model every few minutes. The loop handles the polling, the state comparison, and the reporting on its own.
Frequently Asked Questions
What is Hermes Agent?
Hermes Agent is an open-source agentic framework that gives AI models access to a terminal, file system, web tools, memory, and the ability to carry out multi-step tasks, effectively acting as an operating layer between a model and real-world actions.
Does /loop require a cloud-based model?
No. The feature was demonstrated running against a locally hosted model served through llama.cpp, with no external API key required.
How does the loop know when to stop?
Stop conditions can be a fixed number of wake-ups, a natural language condition evaluated by the agent or a separate judge model after each wake-up, or the agent’s own determination that the task is complete.
What’s the difference between /loop and /goal?
/loop is timer-driven and suited to watching something that changes on its own schedule. /goal is judge-driven and suited to actively working toward a specific outcome until it’s verified as done.
Can the loop adjust its own checking frequency?
Yes. The configuration includes floor and ceiling values for backoff, allowing the loop to start with frequent checks and automatically slow down if it detects no changes over time.
