Hermes & the Eight Powers A Field Guide for First-Time Travelers

Tells Hermes do this later — once, hourly, every Sunday at 9, whatever. The gateway daemon ticks every 60 seconds and runs anything that's due in a fresh agent session, then delivers the result wherever you said (chat, file, Telegram, Discord, email…).

Three ways to schedule: a relative delay (30m), an interval (every 2h), or a full cron expression (0 9 * * 1-5). You can also just ask Hermes in plain English — "every morning at 9, summarize Hacker News and DM me on Telegram" — and it'll wire up the cron job for you.

First-timer pitfall: cron runs in a fresh session with zero memory of your last chat. Whatever the agent needs to know, the prompt has to say.

Reach for it when

You want recurring or future-scheduled work — daily briefs, hourly polls, "remind me in 30 minutes."

Don't reach for it when

You need the result now in this conversation. Use the agent normally.

Lets the main agent spawn child agents to do work in parallel, each with a fresh isolated context and a restricted toolset. Up to 3 children at once by default. Only their final summaries come back — intermediate noise stays out of your context.

Think fork & join: the parent blocks until every child returns, then continues. Children know nothing the parent knows unless the parent passes it explicitly via the context field.

Crucial distinction: delegation is synchronous and ephemeral. If the user interrupts the parent, every child dies and their work is discarded. For durable work, use Cron or Kanban.

Reach for it when

You need 3 research questions answered in parallel, want to refactor a big codebase without flooding context, or want to delegate cheaper subtasks to a smaller model.

Don't reach for it when

The work has to survive interrupts, needs human input, or might be picked up by another role.

A durable SQLite-backed task board where multiple named profiles (researcher, reviewer, writer, deploy-bot) collaborate over time. Tasks have status, dependencies, comments, retries, and a full audit trail. The dispatcher inside the gateway claims ready tasks and spawns whichever profile owns them.

Where delegation is a function call, kanban is a work queue: every handoff is a row, humans can comment or unblock at any point, and a crashed worker gets reclaimed and retried instead of losing its task.

Open the dashboard (hermes dashboard → Kanban tab) and you get a Linear-style drag-and-drop board with columns for Triage / Todo / Ready / Running / Blocked / Done.

Reach for it when

Work crosses agent boundaries, needs to survive restarts, might need human input, or you have fleet work (one specialist + 50 subjects).

Don't reach for it when

You just want the parent agent to think about three things in parallel and merge results — that's delegation's job.

The companion tutorial walks four real shapes of work with dashboard screenshots:

① Solo dev shipping a feature — three linked tasks (schema → API → tests), each handing off structured --summary + --metadata so the next worker doesn't re-read a design doc.

② Fleet farming — one translator profile, one transcriber profile, one copywriter, all draining their queues in parallel while you sleep.

③ Role pipeline with retry — PM writes spec, engineer implements, reviewer rejects, engineer iterates, reviewer approves. Retry history is preserved, so the second attempt sees why the first failed.

④ Crash & circuit breaker — worker OOM-kills, dispatcher detects the dead PID, requeues. After N consecutive spawn-failures the breaker trips and the task auto-blocks.

If you're new, this is the page that makes Kanban click. The reference page tells you what; the stories show you why.

Read it when

You skimmed the Kanban reference and aren't sure when you'd actually pick it over a TODO list. The story comparing flat-todo vs. retry-aware runs is the moment of clarity.

You hand Hermes a goal that survives across turns. After every turn, a tiny judge model decides "done?" or "continue?" If continue, Hermes auto-feeds itself a continuation prompt and works again — up to 20 turns by default before pausing for you to /goal resume.

This is Hermes' take on the Ralph loop pattern. Use it for tasks where you'd otherwise be sitting there saying "keep going" three times: lint sweeps, multi-file ports, "investigate this drift bug and write a report."

User messages always preempt the loop — type something and it pauses. /goal pause, /goal resume, /goal clear, /goal status are the levers.

The judge is deliberately conservative: it only marks a goal done when the response explicitly confirms the work, the deliverable is clearly produced, or the goal is unachievable.

Reach for it when

The job is iterative and well-defined: "fix every failing test in tests/foo/ until scripts/run_tests.sh passes."

Don't reach for it when

The agent normally finishes in one turn. Goals are for tasks that need self-driven iteration.

Hermes can write a Python script that calls Hermes tools — web_search, read_file, patch, terminal, search_files… — programmatically, with normal Python flow control between calls. The script runs in a sandboxed child process and only its print() output comes back.

Why this matters: in a normal multi-tool workflow, every intermediate result enters the LLM context. With execute_code, you can loop over 50 search results, filter, fetch, summarize — and the LLM only sees the final summary. Massive token savings on tool-heavy work.

The agent decides on its own when to use this. It picks execute_code when there are 3+ tool calls with logic between them (loops, filters, conditionals).

Reach for it when

Mechanical pipelines — "find every file with X, read each, extract Y, count and report." (Or just trust the agent to pick it.)

Don't reach for it when

The work needs reasoning between steps — that's what delegation is for. Also: Linux/macOS only (uses Unix domain sockets).

Three hook flavors let you wedge custom logic into agent lifecycle: Gateway hooks (Python handlers that fire on Telegram/Slack/Discord events), Plugin hooks (Python, fire in CLI and gateway), and Shell hooks (drop-in shell scripts declared in config.yaml).

Three things hooks can do, in increasing power:

① Observe — log every tool call, count subagent runs, ping Telegram when a long task crosses 10 steps.
② Block — pre_tool_call can veto a dangerous shell command before it runs (e.g. forbid rm -rf /).
③ Inject — pre_llm_call can prepend context to the user's message every turn (memory recall, "today is Friday," current git status).

A famous community pattern: drop a ~/.hermes/BOOT.md with natural-language startup instructions, wire a hook on gateway:startup, and Hermes runs your checklist on every boot.

Reach for it when

You want auditing, guardrails, auto-formatting after writes, RAG-style context injection, or a startup ritual.

Batch processing is the training-data generation tool. Feed it a JSONL of prompts, set parallelism, and every prompt gets its own isolated agent session with sampled toolsets. Output is structured ShareGPT-format trajectories with full conversation history, tool stats, and reasoning coverage.

Resume is content-aware — if a run crashes halfway, --resume scans existing batch files, matches completed prompts by their actual text, and only re-runs what's missing. Quality filters drop samples without reasoning and entries with hallucinated tool names.

You can pin a per-prompt Docker image (so a "compile this Rust" prompt gets a Rust container) and a per-prompt working directory.

This is for fine-tuning & eval workflows, not for agent users. If you're not training a model, skip it.

Reach for it when

You're generating tool-use trajectories for fine-tuning, or you want to measure how well a model handles a benchmark of prompts.

Don't reach for it when

You just want the agent to handle one task — that's just… using the agent.