To run hermes agent background work, type /bg followed by your prompt. Hermes spins up a separate agent session that works on it while your main chat stays free, then hands you the result when it's done.
📺 Watch: Hermes + Claude + Codex - The AI System That Does EVERYTHING!
🔥 Get the Agent OS as a free bonus: AI Profit Boardroom members get the full Agent OS zip, prompt libraries, daily tutorials and weekly live coaching calls. → Get inside
That's the headline. But "background" in Hermes covers four things: background sessions, background processes, subagents, and cron jobs that run while you're not looking. Plus the gateway service that keeps all of it alive. I'll take each in turn, using only what the Hermes docs say.
Hermes Agent is the open-source, self-hosted agent from Nous Research, MIT licensed, with persistent memory and self-written skills. I run it daily inside my own Agentic Operating System, and background work is where most of the time savings come from.
Background sessions with /bg
In the CLI, you type something like /bg Analyze the logs in /var/log and summarize any errors from today. Hermes confirms straight away, gives you a task ID (the docs show one like bg_143022_a1b2c3), and hands you your prompt back.
Per the Hermes docs, each /bg prompt spawns a completely separate agent session in a daemon thread:
- Isolated conversation. The background agent knows nothing about your current chat. It only gets the prompt you give it.
- Same configuration. It inherits your model, provider, toolsets, reasoning settings and fallback model.
- Non-blocking. You keep chatting, running commands, or starting more background tasks.
- Multiple tasks. You can run several at once, and each gets a numbered ID.
When a task finishes, the result shows up as a panel in your terminal. If it fails, you get an error notification. If display.bell_on_complete is on in your config, the terminal bell rings when it's done.
One thing to know: background sessions don't appear in your main conversation history. They're standalone sessions with their own task ID.
If you want to learn how to structure this kind of work properly, the AI Profit Boardroom ($69/mo) has Hermes courses, my Agent OS zip, daily updates and four coaching calls a week.
Background sessions from Telegram, Discord and Slack
/bg works in messaging apps too. Per the docs, the background agent inherits your model, provider, toolsets, reasoning settings and provider routing from the gateway setup. When it's done, the result goes back to the same chat or channel, prefixed with "Background task complete". If it fails, you see "Background task failed" with the error.
The docs call these fire-and-forget. You don't need to wait or check. Their example uses include server monitoring, long builds, competitor research and organizing files.
Background process management
This is different from /bg. A background process is a long-running command the agent starts, like a test run, a build or a server, using terminal with background set to true. It returns a session ID and a PID.
The agent then manages it with the process tool. Per the Hermes docs, the actions are:
| Action | What it does |
|---|---|
| list | Show all running processes |
| poll | Check status |
| wait | Block until done |
| log | Full output |
| kill | Terminate |
| write | Send input |
PTY mode lets interactive CLI tools like Codex and Claude Code run this way.
Finished commands keep their exit status and output. Hermes keeps the newest 64 completed results for up to 7 days after completion, under logs/process-results/ in the profile's Hermes home. Each receipt holds at most a 200,000-character output tail, with secret redaction always applied. The docs are clear that this saves work that finished. It doesn't keep unfinished processes alive after a timeout or crash.
Controlling process notifications
On messaging apps, you choose how chatty these updates are with display.background_process_notifications in ~/.hermes/config.yaml:
- concise (the default): a one-line status on completion, with a short output tail on failures
- all: running-output updates plus the final status
- result: only the final status with the output tail
- error: only the final status, and only when the exit code is non-zero
- off: no process watcher messages at all
You can also set it with the HERMES_BACKGROUND_NOTIFICATIONS environment variable.
📺 Watch: Hermes3D Is INSANE: AI Agents Now Have a 3D Office
Background subagents
The delegate_task tool spawns child agents with isolated context, inherited tool access and their own terminal sessions. Only each child's final summary goes back into the parent's context.
Per the Hermes docs, top-level model calls run in the background automatically. Hermes returns a handle straight away so the conversation can continue, then posts the result back as a new message. You can run up to 10 concurrent subagents by default, and that's configurable.
One rule to remember: background processes belong to the agent that starts them. When a child finishes, its remaining processes are shut down. So if a server or watcher needs to keep running after the child is done, start it in the parent session.
Which tools you give these agents matters a lot. My best Hermes Agent tools list covers the ones worth switching on.
📺 Watch: Hermes AI Agents Just Went Portable
Cron jobs: hermes agent background work on a schedule
Cron is how you get Hermes doing jobs in the background while you sleep. Per the docs, you can schedule one-shot or recurring tasks in plain language or cron expressions, attach skills, and deliver results back to a chat, local files or other platform targets.
The key detail: cron execution is handled by the gateway. The gateway ticks the scheduler every 60 seconds and runs due jobs in isolated agent sessions. No gateway, no cron.
You can just ask Hermes to create, pause, edit or remove jobs. Or use the CLI:
- hermes cron list shows your jobs
- hermes cron pause and hermes cron resume stop and restart scheduling for a job
- hermes cron run triggers a job on the next scheduler tick
- hermes cron remove deletes it
- hermes cron status reports whether the scheduler is alive and the next scheduled run
Need to stop everything at once? hermes pause is the global emergency stop, and hermes resume lifts it. Runs already in progress aren't killed, and due work catches up after you resume.
If hermes cron status shows a job as overdue, the docs say that's the sign of a scheduler that stopped ticking. Restart the gateway with hermes gateway restart, or run the job now with hermes cron run.
The Agent OS guide shows how I organize scheduled jobs across different agents.
How to check and stop background work
Here's the quick reference, all from the Hermes docs:
| Type | How to check it | How to stop it |
|---|---|---|
| /bg session | Result panel or chat message when done | Fire-and-forget; results arrive automatically |
| Background process | process list, poll or log | process kill |
| Cron job | hermes cron list, hermes cron status | hermes cron pause or remove; hermes pause for everything |
| Gateway | hermes gateway status | hermes gateway stop |
Keeping the gateway running in the background
Your bots and cron jobs only work while the gateway is up. Per the docs, hermes gateway install sets it up as a user service on Linux (systemd) or a launchd service on macOS.
Linux (systemd)
- hermes gateway install, then hermes gateway start
- View logs with journalctl --user -u hermes-gateway -f
- Run sudo loginctl enable-linger $USER so it keeps running after you log out
- Or install a boot-time system service with sudo hermes gateway install --system
The docs say to use the user service on laptops and dev boxes, and the system service on a VPS or headless host that should come back at boot. For a headless VM you never log into, a user service plus linger gives you start-at-boot with no root needed, so hermes update can restart the gateway without sudo.
Prefer hermes gateway restart over a raw systemctl restart when in-flight agent turns matter, because it drains first and waits for the replacement.
macOS (launchd)
Same commands: hermes gateway install, start, stop and status. Logs are at ~/.hermes/logs/gateway.log, and the plist lives at ~/Library/LaunchAgents/ai.hermes.gateway.plist. Per the docs, if you install new tools after setting up the gateway, run hermes gateway install again to capture the updated PATH.
If you haven't installed Hermes yet, start with my Hermes Agent installation guide. And if you want it running 24/7 without your laptop open, see my pick of the best Hermes VPS options.
Choosing a model that handles long background jobs well is worth testing first. I score models on real agent work in Goldie Bench.
Want a plan for what to automate first? Book a free AI strategy session.
FAQ
How do I run a Hermes task in the background?
Type /bg followed by your prompt. Per the Hermes docs, it spawns a separate agent session with your same model and toolsets, and the result comes back to your terminal or the same chat when it finishes.
Does a background session know about my current chat?
No. The docs say the background agent has no knowledge of your current session's history and only receives the prompt you provide. Put everything it needs in that prompt.
Why aren't my cron jobs running?
Cron runs inside the gateway, so check hermes gateway status and hermes cron status. If a job shows as overdue, restart with hermes gateway restart. Also check you haven't left hermes pause switched on.
How do I keep Hermes running after I close my laptop?
Install the gateway as a service with hermes gateway install. On a Linux server, enable linger or use the --system service so it starts at boot. For true always-on, run it on a VPS.
Ready to put your agent to work while you're offline? Join the AI Profit Boardroom for the Hermes courses, or book a free AI strategy session. Get one hermes agent background job running tonight and see what's waiting for you in the morning.
