Every Hermes Agent tip from witcheer at Nous Research, in his own words. Collected in one place and updated daily.
witcheer says each tip ran on a real Hermes box before it shipped. Hermes changes fast, so check your version and the linked doc.
Latest tip #113 · switch projects from the chat · Oct 29, 2026
start the schedule with "in" and the job runs one time:
hermes cron create "in 2h" "Remind me to call the dentist before they close."
your gateway runs it once, two hours from now, and the job then clears itself from your list. "in 30m" and "in 1d" work the same way.
handy for a call to return, a parcel to chase or a build to check later today!
docs: https://hermes-agent.nousresearch.com/docs/user-guide/features/cron
your Hermes Agent can run the same prompt again every few minutes, inside the chat you're already in.
type /loop, how often, then what it should check:
/loop 5m check build.log and tell me when the build is done
handy while a build or a deploy is running!
docs: https://hermes-agent.nousresearch.com/docs/user-guide/features/loops
it sets up a ready-made automation for your Hermes Agent. Hermes asks you what it needs, one question at a time, then schedules it as a cron job. you do not write any cron syntax.
want a short lesson on a topic you pick, every weekday morning?
type this in the chat:
/blueprint learn-daily
other blueprints cover a reminder in your own words, or a weekly meal plan with the grocery list!
/blueprint on its own lists every blueprint your Hermes Agent has.
docs: https://hermes-agent.nousresearch.com/docs/reference/automation-blueprints-catalog
one command stops your Hermes Agent from starting new work. while it is on:
hermes resume lifts it.
useful when a scheduled job does something you did not expect, or before you change a skill your cron jobs use!
docs: https://hermes-agent.nousresearch.com/docs/user-guide/features/cron#pausing-everything-hermes-pause
hermes -z --resume, one-shot calls that keep the threadyou call Hermes Agent from a script or a cron job with hermes -z: one prompt in, the final answer out, nothing else printed.
Hermes Wingtips #61: cron preflight
before a scheduled job runs, your Hermes Agent checks that the run can actually succeed: the provider key resolves, attached skills have what they need, delivery targets are reachable.
a job that fails the check is marked blocked_config and alerts you once. no model call happens, so it sits at zero cost until you fix it.
the next healthy run clears the state on its own.
Hermes Wingtips #55: chaining cron jobs
every cron job wakes up in a fresh session. a two-step pipeline, collect then summarize, can't see what step one produced.
context_from wires the connection. when you create the second job, point it at the first job's id, and the first job's latest output is prepended to the second job's prompt at fire time.
a job can also point at itself. continuity injects the job's own previous output.
you set all of this by asking your Hermes Agent in plain language, it manages its own cron table.
Hermes Wingtips #50: the [SILENT] marker
a monitoring job that reports every run trains you to ignore it. your Hermes Agent has a quieter contract: if a cron job's response contains [SILENT], delivery is suppressed and nothing lands in your chat.
the lever is the prompt itself:
"check if nginx is running. if everything is healthy, respond with only [SILENT]. otherwise, report the issue."
great for any check that should only speak up when something is wrong: uptime, disk space, backups, feed watchers!
Hermes Wingtips #47: cron prompts
your agent nails a task in chat, you schedule the same thing with /cron, and the scheduled runs come back wrong.
the reason is simple: a cron job runs in a fresh session, with none of the chat context that made the task work. a prompt leaning on what you discussed earlier has nothing to lean on at run time.
so write the prompt like the agent has never met you: every url, every command, every rule spelled out inside the prompt itself.
this is also why a scheduled job cannot ask you clarifying questions, it answers with what the prompt gave it!
Hermes Wingtips #28: cron jobs & workdir
a cron job runs in a completely fresh session, detached from any repo: no AGENTS.md is loaded, and the terminal and file tools start from wherever the gateway happens to be running.
the fix is one flag:
(1) hermes cron create "every 1d at 09:00" "audit open PRs, summarise CI health" --workdir /home/me/projects/acme
(2) or from the chat directly, just tell Hermes which directory the job should run in (the cronjob tool takes workdir= the same way)
with workdir set, the job loads AGENTS.md from that directory and every file tool runs inside it. the path must be absolute and exist, or the create is rejected.
Hermes Wingtips #27: /background
you do not have to wait while your agent grinds through a long task.
/background <prompt> spawns a completely separate agent session that runs in parallel: your chat stays fully interactive, and the result comes back as a panel in your terminal when it finishes.
(1) as an example: /background analyse the logs in /var/log and summarise today's errors.
you can run several at once, and the status bar shows how many are in flight.
(2) one thing to know: the background agent starts clean, with no knowledge of your conversation.
it only gets the prompt you give it, so write it self-contained. it inherits your model, provider and toolsets, so no setup needed.
Hermes Wingtips #25: /goal
/goal keeps working until a judge model calls it done, so a vague goal gets a vague judging. fix it by telling the judge what done means:
(1) let Hermes write it:
exemple: /goal draft migrate the auth service to JWT
(2) or spell it inline under
Hermes Wingtips #12: kanban's default worker workspace is scratch
you're handing a kanban task to a Hermes agent and want to keep the files it writes? one thing to know before you run it.
by default each kanban worker runs in a scratch workspace, and Hermes clears that workspace the moment the task completes. indeed, throwaway chores should not leave directories behind.
to keep the output, give the task its own workspace when you create it:
hermes kanban create "your task" --workspace dir:/absolute/path
two things to get right:
(1) name the workspace with dir: for anything you want to survive the run. no flag means scratch, cleared on completion.
(2) make the path absolute. Hermes accepts a relative path at create with no error, then rejects it when the worker spawns.
All tips are written by witcheer and collected here with credit. Card images stay on his X posts.
May we use Google Analytics to measure visits and newsletter signups? It uses cookies. Declining will not affect the site. Privacy details