Monitoring
18. Monitoring — Hermes as a Proactive Monitoring System
This is the area that clearly differs from chapter 17 (Business) or 16 (Content): instead of responding when asked, this is what Hermes does quietly in the background, self-evaluating, and speaking up only when there is something worth saying. All six sub-sections below are built on the same underlying mechanism — the cron scheduler described in 17.4 — but applied in a “watch” direction rather than an “execute a task” direction.
The shared architectural principle: a “boring stack” — scripts do the mechanical work, the model does the reasoning
This is the most important point running through the entire chapter 18, clearly illustrated by the case study of building a competitor-tracking system: the standard architecture is YAML for the registry, Python for fetching/diffing, SQLite for persistent state, Hermes cron for the schedule, Hermes skills for reusable procedures, and messaging for delivering alerts. No dashboard, no vector database, no letting the agent “browse the web from scratch every morning on its own” — start deterministic (scripts do the mechanical work: fetch data, compare), and only add LLM synthesis after the diffs have proven valuable.
The [SILENT] mechanism — the heart of every monitoring job
This is the pattern repeated across all six sub-sections: a good monitoring job must stay silent when there is nothing worth saying. If there is nothing new, the agent replies exactly [SILENT] and nothing is sent — avoiding turning the alert channel into noise that gets ignored. Important note: always write prompts in the form “reply [SILENT] only if nothing changed”, and avoid letting [SILENT] get buried inside a long explanatory paragraph — because the cron mechanism treats any [SILENT] marker that appears anywhere as the signal to suppress sending.
Two running modes — with LLM and without LLM
hermes cron create "every 30m" "..." --script check.py # with agent, script only provides context
hermes cron create "*/15 * * * *" "..." --no-agent --script health.sh # script-only, no token cost
With --script, the script runs before each turn and its stdout is fed in as context for the agent — the agent does only the reasoning part (“is this change noteworthy?”), while fetching/comparing is handled by the script. For simple watchdogs where the script already produces exactly the content to send (memory alerts, disk alerts, heartbeat), use --no-agent — the same scheduler, no LLM, no per-run cost.