Loading...
Loading...
A field-tested operator playbook for the Hermes Agent unified cronjob tool: schedule dialects, delivery targets, the fail-closed wallet guard, no-agent mode, attached skills, and the recursion lock.
Continue the reading path
Topic hub
Runtime GovernanceThis page is routed through Armalo's metadata-defined runtime governance hub rather than a loose category bucket.
A builder-focused decision framework for the Hermes Agent delegate_task tool: when to delegate, how to size tasks, how to write context blocks the subagent can actually use, and how the concurrency ceiling shapes your design.
An operator reliability playbook for the most common Hermes Agent production failures: cron fail-closed, memory overflow, subagent context starvation, MCP probe failures, browser TTL, and provider fallback exhaustion, with concrete triage steps.
Curated Collection
Builder Guides
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
Scheduled tasks are where a conversational agent turns into an operator. Once a job can wake itself up, gather information, write files, send messages, or call tools without a human typing the next prompt, the agent stops being a search box and starts being a teammate. Hermes Agent's cron system is documented as a single unified surface (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron) rather than a pile of separate schedule, list, and remove tools, which is the right call for an operator who needs to reason about jobs as one category of object.
The two qualities that matter for a real operator are predictability and auditability. Predictability means the job runs when you expect, with the provider and model you expect, and writes back to a place you expect. Auditability means you can answer, later, why a job did what it did, who pinned it to what, and which skills or workdir were in scope. The cron system in the public docs is built around those two properties.
Hermes Agent exposes scheduled work through one tool with action-style operations instead of separate schedule/list/update/remove tools (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). The documented action vocabulary covers create, list, update, pause, resume, run, and remove, which means the same mental model applies whether you are scheduling from the chat surface, the standalone CLI, or asking in plain English.
Run Hermes on your agent right now — paste an endpoint, get a public 12-dimension scorecard, $99 keeps the seal live with a 30-day recheck.
Run Hermes — $99 →The chat-side command form is intentionally short. The published examples show patterns like /cron add 30m "Remind me to check the build" for ad-hoc intervals and /cron add "every 2h" "Check server status" for recurring ones, with a --skill <name> flag to attach a skill before the prompt runs (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). The standalone CLI mirrors the same arguments, which removes a class of "did I run this in chat or shell" bugs.
The natural-language path is documented as well: a sentence like "every morning at 9am, check Hacker News for AI news and send me a summary on Telegram" causes the agent to call the same cronjob tool internally (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). That is the right escape hatch for non-engineers, because it keeps the canonical artifact (the cronjob tool call) the same regardless of input form.
Cron expressions, short human intervals, and named one-shots are all supported in the public docs (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). every 30m, every 2h, 0 9 * * *, and every 1d at 09:00 are the documented shapes an operator will reach for first. Picking the right dialect is not a stylistic preference; it is a readability contract with the next person who has to debug the job at 2am.
| Dialect | Best for | Watch out for |
|---|---|---|
Short human intervals (every 30m, every 2h) | Readable recurring tasks the team owns | Drift across daylight saving boundaries unless you anchor to a wall-clock form |
Classic cron (0 9 * * *) | Calendar-aligned schedules and server-style ops | Requires the team to read cron; not as obvious as a natural interval |
| One-shot timestamp | Delayed execution, reminders, follow-ups | Easy to forget that one-shots still consume a job slot until they run |
Operators usually end up mixing the dialects rather than committing to one, and the documentation supports that without ceremony (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron).
The docs document delivery to the origin chat, to local files, or to a configured platform target, with the agent's final response as the default payload (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). The interesting design choice is that the cron system owns delivery rather than handing it off to an agent-callable tool; outbound delivery is "handled by cron's own delivery, the hermes send CLI, and the gateway notifier" per the tools documentation (https://hermes-agent.nousresearch.com/docs/user-guide/features/tools).
That separation matters when designing an operator workflow. The cron job should focus on the work (fetch, summarize, decide), and the delivery target should focus on who needs to see the result. If you find yourself wiring custom HTTP calls inside a cron prompt to send to Telegram, you are probably trying to bypass the documented delivery path. Move the destination into the job's deliver parameter instead.
The most important operational behavior in the public cron docs is the documented fail-closed rule for unpinned jobs (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). When a job is created without an explicit provider and model, it follows the global default selected by hermes model and the system snapshots that provider and model on the job. If the global default later changes, the job does not silently follow; it skips the run, makes no inference call, and sends an alert telling you to pin the provider and model explicitly.
This is the documented mitigation for the underlying issue tracked in the public repository (https://github.com/nousresearch/hermes-agent/issues/44585). The intent is that an unattended job cannot inherit an operator's switch to a paid provider or a more expensive model and silently burn money. The behavioral contract is therefore: either pin the provider and model at creation time, or accept that the job will refuse to run when the global default moves underneath it.
For unattended workloads, the documentation points at hermes setup --portal as the lowest-friction option because OAuth refresh is automatic (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). For jobs you want to deliberately track your global default, the documented remediation is to update them to the new provider and model values explicitly. This is one of the rare operator behaviors where the safest action is the more verbose one.
Skills can be attached to a cron job at creation time, and the documentation supports one skill or a list of skills loaded in order (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). When you attach a skill, the prompt becomes the task instruction layered on top of the skill's instructions, which is the right semantic: the skill brings reusable workflow scaffolding, and the prompt carries the per-job specifics.
The workdir parameter (or --workdir flag) is the documented way to bind a cron job to a project directory (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). When you set it, project context files from that directory are injected into the system prompt and the terminal, file, and code-execution tools use that directory as their working directory. Without it, jobs run detached from any repository.
The documented constraint is that workdir jobs are serialized, not parallel (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). The reason given is that the cron worker applies the job's workdir through process-global terminal state, so two workdir jobs running at the same tick would corrupt each other's working directory. Workdir-less jobs still run in the parallel pool, which is what most pure-monitoring jobs want anyway. The takeaway is to be deliberate about which jobs need a workdir and which do not.
The cron system explicitly disables cron management tools inside cron executions to prevent runaway scheduling loops (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). This is a hard guardrail, not a polite suggestion: a cron-driven agent cannot recursively create more cron jobs, which means a bug in the prompt cannot spawn an exponential schedule.
The operator implication is that any "schedule a follow-up if the answer is X" pattern needs to be expressed as a different mechanism. The practical replacements are a one-shot cron job pre-scheduled at creation time, a gateway hook reacting to a downstream event, or an external scheduler that the cron job can call but that the cron job itself cannot redefine. Designing with this constraint in mind is part of becoming a serious Hermes Agent operator.
A useful first set of jobs for a new operator usually looks like three things, not thirty. First, a daily morning brief that fetches two or three feeds and posts to your messaging channel. Second, a weekly stale-context sweep that asks the agent to look at a project directory and flag anything that has changed since last review. Third, a watchdog that runs a small shell script in no-agent mode every five minutes and only delivers when the script emits non-empty stdout (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron).
The metrics worth watching from day one are the four below. Track them in a notebook or a small dashboard; they are the early signals that the cron layer is healthy or that something has drifted.
| Metric | Threshold worth watching | Why it matters |
|---|---|---|
| Jobs that ran in the last 24 hours | Sudden drop to zero for any previously firing job | A dropped count is the first signal of the fail-closed skip or the recursion lock biting |
| Jobs that errored in the last 24 hours | More than 10 percent of total runs | A rising error rate is the first signal of provider degradation or token-cap exhaustion |
| Provider and model on each job | Any unpinned job after a global model change | An unpinned job is one provider switch away from a silent skip |
| Delivery target accuracy | Any job whose deliver parameter has been empty for more than a week | An empty deliver parameter is the first signal that nobody is actually reading the output |
That third pattern is worth dwelling on. The no-agent mode is documented as a way to run a script on a schedule with verbatim stdout delivery and zero LLM involvement (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). It is the right tool for "did the disk fill up", "did the certificate expire", "is the queue depth over N" — checks where there is nothing for a language model to add beyond passing the signal through. Reserve LLM-driven jobs for work where a language model genuinely adds value; everything else belongs in no-agent mode where cost and latency collapse to the script's footprint.
Unpinned jobs snapshot the global provider and model at creation time. When the global default changes, the job refuses to inherit the new values and skips the run with an alert, per the documented fail-closed behavior (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron).
No. Cron management tools are disabled inside cron executions as a recursion lock (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). Use a pre-scheduled one-shot, a gateway hook, or an external scheduler if you need chained timing.
No-agent mode runs a script on schedule and delivers its stdout verbatim without any LLM call (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron). A normal cron job starts a fresh agent session with the prompt and any attached skills, then delivers the agent's response.
A scheduled task is healthy when it (a) runs when you expect, (b) does not silently switch providers, (c) tells you when it skipped, (d) tells you which skills and workdir were in scope, and (e) cannot recursively spawn more jobs. The public cron surface is built to make each of those questions answerable; the operator's job is to use the surface as designed rather than building parallel systems that hide the answers. Each cron implementation is also a tradeoff between flexibility and predictability, and a good implementation surfaces that tradeoff in the implementation review rather than hiding it in a custom scheduler. The limitations of no-agent mode are the right counterweight for LLM-driven jobs, and the right implementation names the boundary between them instead of letting one bleed into the other.
The cron review most teams forget to schedule is the one on the cron jobs themselves. A weekly review of which jobs are still firing, which jobs are delivering to an audience that still reads them, and which jobs have an unpinned provider that is one model switch away from a silent skip is the implementation tradeoff that pays for itself within the first month. The source for each of those numbers is the scheduler's own job history, and the limitation of reading them by eye is what makes a small dashboard worth building before the first month ends. The evidence artifact for that review should name the rollback path, alert threshold, and failure mode that would make the operator pause or remove the job.
The same scorecard Armalo Pro agents are graded on. Run it against your agent today.
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
Explore the docs, register an agent, or start shaping a pact that turns these trust ideas into production evidence.
Loading comments…
A complete builder mental model for the three persistence layers in Hermes Agent: bounded MEMORY and USER memory files, on-demand skills, and deep-searchable session history, with the design rules that keep each layer from overflowing.
No comments yet. Be the first to share your thoughts.