Automation — งานที่รันเองตามเวลา ตามเหตุการณ์ และไม่เปลือง tokenAutomation — Scheduled, Event-Driven, and Zero-Token Work

Picture a Monday morning. Before anyone on the team has opened a laptop, the pull requests that sat unreviewed all weekend have a summary waiting in Slack, the dependency that acquired a new CVE overnight already has a ticket, and nobody has typed an instruction since Friday evening. The question this post answers is not whether an agent can do that — it is which door the work should walk through: a schedule, an external event, or another application calling in. And, just as important for whoever pays the bill: which of those rounds never need to spend a token at all.

The introduction to cron is already in #2 Agent Teams, under "Always-On Work" — the cronjob actions, the schedule dialects, fresh isolated sessions, continuity and context_from, the delivery targets, [SILENT], no_agent, and v0.21.0's "cron jobs that remember". In #5 Integrations the API server and A2A each got a brief section. This post does not re-introduce any of that; it is the ops layer on top: the files and ledger behind the built-in cron of Hermes Agent, the defaults worth knowing, the incidents/doctor/runs loop; inbound webhooks that verify a signature before they believe anything; hooks and outbound webhooks that push events to systems your organization already owns; blueprints, which turn out to be nothing more than a skill with a schedule; and an OpenAI-compatible API server that lets internal apps call Hermes the way they would call any model.

Readers who followed this blog's OpenClaw series will recognise the heartbeat pattern from OpenClaw #5: Integrations — wake the agent periodically and let it check whether anything needs doing. The idea survives in Hermes, but it has been broken into named, inspectable pieces, and the most important of those pieces can leave the model switched off when nothing has changed. I will keep that comparison qualitative. No number in this post is my own measurement; every version, default and quotation comes from the official documentation or the GitHub release notes of Nous Research, as of 1 September 2026 (v0.21.0, tag v2026.8.31).

Five Doors Into the Gateway

The first thing to internalise is that all of Hermes's automation lives inside the same gateway daemon that receives your Telegram and Slack messages — the same VPS or Docker container from #7 Production. There is no separate scheduler process and no worker pool. Work reaches that one daemon through five doors:

My advice for an organization starting out: begin with cron. It is the only door where you set the tempo, nothing external can knock, and since v0.13.0 it has a mode that never touches the model. Add inbound webhooks when you want GitHub or your monitoring stack to do the waking. Leave the API server and A2A for last — both open network surfaces with a CVE history of their own, which I keep for the final section.

💡 If you have read #2, hold the distinction this way: a heartbeat is an agent that wakes up and asks whether anything has happened; a Hermes cron job is a named unit of work with a schedule and a ledger of its own — and, as the next two sections show, it can separate "waking up" from "thinking".

Anatomy of a Cron Job

Hermes cron is not the Linux crontab firing bare commands. A job is a prompt wrapped in metadata (or a script wrapped in the same metadata), and every piece of state is a plain file you can open yourself:

~/.hermes/cron/
├── jobs.json                 # every job definition — written atomically
├── executions.db             # the ledger: claimed → running → completed | failed | unknown
├── .tick.lock                # file lock so two ticks never overlap
└── output/
    └── {job_id}/
        └── {timestamp}.md    # every run's output, readable after the fact

The 60-second tick from #2 has two operational consequences: one minute is the finest schedule resolution you get, and .tick.lock is what stops two processes (say, two gateways accidentally mounting the same volume) from running the same job twice.

There are three ways to create a job — the CLI (hermes cron create), the cronjob tool the agent calls for itself inside a session, and the dashboard on port 9119 (backed since v0.4.0 by a /api/jobs REST API). I show the tool form because it is the parameter list the documentation spells out most completely; in chat you simply describe the job you want and the agent calls this. For the CLI flags, hermes cron create --help is the source of truth:

# one tool for every action — release v0.3.0 (17 March 2026) folded several commands into it
cronjob(
  action="create",            # list | update | pause | resume | run | remove
  schedule="0 9 * * 1-5",     # five-field cron — weekday mornings
  name="morning-brief",
  prompt="Summarise the issues opened in the team repo yesterday, grouped by label",
  deliver="slack",
  skills=["github-triage"],   # attach a skill from post #6
  workdir="/srv/repo",        # scopes file/terminal tools and loads that repo's AGENTS.md (absolute paths only)
  enabled_toolsets=["web", "file", "terminal"],
  continuity=True,            # v0.21.0 — remember this job's own previous output
  context_from="deps-scan",   # v0.12.0 — prepend another job's last successful output
  reasoning_effort="high",    # v0.21.0 — pinned per job
  no_agent=False,
  attach_to_session=False,
)

The schedule dialects are covered in #2 (the feature page lists five: relative, interval, natural language, five-field cron, and ISO timestamps). One thing worth adding: the cron feature page lists natural-language forms such as daily at 7am, and #2 uses weekdays at 9am as its example, but the automate-with-cron guide, another official page, states that natural language such as "daily at 9am" is not supported. I have not tested which page matches the code. In production I would standardise on five-field cron, and if you want natural language, test it on your own build (v0.21.0) before you depend on it.

The cron: block of config.yaml carries defaults an organization should know before touching them:

On delivery: #2 gave a partial list; the full one on the feature page is origin, local, telegram, discord, slack, whatsapp, signal, matrix, mattermost, email, sms, homeassistant, dingtalk, feishu, wecom, weixin, bluebubbles, qqbot, bot-chat and all. You can target a specific chat and thread (telegram:-100123:17585) or fan out to several targets separated by commas. The [SILENT] rule is in #2; two things to add: a suppressed result is still saved under output/, and a failed job always delivers, however quiet you asked it to be.

As for what a job may use: toolsets.py defines a hermes-cron toolset that mirrors hermes-cli, then per-job enabled_toolsets and the cron platform entry in hermes tools override it in that order. And workdir does more than fence the file and terminal tools — it also loads AGENTS.md, CLAUDE.md or .cursorrules from that directory, so a job working on a repository inherits that repository's rules without you pasting them into the prompt.

Zero-Token Automation: Work That Never Wakes the Model

This is where Hermes cron most clearly parts company with the OpenClaw-era heartbeat. In the heartbeat pattern every wake-up is an LLM call, even when nothing has changed. Hermes offers three layers that remove that cost.

Layer 1 — script-only jobs (--no-agent, v0.13.0)

#2 gave no_agent=True one sentence; this is its full contract. Release v0.13.0, "The Tenacity Release" (7 May 2026), added watchdog mode: a job that runs an ordinary script with no agent in the loop at all.

# scripts must live in $HERMES_HOME/scripts/ — path traversal is rejected
cat > ~/.hermes/scripts/watchdog.sh <<'EOF'
#!/usr/bin/env bash
# the shebang is ignored — .sh/.bash always run under bash, anything else under the current Python
code=$(curl -s -o /dev/null -w '%{http_code}' https://intranet.example.ac.th/health)
if [ "$code" != "200" ]; then
  echo "⚠️ intranet health = $code"     # stdout present → this text is delivered as-is
  exit 0
fi
# exit 0 + empty stdout = a silent tick: nothing sent, no tokens spent
EOF

hermes cron create "every 5m" --no-agent --script watchdog.sh --deliver telegram

The watchdog contract fits in four lines: exit 0 with empty stdout is silent; any stdout is delivered verbatim; a non-zero exit or a timeout raises an error alert; and if the last line of stdout is {"wakeAgent": false} the tick is treated as silent too. The detail I like most is that the subprocess environment is scrubbed of provider credentials — a script you wrote (or one the agent wrote for you) does not walk away with your model API keys.

Layer 2 — monitor mode that skips the LLM when nothing changed (v0.21.0)

v0.21.0 "Pantheon" (31 August 2026) added hash-suppressed change detection (PR #81138): a job in monitor mode hashes what it is watching, compares it with the previous run, and if nothing changed it never calls the model. This is the direct answer to the complaint I made in the earlier series about heartbeats that pay for the privilege of reporting that nothing happened. A sourcing caveat: as of this writing, monitor mode appears in the v0.21.0 release notes and PR #81138 only — the rendered cron documentation does not describe it yet. So I have found no percentage for what it saves and will not invent one, but the logic is plain: an unchanged round costs zero tokens.

Layer 3 — deliver_only and hermes send

The webhook side has the same idea: a route with deliver_only: true (v0.11.0, PR #12473) forwards the transformed payload to a channel without involving the agent. And for any script on the box there is hermes send, from v0.15.0 "The Velocity Release" (28 May 2026, PR #27188), which the release note describes as "pipe any script's output to any messaging platform":

# one-shot delivery to a configured channel — no agent loop, no tokens
hermes send --to slack "Backup finished: 2.1 GB"
hermes send --to telegram --file /var/log/nightly-report.pdf
hermes send --list             # which targets are available

# bolt it onto the scripts you already run
./run-etl.sh 2>&1 | tail -n 5 | xargs -0 hermes send --to slack

A detail that matters for scripts on a server: for the bot-token platforms — Telegram, Discord, Slack, Signal, SMS and the WhatsApp Cloud API — hermes send delivers on its own, with no running gateway required; plugin platforms still need one.

Cron That Remembers — and the Ops Loop

All three bridges across runs are already in #2 — context_from (v0.12.0, 30 April 2026, PR #15606), which prepends the most recent successful output of another job; continuity=True, which injects the same job's previous output; and v0.21.0's persistent memory and per-job notepad. Two things #2 did not say: the memory a cron agent loads is the same bounded MEMORY.md whose rules and caps are in #3 Memory (so what a job learns at 2 a.m. is there for your session at 9), and, as of this writing, cron memory and the notepad rest on the v0.21.0 release notes and PR #81138 only — the rendered cron page still documents just continuity and context_from. Here is what the chain looks like in practice:

# a two-step chain: scan at 01:00, let the 02:00 job read that result
cronjob(action="create", name="deps-scan", schedule="0 1 * * *",
        prompt="Run pip-audit and npm audit in the repo; report only CVSS ≥ 7",
        workdir="/srv/repo", deliver="local")

cronjob(action="create", name="deps-triage", schedule="0 2 * * *",
        context_from="deps-scan",     # deps-scan's last successful output is prepended
        continuity=True,              # and it remembers which issues it opened last time
        prompt="From the attached scan, open issues for the team; skip anything already filed",
        deliver="slack")

Two more v0.21.0 additions ops people will appreciate: output can land in a bot's own Bot Chat (the Bot Mode concept lives in #2 — I will not re-explain it), and a "Trigger now" button (#70638) in the Desktop app and the dashboard runs a job immediately for testing without touching its schedule — on the CLI the same verb is hermes cron run <job>.

The ops loop: incidents → doctor → runs

A cron system that runs while nobody is watching must answer "did anything break last night?" in three commands:

# 1) what the system noticed — detected → alerted → closed
hermes cron incidents
hermes cron incidents ack <incident-id>    # v0.21.0: an acked failure signature stops re-pinging (#95017)

# 2) read-only health check — exits 1 on problems, so it slots straight into monitoring
hermes cron doctor
#   checks: last run failed / delivery failed / stale next_run_at / missing script / missing workdir

# 3) run history
hermes cron runs deps-triage --limit 20

Details I give credit for: incident error text is redacted before storage, because stack traces drag credentials along; hermes cron doctor is designed so its exit code means something, which is exactly what the monitoring section of #7 wants. And the model-drift guard is a piece of care I have not seen in other agents' cron systems: change the global default with hermes model and every unpinned job skips its run with a one-time alert, instead of silently executing with a model you never tested against that prompt (resolution order is per-job pin → cron.model → the global default).

For output you want to keep talking to, set cron.mirror_delivery: true globally or attach_to_session=True per job; on thread-capable platforms (Telegram topics, Discord and Slack threads) each run opens its own thread you can reply in as if you were chatting with the agent. Slack's in-channel mode additionally needs slack.cron_continuable_surface: in_channel with reply_in_thread: false.

Inbound Webhooks Done Properly

The webhook adapter arrived in v0.4.0 (tag v2026.3.23, published 24 March 2026) in the same batch as Signal, DingTalk, SMS, Mattermost and Matrix. Hermes treats it as one more "platform", like Telegram — except the sender is a machine rather than a person. The ground rules fit in one table:

Static routes live in config.yaml under platforms.webhook.extra.routes.<name>. This is the skeleton of the PR-review recipe the official docs publish:

# config.yaml — shape follows the official webhook-github-pr-review guide
platforms:
  webhook:
    enabled: true
    extra:
      port: 8644
      rate_limit: 30
      routes:
        pr-review:
          secret: "<long-random-secret>"      # the same value goes into GitHub's webhook settings
          events: [pull_request]
          prompt: |
            Review PR "{pull_request.title}" in {repository.full_name}.
            The payload carries no diff — run: gh pr diff {number} --repo {repository.full_name}
            Summarise risks and suggestions in at most 10 points.
          deliver: github_comment
        alerts:
          secret: "<another-secret>"
          deliver_only: true                    # skips the agent — zero tokens
          deliver: telegram

What the template can do: dot-notation into the payload ({pull_request.title}), and {__raw__}, which dumps the whole payload as JSON truncated at 4,000 characters. Each route may also carry filters (exists / missing / equals / not_equals / contains / in / in_file / regex, composed with all / any / not) to screen events before they reach the agent, and a script transform from ~/.hermes/scripts/ — JSON on stdout replaces the payload, while empty stdout, [SILENT], or {"__hermes_ignore__": true} returns 200 and quietly drops the event. Webhook deliver adds log and github_comment to the usual channel list.

If a route genuinely needs more — the recipe above asks the agent to run gh pr diff, which is outside those four tools — the route's toolsets key replaces the platform default wholesale; it does not merge. Open only what the job needs, and know that you are lowering a wall when you do. On the GitHub side you point the webhook at https://<host>/webhooks/pr-review, choose JSON as the content type, paste the same secret, and select the Pull requests event. The guide says the comment lands on the PR in roughly 30–90 seconds, and duplicate deliveries from GitHub are deduplicated for one hour.

Subscribing without a restart

Beyond static routes there are dynamic subscriptions that take effect immediately:

hermes webhook subscribe ci-failed \
  --events workflow_run \
  --prompt "Read the failed workflow's log and summarise the likely cause" \
  --deliver telegram --deliver-chat-id -100123 \
  --skills ci-triage

hermes webhook list
hermes webhook test ci-failed --payload ./sample.json   # fire a sample payload at the route
hermes webhook remove ci-failed

# stored in ~/.hermes/webhook_subscriptions.json
# on a name collision, the static config.yaml route wins

The docs are explicit: "No gateway restart required — subscribe and it's immediately live." One thing I want you to notice: the agent itself has no webhook tool. When you say in chat "set up a webhook for GitLab events", it uses the terminal tool to run the hermes webhook subscribe command above, guided by a bundled skill called webhook-subscriptions (the SKILL.md anatomy is in #6 Skills). Which means a session without the terminal tool cannot do it — correct behaviour, for a session that was itself woken by a webhook.

A small market has already formed around port 8644 — Hookdeck publishes a guide to putting its own relay in front of Hermes, and fast.io a guide to having n8n call hermes webhook subscribe with an HMAC-computing node. Both are vendor marketing; I cite them only as evidence that organizations are wiring their existing workflow tools in front of this door, not as recommendations.

Pushing Events Out: Outbound Webhooks, Shell Hooks, and Deliverable Mode

The outbound side has three doors that are entirely different from one another, and I want the difference to be sharp, because the docs call several of them "hooks".

1) Signed outbound webhooks (v0.20.0)

PR #69406 (merged 2 August 2026, shipped in v0.20.0 "Herald" the next day) added hooks.outbound: whenever a lifecycle event fires, the gateway POSTs to a URL you choose, with an HMAC. This is how the observability section of #7 gets lifecycle events without scraping logs:

# config.yaml
hooks:
  outbound:
    - name: siem
      url: https://siem.example.ac.th/hermes
      events: [on_session_end, subagent_stop, post_tool_call]   # any event from the plugin-hook catalog
      secret_env: HERMES_SIEM_SECRET        # read from ~/.hermes/.env — preferred over an inline secret:
      timeout: 10                           # 1–60 seconds
      matcher: "^(terminal|write_file)$"    # regex to narrow tool-scoped events to the tools you care about

# what the receiver sees
POST /hermes HTTP/1.1
Content-Type: application/json
X-Hermes-Event: post_tool_call
X-Hermes-Delivery: <delivery-id>
X-Hermes-Signature-256: sha256=<hex of HMAC-SHA256 over the raw body>

{ "hook_event_name": "post_tool_call", "tool_name": "terminal", "session_id": "…",
  "delivery_id": "…", "timestamp": "…", … }      # same shape as shell-hook stdin, plus the last two fields

Delivery is fire-and-forget through a bounded queue and a single daemon thread: one retry with backoff on a connection error or 5xx, no retry on 4xx, 3xx not followed, and edits to the target list take effect on the next CLI session or gateway restart. Put bluntly, this is not a message queue with delivery guarantees. If your organization needs at-least-once, put a relay that owns that responsibility in between. hermes hooks list shows outbound targets alongside shell hooks.

2) Shell hooks that can veto (v0.11.0)

Shell hooks (v0.11.0, 23 April 2026, PR #13296) are a different animal from webhooks: local scripts that run at moments in the agent's loop, and at some of those moments can block the action:

# config.yaml
hooks:
  pre_tool_call:
    - matcher: "^terminal$"
      command: ~/.hermes/agent-hooks/guard-terminal.sh
      timeout: 30          # default 60, maximum 300
      fail_closed: true    # if the script breaks, block (the default is fail-open!)

#!/usr/bin/env bash
# ~/.hermes/agent-hooks/guard-terminal.sh — reads JSON on stdin
payload=$(cat)
cmd=$(printf '%s' "$payload" | jq -r '.tool_input.command // ""')
if printf '%s' "$cmd" | grep -Eq 'rm -rf /|mkfs|DROP TABLE'; then
  echo '{"action":"block","reason":"dangerous command — needs a human"}'
  exit 2              # exit code 2 also blocks
fi
exit 0

The stdin fields are hook_event_name, tool_name, tool_input, session_id, cwd and extra. A pre_tool_call hook may answer with {"action":"block"|"modify"} or with the Claude Code form {"decision":"block"} — deliberately, so hooks an organization wrote for Claude Code can move across. The first time any (event, command) pair fires, Hermes asks for consent and records it in ~/.hermes/shell-hooks-allowlist.json (bypass with --accept-hooks or HERMES_ACCEPT_HOOKS=1 on headless machines).

hermes hooks list                 # shell hooks + outbound targets
hermes hooks test pre_tool_call   # fire a synthetic event — do this after every config change
hermes hooks doctor
hermes hooks revoke               # withdraw a consent you gave earlier

Besides the 26 plugin-level hooks the plugins doc lists (directive: pre_tool_call, pre_llm_call, pre_verify, pre_gateway_dispatch; the transform family; and observers such as on_session_start/end, subagent_start/stop, kanban_task_*), there is a separate set of gateway-only events — gateway:startup, session:start/end/reset/compress, agent:start/step/end, reaction:added/removed, command:*. Bounded hooks time out after plugins.hook_callback_timeout (30 seconds by default, 600 at most), and pre_tool_call is the only one that fails closed on timeout; the rest fail open.

3) Deliverable Mode — the files an agent produces reach the people in the chat

The last outbound door carries files, not events. In Deliverable Mode the gateway scans the agent's response for absolute (/tmp/report.pdf) or home-relative (~/out/chart.png) paths with supported extensions and uploads them as native attachments on Slack, Discord, Telegram, WhatsApp and Signal — images inline, audio as voice notes, everything else as files. Paths inside code blocks are ignored, and source files such as .py are deliberately excluded. Kanban workers can attach deliverables to kanban_complete too. The doc warns that "the agent doesn't reach for artifacts by default" — if you want the morning cron job to send a PDF instead of a wall of text, say so in the prompt or in AGENTS.md/SOUL.md.

💡 "Artifact" means three unrelated things in Hermes: Deliverable Mode above; the right-rail viewer in the Desktop app (PR #72345, v0.20.0 — a pure UI feature, persisted in that machine's localStorage); and the "task artifact" of the A2A protocol. Do not expect a central artifact store your pipelines can pull from — there is none today, and issue #19489 asking for an artifact-builder skill is still open.

Blueprints: A Skill With a Schedule

If cron is the engine, Automation Blueprints (v0.17.0, 19 June 2026, PR #41309) are the dashboard that lets people who never want to see cron syntax drive it — the release note's summary is "Pick an automation by name and Hermes asks you for what it needs — no cron syntax." But the line I want you to remember is the one in tools/blueprints.py:

"A blueprint is NOT a new object type. It is an ordinary skill that additionally declares an automation schedule in its frontmatter."

Everything you know from #6 Skills therefore applies unchanged. Take an existing SKILL.md, add a metadata.hermes.blueprint block, and it becomes a blueprint that flows through the same skills-hub pipeline — which, by the docs' own logic, means every mechanism that wraps a skill (including the install-time scanning described in #6) wraps a blueprint too:

---
name: nightly-backlog-triage
description: Rank the open backlog every night and post a summary to the team's Slack
metadata:
  hermes:
    blueprint:                   # shape follows the BlueprintSpec fields — verify against tools/blueprints.py before relying on it
      schedule: "0 2 * * *"      # skill_name, schedule, deliver (default origin), prompt,
      deliver: slack             # no_agent, model, provider, enabled_toolsets
      prompt: "Run this skill against the team repository"
      enabled_toolsets: [web, file, terminal]
---

# Nightly Backlog Triage
1. Fetch every open issue with gh …
2. Group by label and age …

One definition is rendered four ways: a form in the dashboard, a /blueprint command in the CLI, the TUI and the messengers, a conversation in which the agent asks for what it needs one question at a time, and an entry in the docs catalog. The developer-facing Automation Blueprints page shows examples any software organization will recognise:

The Automation Blueprints guide page (hermes-agent.nousresearch.com/docs/guides/automation-blueprints) lists 17 blueprints as of 1 September 2026 — beyond the table above it adds Competitive Repository Scout, AI News Digest, Paper Digest, Stripe Payment Monitoring, Daily Revenue Summary and Content Pipeline (that count is attributed to the guide page only; the reference catalog is client-rendered and I could not count it). The organizational consequence of "blueprint = skill" is the useful part: you manage them the way you manage every skill — through the skills hub, through profile export — and when you are looking after many machines, #10 Desktop & Fleet picks the story up.

Hermes as a Backend for the Apps You Already Run

The fifth door is the inversion: instead of Hermes calling other systems, other systems call Hermes. Since v0.4.0 the gateway carries an OpenAI-compatible API server (the release note says it shipped "hardened with input limits, field whitelists, SQLite-backed response persistence, and CORS origin protection" from day one):

# ~/.hermes/.env  (or gateway.api_server.* in config.yaml — env wins)
API_SERVER_ENABLED=true
API_SERVER_KEY=<long-random-key>      # mandatory, even on loopback

# start the gateway as usual — the API server listens on http://127.0.0.1:8642
hermes gateway

# any OpenAI client works
curl http://127.0.0.1:8642/v1/chat/completions \
  -H "Authorization: Bearer $API_SERVER_KEY" \
  -H "X-Hermes-Session-Key: helpdesk-user-4471" \
  -H "Content-Type: application/json" \
  -d '{"model":"hermes","messages":[{"role":"user","content":"Summarise my open tickets"}],"stream":true}'
# the model name is configurable via gateway.api_server.model_name — read the real value from GET /v1/models

Limits to know before you design around it: no file upload, a default cap of 10 concurrent runs (max_concurrent_runs), and the hermes-api-server toolset drops clarify, TTS, computer_use and send_message — there is no human on the other end to ask.

The first app most organizations plug in is Open WebUI — and Open WebUI's own documentation carries a "Connect an agent → Hermes Agent" page: base URL http://localhost:8642/v1 (host.docker.internal from Docker; the /v1 suffix is required), the API key is API_SERVER_KEY, and the gateway must stay running. Hermes's Open WebUI page adds that tools execute on the API-server host, that Open WebUI talks server-to-server so no CORS setting is needed, and that per-user isolation is done with profiles on separate ports.

hermes peer, A2A, and what hermes mcp serve does not do

These three are routinely confused with one another:

• hermes peer (v0.21.0, PR #88725) lets two Hermes instances talk across hosts — but it is not A2A. The PR says it "uses the peer's existing api_server platform as the wire" (POST /api/sessions/{id}/chat with a bearer key). Peers are configured under bot_peers, keys live in .env as HERMES_PEER_<NAME>_KEY, and the CLI is hermes peer add|dm|run --idempotency-key|status|stop. Replies land in each side's Bot Chat.
• A2A (a bundled plugin implementing A2A v1.0, PR #77109, v0.20.0) listens on port 9900, serves /.well-known/agent-card.json and JSON-RPC 2.0 (SendMessage, SendStreamingMessage, GetTask, ListTasks, CancelTask) — for talking to other vendors' agents that speak the standard. The client toolset is off by default, the server binds 127.0.0.1 by default, a remote bind requires a token, and there is an audit log at ~/.hermes/a2a_audit.jsonl. The doc itself says that for same-machine work you should prefer delegation or Kanban (#2).
• hermes mcp serve (v0.6.0, 30 March 2026) does not expose the agent to anyone. The mcp_serve.py docstring says it exists to "expose messaging conversations as MCP tools": ten messaging-bridge tools (conversations_list, messages_read, messages_send, events_wait, permissions_respond and so on) over stdio only. There is no "ask the agent" tool. If you want Claude Desktop to read and answer messages in the channels Hermes manages, this is the thing for that; if you want an app to make Hermes think, go back to 8642.

# Claude Desktop config — this reaches Hermes's inbox, not its brain (the gateway must be running)
{ "mcpServers": { "hermes-messaging": { "command": "hermes", "args": ["mcp", "serve"] } } }

Hardening and Scaling the Automation Plane

Every door opened in this post has had an uninvited visitor. #4 Security tells the CVE record as a whole; four entries belong specifically here:

The first two name hermes-agent 0.8.0. The INSECURE_NO_AUTH story needs its full context: the official webhooks page itself sanctions it for loopback testing — it is a documented test switch, not a hidden backdoor — and what the CVE records is that the switch can disable signature verification for a whole route. The PR-review guide carries the line worth pinning to the wall: "Never use INSECURE_NO_AUTH in production." Three further entries on the same surface are now NVD-listed (checked 1 September 2026): CVE-2026-10224 (published 1 June 2026, CVSS 3.1 5.3 — _handle_webhook_request in gateway/platforms/feishu.py leads to resource consumption, remotely triggerable, 2026.4.0–2026.4.30; fixed by the "webhook body-cap sweep" PR #59215), CVE-2026-53869 (17 June 2026, CVSS 3.1 7.5 HIGH — a DNS-rebinding vulnerability in WebSocket endpoints that bypasses Host and Origin validation, <0.16.0) and CVE-2026-53870 (17 June 2026, CVSS 3.1 5.5 — response_store.db and webhook_subscriptions.json created world-readable at 0o644, exposing conversation history and HMAC secrets to local users, <0.16.0). After that, between 3 July and 6 August, a steady trickle of eleven further low-severity VulDB entries landed on other Hermes surfaces — the consolidated record is in #4 Security.

The hardening checklist I distilled from every document in this post:

• ☐ Run v0.21.0 or later — every entry above names a version before 0.16.0.
• ☐ Port 8644 sits behind a TLS-terminating reverse proxy; every route has a long random secret; use Generic V2 with its timestamp, never V1.
• ☐ Leave a route's toolsets alone unless you must — the four safe tools are the right default.
• ☐ 8642 and 9900 listen on 127.0.0.1 unless there is a reason, and always carry a key or token.
• ☐ A shell hook acting as a guard sets fail_closed: true — the fail-open default means a broken script is no guard at all.
• ☐ cron.allow_agent_scheduling is still false and preflight is still true.
• ☐ Test the hooks for real after every update — this one has a history.

Hook reliability has not been a smooth story: issue #2817 (hooks not firing) preceded the v0.5.0 release note of 28 March 2026 announcing that lifecycle hooks "now fire", and issue #44582 (opened 12 June 2026 on 0.16.0: "pre_tool_call plugin hook not invoked during agent tool execution") was closed as not planned with no visible maintainer response. I am not saying hooks do not work today — I am saying do not believe it until you have seen it:

# after every hermes update — make it part of the runbook
hermes hooks test pre_tool_call
hermes hooks test on_session_end
hermes plugins doctor --ci        # CI-friendly exit code
hermes cron doctor

Chronos — cron for a gateway that is allowed to sleep

The one architectural problem with built-in cron is that it needs a gateway that is awake all the time to tick every 60 seconds — which contradicts the scale-to-zero hosting #7 discussed. v0.17.0 (PR #48275) therefore made the scheduler pluggable and added a provider called Chronos, specified in the repo document docs/chronos-managed-cron-contract.md: instead of ticking itself, the gateway registers its jobs with an external service that arms one-shot timers; when one fires, the service calls back to /api/cron/fire with a short-lived JWT (roughly 60–120 seconds, aud=agent:{instance_id}, purpose=cron_fire), the gateway answers 202 {"status":"accepted"} and runs the job in the background — at-most-once via a compare-and-set on the store.

# config.yaml — enable Chronos; leave it unset and the built-in ticker is used
cron:
  provider: chronos
  chronos:
    portal_url: …
    callback_url: …
    expected_audience: …
    nas_jwks_url: …

This is the mechanism that lets a hosted gateway that scales to zero — the kind Hermes Cloud advertises — keep its cron jobs without paying for an idle machine. I will not print Cloud prices or server sizes, because there are no official figures. For a self-hosted single VPS the built-in ticker is enough; Chronos is the option when you move to hosting that bills only for time actually worked.

A closing note for anyone migrating from OpenClaw: as #7 recorded, hermes claw migrate does not carry cron jobs or hooks across — and I see that as an opportunity rather than a chore. Every heartbeat in the old system deserves to be asked again whether it is a watchdog (layer 1), a monitor (layer 2), or work that genuinely needs thought (a regular cron job). My bet is that most of them fall into the first two.