Automation & scheduling

Just ask in plain language, like "every morning at 9am, send me an AI news summary on Telegram," and Hermes creates the cron job itself. You can also use /cron add "every 2h" "Check server status" in chat or hermes cron create from the shell, optionally attaching skills with --skill.

Automation blueprints are ready-made jobs with a couple of fields to fill in. Type /blueprint to list them and /blueprint <name> (for example /blueprint morning-brief) to be asked for what it needs, or use the Blueprints tab on the Cron page in Desktop or the dashboard. Nothing is scheduled until you confirm.

Agent-backed jobs run inside the gateway, so keep it running. Results can go back to the original chat, to files, or to other configured platforms, and /cron or hermes cron list manages what you've created.

Agent-backed cron jobs run inside the gateway, which checks for due jobs every 60 seconds. If the gateway isn't running, those jobs are skipped with a logged reason and fire on the next tick after you start it with hermes gateway start; their schedule is not penalised. Script-only (no_agent) jobs are the exception and still run from a bare hermes cron tick. hermes cron list shows each job's status and reason.

Hermes also validates a job before running it. Missing API keys, unready skills or unknown delivery targets set its status to blocked_config and send a single alert.

Yes. The delegate_task tool starts child agents, each with a fresh, isolated conversation and its own terminal session. Only the child's final summary comes back to the main chat. By default up to 10 can run in parallel.

You can give subagents a different model, for instance a cheaper one, with delegation.model and delegation.provider in config.yaml.

Yes, in two ways. No-agent mode runs a script from ~/.hermes/scripts/ on a schedule and delivers its stdout verbatim with no LLM call, and empty output means no message. Create one with hermes cron create plus --no-agent and --script, or just describe the watchdog in chat and Hermes sets it up.

For agent-backed jobs, a pre-check script can print {"wakeAgent": false} as its last line to skip that run without calling the model.

Set the job's deliver target. origin goes back to the chat where the job was created (the default on messaging platforms), local saves to ~/.hermes/cron/output/ (the CLI default), and a platform name like telegram or discord uses that platform's home channel. You can also target a specific chat or Telegram topic, list several targets separated by commas, or use all.

Send /sethome in a chat to make it the home channel. The agent's final response is delivered automatically, so the job prompt doesn't need to send anything.

delegate_task works like a function call: the parent waits for an anonymous child and gets a summary back. Kanban is a durable work queue in ~/.hermes/kanban.db where named profiles with their own memory pick up tasks, hand off, recover from crashes and take comments from you.

Use subagents for quick answers that feed the current conversation. Use Kanban when work crosses agents, must survive restarts or might need your input. Start with hermes kanban init, keep the gateway running because it hosts the dispatcher, and add tasks with hermes kanban create.

Yes, through the webhook adapter. Enable it with hermes gateway setup (it listens on port 8644 by default), then define routes in config.yaml or create them with hermes webhook subscribe, which returns the URL and HMAC secret to give the service. Incoming events become agent prompts, and results can go to Telegram, Discord, Slack or a GitHub comment.

--deliver-only skips the agent and forwards the rendered message at zero LLM cost, and --script can filter or reshape payloads first.

On messaging platforms, a message sent while the agent is working redirects the current turn by default: running tools finish safely and your correction is picked up at the next step. /stop is the hard stop.

/busy (or display.busy_input_mode in config.yaml) changes that. queue holds each follow-up and runs it as its own turn, in arrival order, once the current task finishes. steer slips it into the current run after the next tool call. In the CLI, /steer and /queue (or /q) do the same thing one message at a time.

In Hermes Desktop, queued messages appear above the composer, where you can edit, send or delete them. The queue lives on the gateway, so it survives an app or gateway restart.

A profile is a separate agent with its own config, keys, memory, sessions, skills and cron jobs (hermes profile create <name>). A Bot Mode bot is simply a profile shown in Desktop's Bots roster with an avatar, a permanent Bot Chat and its own routines. A messaging bot is a platform account (such as a Telegram bot) connected to a profile.

A subagent is a temporary child started by delegate_task for one job, with a fresh conversation; only its summary comes back. Use it for quick parallel research or side work inside the current conversation.

Kanban is a durable task board shared across profiles. Use it when work spans several named agents, must survive restarts, or needs your review between steps. Rule of thumb: one assistant, profiles for separate roles, subagents for quick fan-out, Kanban for pipelines.

Create the board once with hermes kanban init and keep the gateway running, since it hosts the dispatcher that hands tasks to profiles. Add tasks with hermes kanban create, /kanban in chat, or the board UI.

In Hermes Desktop the Kanban board is a bundled plugin that ships switched off, so it doesn't appear until you enable it in Capabilities > Plugins; it then adds a Kanban page and sidebar entry. The web dashboard (hermes dashboard) has a Kanban tab too.

The board is only a view. For an agent to create and route tasks from chat, enable the kanban toolset on the profile that orchestrates work, for example hermes -p planner tools enable kanban, and start a new chat. Leave it off on profiles that only talk to people; workers get their task tools automatically.

The easiest way is Bot Mode in Hermes Desktop, on by default as the Bots tab. Click New Agent, give it a name, title and description, and optionally its own model, SOUL.md, skills, toolsets and MCP servers. Each bot is a profile, so it also works from the CLI (hermes -p <bot> chat).

Bots can message each other with @mentions (@researcher have a look at this), you can open group chats where several bots deliberate, and each bot can have recurring routines. Group bots into sections to keep the roster tidy.

For structured pipelines with handoffs and review steps, put the work on the Kanban board. The docs' learning path has a "team of specialist bots" reading order: Desktop, Profiles, Bot Mode, Cron, then Multi-connection Desktop.

Yes, in two ways. Bot-to-bot: register the other gateway as a peer with hermes peer add <name> --url http://host:port --key <API_SERVER_KEY> (the remote side runs the api_server platform), then hermes peer dm <peer> "message". Bots learn about registered peers automatically, so they can message cross-machine teammates themselves.

A2A: the Agent2Agent plugin lets your Hermes call other A2A agents as tools and receive tasks over HTTP, including from non-Hermes frameworks. Enable it with hermes gateway setup and turn on the outbound tools with hermes tools enable a2a --platform cli.

Hermes Desktop can also connect to several machines at once, so bots on different hosts appear in one roster. For agents on the same machine, use subagents or Kanban instead.

Failures are never silent. A failed subagent reports a one-line reason in the CLI and in chat (even with tool progress hidden), and the parent gets status: "failed" with the error so it can retry or reroute. Children have no wall-clock timeout by default, but a stalled one (no activity for 450 seconds, or 1,200 inside a tool) is interrupted and reported.

By default subagents share the parent's working folder, which is fine for reading but risky for parallel edits. Set delegation.worktree_isolation: true and each child works in its own git worktree and branch, which the parent can review and merge. That works for git repos on the local terminal backend.

A restart doesn't resume a running subagent. For work that must survive restarts or hand off between agents, use Kanban or a cron job.

Yes, if each one gets its own checkout. Two agents editing the same working folder can overwrite each other's changes, so the docs recommend git worktrees: start with hermes --worktree (-w), create one mid-session with /worktree new <name>, or in Desktop use New worktree on a project (Cmd/Ctrl+Shift+B).

For subagents, delegation.worktree_isolation: true gives each child its own worktree. Each worktree also gets its own checkpoint history for /rollback.

Shared files outside git (a notes folder, a spreadsheet) have no such protection, so give each agent its own file or coordinate through Kanban.

Only /moa exists in Hermes; there is no /council command in the current release. /moa <prompt> runs one prompt through your default Mixture of Agents preset and then switches back to your normal model.

A MoA preset sends your conversation to several reference models for their views, and an aggregator model writes the answer and does the tool calls; the aggregator is billed for the whole run. Create presets with hermes moa configure, list them with hermes moa list, and select one like any model (it appears under a Mixture of Agents provider) to use it for a whole session.

If you want several distinct agents to discuss something, Bot Mode group chats in Hermes Desktop are the closest built-in equivalent.

hermes pause is an emergency stop for new work: no cron jobs fire, no Kanban tasks are dispatched and no new gateway turns start (CLI, TUI and Desktop turns included) until hermes resume. Turns already running finish; nothing in flight is killed, and held cron work catches up after you resume. /pause and /pause off do the same from a chat.

/restart (in a messaging chat) restarts the gateway gracefully: it waits for active turns to finish first (up to agent.restart_after_turn_timeout, 30 minutes by default), then confirms in your chat when it's back.

Other stops, such as hermes gateway stop or an update, interrupt running chat turns immediately by default (agent.restart_drain_timeout: 0). Queued messages are kept and run after the restart.