Hermes — The Complete Guide
Gardax — the network's worker agent: research, scraping, media & data-science
In my network today, Hermes is Gardax — the comic-cast character alongside Kami, Kaylee, Box and Solis, and the network's studio/worker agent: an autonomous expert worker that takes jobs from Claude Code (the orchestrator) and returns structured output. Its responsibilities: research, scraping data off the web (scrape), generating visual assets and media (media generation), data-science analysis, running cron, and delegating coding tasks to coding agents like codex/opencode. It runs on free Gemini and chats on Telegram in text and voice via the bot @elad_hermes_bot. Mind the division of labor: writing content and posts now belongs to Ranch (the content agent); Hermes supplies him the media and illustrations, but Ranch writes the copy. The name 'Hermes' stays because the agent grew out of a self-healing (autoheal) infrastructure pattern — but today the network's live self-healing lives mostly in the autonomy stack (remediation.py + fix proposals from Aurora/Oracle), and Hermes itself is first and foremost the worker agent. For you it's a general pattern for any agent network: a headless component that does the 'heavy lifting' (research, scraping, media, data) and returns clean output to the orchestrator — without burdening the human interface.
What this guide covers
What is Hermes? The network's worker agent
A headless component that takes a work task from the orchestrator, executes, and returns structured output
Hermes is the network's worker agent — the interface-less component that does the 'heavy lifting' on behalf of the orchestrator. It doesn't talk to Elad directly like Kami; it takes a structured task from Claude Code and returns clean output. Its responsibilities: research, scraping data (scrape), generating media and visual assets (creative_visual), data analysis (data_analysis), running cron, and delegating coding tasks to other coding agents (codex_exec). It runs on free Gemini and chats on Telegram in text and voice via @elad_hermes_bot. A historical note: the name 'Hermes' grew from a self-healing (autoheal) infrastructure pattern, and the guide below still details that pattern's five stages because it remains an important foundational idea — but today the network's live self-healing lives in the autonomy stack (remediation.py + Aurora's fix proposals), not in Hermes. Hermes itself is first and foremost the worker agent.
The self-healing pattern in detail — the 5 stages Hermes grew from
Background: each stage is simple and testable on its own; together they form a self-healing loop
The following sections describe the self-healing pattern the name 'Hermes' grew from — it stays in the guide because it's an important foundational idea for any autonomous system. Note: in my network today the live self-healing lives not in Hermes but in the autonomy stack (remediation.py + Aurora/Oracle's fix proposals); read that guide for the current implementation. The beauty of the pattern is that each stage is a short, independently testable function — which is why you can start with a minimal version and grow it incrementally. This is the canonical SRE approach at Google: a self-healing system is built from small, safe steps, not as one giant monolith.
Whitelist — what Hermes is allowed to do (and, crucially, what it isn't)
The whitelist is the safety harness of any self-healing system
The moment you give an automated script permission to run commands against production — you must define exactly what's allowed and what isn't. Hermes's whitelist is a small JSON file containing the list of permitted actions — without it, Hermes will do nothing. That's the difference between a system that lets you sleep soundly and one that accidentally wipes out your VPS.
Verification — the key to real reliability
A fix worked only if you can prove it worked — 'the command ran' is not enough
The most common mistake junior SRE teams make: 'I ran a restart, it returned 0, it's probably fine.' It isn't. Verification is the ability to prove that after the fix the service is genuinely alive, genuinely responsive, and genuinely doing what it's supposed to do. That's the difference between a Hermes that works and a script that runs at night and lulls you into feeling everything's fine — until morning reveals that the API was returning 500 all night long.
Memory — the memory that makes Hermes smarter every week
A Qdrant collection that remembers what worked for what — semantic search over historical fixes
Without memory, Hermes is a collection of scripts running in a loop. With memory — it becomes something that learns from your network. Every successful fix is stored as an embedding in Qdrant, and the next time a similar failure appears, a 40ms semantic search surfaces the action that worked before. That's the difference between a static system and one that gets smarter with every incident.
Escalation — when it's right to wake you (and as little as possible)
The gold of self-healing: alert only when it's truly worth your sleep
Escalation is a last resort — the moment Hermes throws its hands up and says 'I can't do this, please help.' The whole point of Hermes is to cut alerts down to 10% of cases — reserved only for the new and interesting. If Hermes sends too many alerts, that's a sign the whitelist or memory isn't good enough, not a sign that 'the tool is noisy.' PagerDuty's starter plan runs $21/user/month (modern alternatives like BetterStack, Grafana OnCall or Squadcast come in cheaper still); Hermes costs $0 and saves your sleep on top.
Integrating with your stack — Hermes is a Pattern, not a service
How to embed the approach inside your existing agents and services
Important note: the Hermes pattern (detect→diagnose→fix→verify→learn) lives inside the agents and services themselves — cron jobs, webhook handlers, or in-code modules — not one central service. That's an advantage: effective self-healing is distributed across every component. 2026 update: beyond the self-healing pattern it grew from, today in my network Hermes is also the network's studio/worker agent — the headless component that generates assets, analyzes data, and runs code on behalf of the orchestrator. Both sides coexist: the pattern that keeps the server alive, and the agent that produces work on top of it.
