Five Hermes Agent Patterns I Wish I Had Started With

Hermes Agent becomes much more interesting after the first chat. I do not want another blank prompt waiting for me to invent a question. I want it to notice that Uber moved sharply, apply the same watchlist rule to Micron, remind me that the front door is still unlocked, prepare a useful morning brief, and remember how I publish this site.

The difficult part is not finding things to automate. It is choosing the right Hermes feature for each job.

This is the map I wish I had when I started:

Those features overlap, but they are not interchangeable. These are the five patterns that made the distinctions click for me.

They are not hypothetical categories. My current set of automations includes:

Automate the predictable without using a model

My simplest Hermes jobs are also some of the most useful. One watches a Home Assistant state and alerts me when the front door has been unlocked too long. The live stock job currently watches Uber (UBER) and speaks only when the price has moved at least five percent from its saved baseline. Micron Technology (MU) is a useful second ticker for showing how the same rule can cover a small watchlist without involving an agent.

Suppose the saved Uber close is $75 and a later check returns $80. That is a 6.7% increase, so Hermes sends a message with the old price, new price, and percentage change. If Micron moves from $200 to $205, the 2.5% change stays quiet. The companies are real; the prices here are deliberately simple examples of the rule.

Neither task needs interpretation. The condition can be expressed completely in Python, so I run it as a script-only cron job. Hermes provides the schedule, job history, and message delivery. The script supplies the decision.

The output contract is pleasantly small:

The request I give Hermes can stay close to the outcome: “Watch UBER and MU, save the last acknowledged price for each, and message me when either moves five percent. Do not send anything when both remain inside the band.” For the house: “Check the front-door lock every five minutes and alert me only after it has been unlocked for ten minutes.” Hermes can write each script and schedule it.

The important reliability rule is that a failed check must exit non-zero. If an API credential is missing or Home Assistant returns unavailable, silence is not success. I also keep state changes atomic and record an alert as delivered only after delivery succeeds. A watchdog should never look healthy merely because its error path returned the wrong status.

My decision rule: if I can determine the complete message with an if statement, I start with no_agent mode.

Schedule judgment when the result needs interpretation

Some recurring jobs cannot be reduced to a threshold. My morning technology brief is a good example. I do not want a dump of every headline in a feed. I want Hermes to find a small number of consequential frontend and AI infrastructure stories, link the primary sources, explain why each one matters to a working engineer, and ignore minor product announcements.

That requires selection, comparison, and writing, so it is a normal agent-driven cron job. The finished brief can arrive before I start work instead of waiting for me to open a chat and ask for it.

Hermes cron can run once or repeatedly, attach one or more skills, deliver to a configured channel, and be paused, edited, triggered immediately, or removed. Each run starts in a fresh agent session, which is useful: the job receives its instructions without inheriting a long, messy chat history.

I use a small routing table before creating one:

The script gate is especially useful. A cheap deterministic check can decide whether anything changed; the agent wakes only when there is something worth interpreting. That keeps quiet days quiet and saves model calls.

For every recurring agent job, I pin the provider and model. Hermes supports per-job pins and a separate cron default. Its drift guard can also stop an unpinned job when the global model changes instead of silently moving an unattended workflow to a different or more expensive provider. A scheduled model change is a deployment decision, not a casual chat preference.

My research, writing, and repository-maintenance jobs follow that rule: they have explicit providers and models. The token refresh does not. That job is a good candidate to convert to script-only mode because refreshing a credential is mechanical work; there is no reason to assemble a prompt or inherit the current chat model.

The destination is part of the automation

Telegram has become the most useful surface in this setup. The AI-agent news brief, Uber alert, and daily X coaching can reach me without another dashboard or a browser tab I have to remember to open. A scheduled job is far more valuable when its result appears where I already make decisions.

The current Telegram setup has an explicit user allowlist and home channel. Scheduled work can deliver to the originating conversation or directly to Telegram. That is a successful pattern: the computation happens on the NAS, but the useful moment happens on my phone.

WhatsApp is appealing for a different reason. A Friday list of San Francisco family ideas belongs in the family communication flow, not in a developer console. Hermes supports WhatsApp streaming, voice, and message delivery. Native polls and locations are useful too, but they are documented for bot mode rather than the self-chat mode my running bridge currently reports.

It is not working end to end yet. The WhatsApp bridge reports a connection, but Hermes has no registered WhatsApp home-channel entry, and the weekend-ideas job is blocked because its delivery target is considered unconfigured. The running bridge also identifies itself as self-chat while the saved platform configuration says bot mode. My next step is to choose one mode, run the setup flow again, register and test the home channel, then trigger the job manually before trusting the Friday schedule.

There is a larger operational caveat: Hermes’ built-in WhatsApp bridge uses Baileys, an unofficial WhatsApp Web client. The documentation describes a small account-ban risk, recommends a dedicated number, and warns that protocol changes can temporarily break the bridge. The session directory contains credentials equivalent to a logged-in device; mine is accessible to its Unix group, while the documentation recommends owner-only permissions with chmod 700. I would also change unauthorized private messages from the default pairing flow to ignore before putting a personal number on the internet.

The two channels have different presentation limits:

That suggests a simple editorial rule: send a concise conclusion and the next action to chat, then link to a longer artifact when the result needs tables, logs, or extensive evidence. Telegram’s rich-message support is worth testing on my clients, but I would enable it only after checking how the tables render.

Hermes can also fan a cron result out to comma-separated destinations, including origin,whatsapp or every connected home channel with all. That is useful for a genuinely shared reminder, but I would verify each destination separately first. Multi-channel delivery should not turn one broken route into an ambiguous partial success.

My scheduled deliveries are currently fire-and-forget because cron.mirror_delivery is off. That means I can receive an X-coaching brief in Telegram, reply to it, and discover that the new message does not continue the job’s agent session. Hermes can make a single-channel delivery continuable with attach_to_session; Telegram can isolate it in a topic, while WhatsApp mirrors it into the same direct-message conversation. Fan-out deliveries are not continuable. I would enable this per job for the news and coaching briefs, but keep threshold alerts stateless.

Give Hermes procedures as skills and facts as memory

Publishing this article is a repeatable workflow. The content belongs in a particular directory with required frontmatter. The site must build, links must resolve, the sitemap and feed must include the article, and the page needs a visual check at desktop and mobile sizes. I should not have to restate that checklist every time.

That procedure belongs in a skill. Facts such as “the site uses Astro,” “it deploys through Cloudflare Workers,” and “the repository lives in this directory” belong in memory or project instructions. I originally treated all of this as extra context. The better distinction is simple:

Skills are particularly effective because Hermes uses progressive disclosure. It begins with compact names and descriptions, then loads a skill’s full instructions only when the task calls for them. A detailed deployment or research workflow therefore does not consume the context window during unrelated conversations.

The practical trigger for me is repetition. If a useful task takes five or more steps and I expect to do it again, I ask Hermes to save the method as a skill. “Publish this field note” can then mean: check its metadata, validate the site, inspect the generated route, verify mobile layout, and report anything that blocks release. The next run becomes easier to request, easier to review, and less dependent on whether I remembered every step.

Memory should stay smaller. It is best for durable facts, preferences, project locations, and choices Hermes would otherwise have to rediscover. Procedures do not belong there, and temporary observations should not become permanent personality.

This part of my setup is only halfway mature. Memory, user profiles, checkpoints, and the background curator are enabled. The skill library contains useful procedures for social voice, local events, family routines, GitHub work, static-site SEO, and research. Yet only the AI-agent news job currently attaches named skills. The daily X job should load the social-voice skill; the family weekend job should use local-events discovery; and repository maintenance should load the relevant GitHub and software-maintenance procedures. I have already written much of the method—the schedule simply is not using it yet.

Delegate independent work, not every piece of work

When I was deciding how a Hermes web interface should work, there were several questions that did not depend on one another. One researcher could read the Hermes API and toolset documentation. Another could compare Open WebUI integration options. A third could review which tools would be unsafe to expose through a browser. The parent agent could combine the three conclusions into one implementation plan.

That is a natural use of subagent delegation. Each child starts with fresh context, gets its own terminal session and restricted tools, and returns only its final summary to the parent.

That makes delegation good for work that is both independent and reasoning-heavy:

The clean context is as important as the parallelism. A research subagent can absorb dozens of pages and return a focused conclusion without filling the main conversation with every intermediate step.

There are deliberate boundaries. Subagents cannot ask the user for clarification, write shared memory, or send messages to external platforms. Their work is tied to the owning session and Hermes process, so durable background work belongs in cron or a background terminal task instead.

I also give each subagent the smallest useful toolset and a precise deliverable. “Research this” is vague. “Compare these three libraries on bundle size, browser support, maintenance, and migration cost; cite primary sources in a table” is something a clean-context worker can finish and the parent can evaluate.

I tested that process boundary instead of relying only on the documentation. A one-shot CLI session launched three research children, returned immediately, and then shut down. Hermes interrupted the children during CLI shutdown even though the delegation record still appeared to be running. The same batch completed when I kept an interactive parent session alive. Delegation worked; my first execution mode did not.

The successful run revealed a second limitation. I gave all three children only the web tool and asked each to inspect a different part of the official documentation. They finished independently, but all three reported that the configured web backend could not retrieve the pages. Parallel agents multiply capability, not capability configuration. A missing dependency can produce three fast failures instead of one useful answer, and the parent still has to verify every summary.

The best delegation candidates in my setup are concrete:

Its limits shape how I write the task:

Delegation is therefore available but not yet established in my setup. Hermes currently allows ten concurrent children and inherits the parent’s model because no separate delegation model is pinned. Ten is more concurrency than these personal workflows need. I would lower the limit to three, fix and test the web backend, then introduce delegation only where the branches are genuinely independent.

Design the boundaries before adding more automation

The web interface makes tool boundaries concrete. I might want it to search my published writing, research a question, and prepare a draft. I do not want an ordinary browser session to unlock the front door, edit arbitrary host files, or run an unrestricted shell command.

Hermes can expose terminal access, files, web research, messaging, Home Assistant, scheduling, memory, delegation, and other tools. The feature is not that every conversation receives all of them. The feature is that toolsets can be selected for the job and the platform.

A private command channel and a shared browser interface should not have identical capabilities. I think about each entry point as its own product:

The official security guide treats this as defense in depth: user authorization, command approvals, file safety, container isolation, credential handling, session isolation, and input validation reinforce one another. Prompts can describe intent, but the registered tools define actual capability.

Several of those layers are already in place. Telegram and WhatsApp have explicit user allowlists. Dangerous commands require manual approval, while unattended cron jobs deny them. Checkpoints, secret redaction, command scanning, automatic session pruning, and tool-loop hard stops are enabled. The API server is bound to loopback, and the Docker socket is not mounted into Hermes.

The largest remaining gap is capability scope. Telegram uses nearly the same broad tool catalog as the CLI. The WhatsApp platform bundle also includes full agent tools, and the API server intended for a web UI still includes terminal and file access. That is more authority than a news brief, stock alert, or family recommendation needs.

The container boundary can be tightened too. The application processes run as an unprivileged user, but the supervisor starts as root; the root filesystem and mounted directories are writable; the dashboard listens on every host interface; and there are no CPU, memory, or process limits. Tirith command scanning is enabled, but it is configured to fail open if the scanner is unavailable. None of these choices means the system is unsafe by itself. Together they define the next hardening pass.

This changes how I expand the system. Before adding a new automation, I write down its trigger, required tools, model, delivery target, failure signal, and owner. Then I test the unhappy paths: unavailable API, missing credential, failed delivery, repeated event, and overlapping run.

That produces a compact definition of “done”:

Applied to my current setup, the practical backlog is short:

That is the larger lesson I have taken from Hermes. A useful personal agent is not a chatbot with more permissions. It is a collection of carefully chosen execution modes: deterministic scripts for facts, agents for judgment, skills for methods, memory for durable context, and subagents for clean parallel work.

Once those pieces have clear boundaries, adding a new automation feels less like granting an AI more power and more like designing a small, understandable system.

---

Continue from here:

• Reproduce the reliability rules: KahWee Labs.
• Start with the runtime: Run Hermes Agent on a UGREEN NAS.
• Add a home integration: Connect Hermes Agent to Home Assistant.
• Follow the series: Applied AI Systems: Hermes Agent.