Why Hermes Agent Should Be in Your Toolkit — And Already Is

Why Hermes Agent Should Be in Your Toolkit — And Already Is

September 1, 2026 — Jamie Michael Prince

A few months ago I was running three VPS instances, a Proxmox cluster, an Android test rig, a Cloudflare-brokered DNS-exfiltration lab, and two live NFT-market repos — frontend in TanStack, backend in Express/Knex — and I was doing it from a single terminal, a single chat window, and a single hands-on-keyboard agent that could remember what it did three weeks ago. That agent is Hermes Agent. If you're not using it yet, here's why you should be, and what it actually looks like when you stop treating it like a chatbot and start treating it like the operator layer of a small cluster.

What Hermes Is, and What It Isn't

Hermes is an open-source AI agent framework from Nous Research. It runs in your terminal, in a native desktop app, as a TUI with docked widgets, as a web dashboard, and as an OpenAI-compatible local proxy that lets Codex, Aider, and half the ecosystem plug into your choice of model without each one needing its own API key. It works with any provider — OpenRouter, Anthropic, OpenAI, Google, DeepSeek, xAI, local models, and twenty more. It speaks Telegram, Discord, Slack, WhatsApp, iMessage, Signal, Matrix, Teams, email, and more, with full tool access on each surface, not just chat.

It is not another "chat with your files" wrapper. It is a thing with memory that survives across sessions, a thing that learns reusable procedures as skills, a thing that can spawn subordinate agents via delegate_task, a thing that can run scheduled jobs through a real cron layer, and a thing that can fan a single task out to multiple peer agents across a network via A2A. That last bit deserves its own paragraph, because it's the part most people don't know yet.

The Cluster Piece: A2A

On my hardware I have three machines running Hermes peers — pm2, pm5, and pm7 — each reachable on the private mesh at port 9900, each with its own bearer token. Hermes knows them as named peers and can route work to them. The conversation graph across those peers is already populated: I've sent Proxmox-admin questions to the nodes, asked them what tools they have, asked them whether they can run pvesh/qm/vzdump, and watched them answer honestly — "I don't have a shell tool in this session, I can't run that command" — which is, in its own way, a feature. An agent that lies to please you is a liability; one that tells you it can't reach the host is one you can route correctly.

That's the shape of real multi-agent work: not a marketing diagram of "agent swarms," but a set of peers, each with a known capability surface, each honest about what it can and can't do, and a control plane — Hermes, on my local machine — that knows how to dispatch to them. When I need something done on pm7, I don't SSH in and type it myself; I ask the local Hermes to a2a_call the peer, or to a2a_orchestrate a task across capability-matched peers. The peers are honest nodes in a graph, not puppets. That distinction matters, because it means the system scales the way actual infrastructure scales: by adding more honest nodes and wiring them into the router.

The persisted conversation transcripts on this box — six of them at last count, keyed as ctx-* — are the record of that routing. They're the durable footprint of "I asked that peer to do this, it answered this way, here's the follow-up." That's the kind of thing that, in a smaller world, you'd keep in a ticket or a runbook. Hermes keeps it in the graph automatically.

What the Peers Actually Did

When I pulled status from each A2A peer for this piece, the answers were themselves a demonstration of the system's honesty.

pm5 (the Proxmox VE host) reported two concrete tasks from the last week. First, when asked to list all work in the last seven days, it told me it had zero visibility into files, repos, builds, cron, or deployments — no filesystem, shell, or git tools available. That was the honest answer. Second, it researched Jamie Michael Prince via North Data and returned concrete facts — Hove, UK; director of Byteone Ltd., Companies House #16896840 — with appropriate caveats about the limited data on that page. It also correctly identified its own hostname as almost certainly pve from the kernel string, without being able to run hostname.

pm2 and pm7 both hit model-provider failures when asked for their activity logs — the upstream model returned errors after retries. They reported the failure cleanly: "The model provider failed after retries. I kept raw provider details out of chat; check gateway logs for diagnostics." That's the correct behavior. An agent that silently invents an answer to cover a failure is a liability. One that tells you the model broke and points you to the logs is one you can trust.

This is what the A2A layer actually looks like in practice: not a seamless swarm, but a set of peers with varying tool access, varying model reliability, and a consistent commitment to not lying when things break. pm5 can do web research but can't touch the filesystem. pm2 and pm7 can't always reach their model provider. The control plane knows this, routes accordingly, and the conversation transcripts capture what happened for later review.

What I've Actually Built With It

The meal-suggestion skill and the cron that feeds me

The most boringly important thing Hermes does for me is email me breakfast and dinner every morning at 9am and a weekly shopping list on Mondays, generated from a live kitchen inventory that lives in inventory.json under the skill's directory. The skill was authored by the agent itself — that's the "self-improving through skills" loop in practice — and it encodes a real dietary constraint: I'm a recovering burns victim, I need high protein, I avoid red meat for purchases, and the target is roughly 190–200 g/day at my weight. The skill knows that. It also knows the egg cap (4 per meal, only one of the two meals may contain eggs), the disjoint-ingredient rule, the per-item max_per_meal caps, and the rule that red meat already in the kitchen may be used up but never re-bought.

The two cron jobs run on a schedule, read live inventory, build two meals, email them, and UPSERT into meal-history.json. They don't write inventory.json; inventory changes only via my chat edits. That invariant — learned the hard way — is what makes the system not lie to me about what's in the fridge.

There was a window — real, not hypothetical — where the gateway was down and the 9am run never fired, and stale future rows sat in the history uncorrected. The skill's design held: the next successful run overwrote them. But it taught me something about durable systems: a scheduled job that depends on a live gateway is only as reliable as the gateway. The fix wasn't to the skill; it was to the operational layer — pin provider and model explicitly on each job so a global inference-config drift doesn't silently skip the run. That's the kind of lesson that only shows up when you actually run the thing.

Ghost blog automation: the dev-update cron

The same pattern — skill + cron + real deliverable — powers the daily development-update post on my blog. A cron job runs the ghost-dev-update script every day, reads the last 24 hours of commits from both nft-market-backend and viri-nft-market, generates an overview, uploads a featured image, and publishes to Ghost via the Admin API. The script is Node, pinned to a specific Node binary, with NODE_PATH pointing at its own node_modules. It knows the Ghost subpath and the Cloudflare Flexible-SSL redirect trap that would otherwise loop forever, so it resolves the origin directly via a persistent /etc/hosts entry and trusts the self-signed cert.

The post from this morning processed 25 backend commits and 25 frontend commits, generated and uploaded a featured image, and published. The LLM overview hit a 429 from the upstream model at the moment of generation, so the script fell back to a simpler overview. The post still went out. That's the graceful-degradation story you want from a scheduled deliverable: when one piece blips, the rest of the pipeline carries.

The two repos it watches are real, active projects. nft-market-backend is a Node/Express backend with ESM, Knex + MySQL, Jest + Supertest, and a companion golangComponents/chainWatch process. viri-nft-market is a React + Vite + TanStack Router v1 + TanStack Query 5 frontend, strict-null TypeScript, with SSR via entry-server.tsx, locale routing under src/routes/$locale/, and a systemd-managed SSR service. The agent that owns those repos has an AGENTS.md in each that encodes the project conventions — canonical commands, edit discipline, the Git rule (stage and commit with a descriptive message after any meaningful change) — and the agent reads them before it touches files. That's not a nice-to-have; it's what makes the agent a reliable collaborator instead of a random refactorrer.

The Foundry/Slither IntelliJ plugin

One session — 118 messages, from a single can we create a idea plugin for foundry/slither prompt — produced a buildable IntelliJ IDEA plugin scaffold at /home/jp/IdeaProjects/idea-foundry-slither-plugin. Kotlin + Gradle with the org.jetbrains.intellij plugin, targeting IntelliJ IDEA Community 2024.2, with a FoundryProjectService that detects foundry.toml, a SlitherService that runs slither . --json - and parses findings into a tree, a FoundryToolWindowFactory with forge-build/forge-test/Slither buttons, gutter-ready run configurations, and settings for the forge and slither binary paths. The plugin.xml wires it all together. The repo moved from /home/jp/foundry-slither-plugin to /home/jp/Ideaprojects/ mid-session because the user said so, and the agent did it without losing the build state.

That session matters because it's the shape of an agent doing real software work — not generating a gist, but producing a project that opens in IDEA, has a tool window, and runs a Slither parse. And the honesty around it: the agent pointed out, correctly, that this machine can't build the plugin because the JetBrains plugin repo is unreachable from here, and that you need a local IntelliJ Platform SDK to compile it. So it scaffolded the thing, set the expectation, and stopped. That's the right behavior for a coding agent: produce the artifact, state the next step, don't fabricate a build that didn't happen.

The dns-exfil project

Then there's the DNS-exfiltration tool at /home/jp/IdeaProjects/dns-exfil — a C server, a Go handler, an Android client, a Wear OS module, DNSSEC signing on the VPS, and a Cloudflare-delegated subdomain whose wildcard NS points to a Fasthosts VPS. The client uploads data in base32 in the QNAME, the server reassembles, and the response encoding is adaptive — raw, base64, or base32 TXT depending on what the path probes back. There's an X25519 + ChaCha20-Poly1305 encryption layer for end-to-end. There's a cleartext-traffic-permission fix for the Android side. There's a systemd-resolved port-ownership quirk on pm7 that bit the Python sender but not test_exfil, and the agent diagnosed it from the ss output and the log shapes.

That project is the sharpest example of why you want a terminal agent with real shell access and real memory: it touches C, Go, Kotlin, JNI, CMake, Gradle, Android ADB over mDNS, DNS wire format, DNSSEC, Cloudflare's API, and a VPS firewall. A chatbot can't hold that whole state. A terminal agent with skills and memory can, because the state lives in the project files and the session transcripts, not in the context window.

The crash-watch cron

A quieter piece: a cron job that runs crash-watch.sh every few minutes, checks the last 30 minutes of the system journal for i915/drm hangs, soft-lockups, hung-task stalls, kwin BadDamage churn above 150, Chrome GPU-process crashes, thermal at or above 90C, and available memory under 1 GiB. It self-alerts via notify-send and writes to crash-watch.log only when a signal flares — normally it's silent, and the cron job reports calm / no alerts. That's the pattern you want for a monitor: cheap when nothing's wrong, loud when something is, and never writing noise to disk.

What Makes Hermes Different in Practice

The things that actually matter, in order of how often I notice them:

Memory that survives. Hermes keeps a canonical session store (SQLite + FTS5) and pluggable memory backends. When I come back to a project after a week, the agent remembers who I am, what my diet is, what my repos are, what my VPS topology looks like, and what I told it never to publish externally. That last one is concrete: I told it, explicitly, after a worklog post leaked an internal gateway IP, never to include internal/private IPs or infra-exposing details in external-facing content. It remembers that. It should. And it does.

Skills that encode procedures. A skill is a reusable procedure that loads into future sessions. The meal-suggestion skill, the Ghost-dev-update script's expectations, the dns-exfil AGENTS.md — these are all things the agent learned and saved so it doesn't re-derive them next time. The curator runs in the background, tracks usage, marks idle skills stale, archives them with a pre-run tar.gz so nothing is lost, and can consolidate overlapping skills into umbrellas if you opt in. That's a system that gets more useful the more you use it, without you managing it.

Cron that's a scheduler, not a glorified at. The cron layer is a real scheduler — cron/jobs.py plus cron/scheduler.py — with 3-minute hard interrupts per run, a .tick.lock file that prevents duplicate ticks across processes, per-job knobs for skills, model/provider override, a pre-run script, context_from chaining so job B can see job A's output, and multi-platform delivery. The meals cron and the dev-update cron and the crash-watch cron are all instances of the same layer, each with its own schedule and its own deliverable. That's how you run a small cluster's worth of recurring work: one scheduler, many jobs, each with a clear output contract.

A2A that's honest routing, not magic. The A2A layer lets Hermes call out to peer agents — including ones running on other machines — and get answers back. The peers are honest about their capabilities. The conversation transcripts are persisted. The orchestration mode (all / first / best) lets you choose how to aggregate. This is the piece that turns Hermes from a single-machine agent into a cluster operator: you put a Hermes peer on each machine that has something to do, and the control plane routes work to them by capability.

Provider-agnostic model routing. I've run this session on multiple free models via Nous Portal, and the session state — memory, skills, cron state — survives the switch. That's not a feature you notice until you hit a 429 and need to move to a different model mid-day without losing the thread. Then you notice it a lot.

Surfaces that all run from one core. The same agent drives the CLI, the Ink TUI, the desktop app, the web dashboard, and the OpenAI-compatible proxy. Point Codex or Aider at hermes proxy and they get an OpenAI-compatible endpoint backed by whatever provider you're signed into, with no API key of their own. That's a clean way to let a whole ecosystem of tools share one credential pool and one model preference.

Where It's Not Magic

I want to be honest about the edges, because an op-ed that claims a tool is perfect is a tool that, when it breaks, breaks your trust entirely.

Hermes is only as capable as the tools it has loaded. On an A2A peer that only has the FLUX 3 video tools and the A2A routing tools, you can't ask it to run pvesh and expect it to do it — it will tell you it can't, and that's the correct answer. The honesty is a feature, but it also means you have to wire the right tools into the right sessions.

Cron jobs depend on the gateway being up. I've seen a gateway_running: false state where the dispatch still succeeded as a background task, and I've seen the opposite. The lesson is to treat cron as "best-effort scheduled," not "hard real-time," and to pin provider and model explicitly so a global config drift doesn't silently skip a run.

Ghost posting via the Admin API has its own quirks: the subpath must be in the SDK url or you get INVALID_JWT; source: 'html' is the reliable path for content; Ghost may store the body in lexical even when you send html, so you verify with the Content API; and the Lexical sanitizer strips

, , class and style attributes, so you build post HTML with inline elements andseparators, not wrapper divs. None of that is a Hermes problem — it's the Ghost side — but it's the kind of thing a real operator learns and encodes.

The agent can't build the IntelliJ plugin on this machine because the JetBrains plugin repo is unreachable and there's no local Platform SDK. It scaffolds the project and tells you the next step. That's the right behavior, but it's also a reminder: the agent does the work it can do, and states the work it can't. You still have to be the one who opens IDEA and compiles.

And finally: an agent is not a substitute for knowing what you're asking it to do. The dns-exfil project required me to understand DNS wire format, DNSSEC signing, Cloudflare's DS record API, and a VPS firewall. Hermes accelerated the work — it generated the key-generation commands, diagnosed the systemd-resolved port-ownership quirk, wrote the C patches with setvbuf and fprintf(stderr, ...) markers to localize a crash — but it didn't replace the need to understand the domain. It was the fastest pair-programmer I've had, not the last word.

Why You Should Use It

Because if you're doing any of the following — running a small cluster of machines, automating a recurring deliverable, coordinating work across repos, or just tired of context-wiping between sessions — Hermes gives you a single operator layer that remembers, schedules, routes, and delivers, and that gets more useful the more you teach it.

Because the skill system means the procedures you discover — how to post to your blog, how to email your meals, how to run Slither on a Foundry project — stop being tribal knowledge in your head and become reusable artifacts that load automatically.

Because the A2A layer means you can put a Hermes peer on each machine in your cluster and route work to them by capability, with honest answers about what each one can do, and a persisted record of what was asked and answered.

Because the cron layer means your recurring deliverables — meals, blog posts, crash reports, build summaries — run on a schedule with a clear output contract and graceful degradation when one piece blips.

Because the memory layer means you come back to a project after a week and the agent still knows who you are, what your constraints are, and what it was doing last time.

Because it's provider-agnostic, so when your primary model hits a 429 at 9am on a Monday, you switch to another and the session state — memory, skills, cron — survives the move.

And because it's open source, from Nous Research, and runs on Linux, macOS, and Windows, with a documentation set indexed by a single llms.txt file that answers "can Hermes do X?" before you spend a session guessing.

I'm using it to run a cluster, feed myself, publish my dev log, watch for crashes, and scaffold plugins. It's not perfect. It's honest about its limits. It gets more useful the more I use it. That's the bar I care about, and Hermes clears it.