What are Hermes and OpenClaw?
Before I write about my own setup, I should define the two names that will show up a lot in this series: OpenClaw and Hermes.
The short version:
OpenClaw was my earlier experiment in getting an AI assistant closer to real engineering work.
Hermes is the agent runtime I am using now to make that kind of work more durable.
That distinction matters because I do not want this series to read like “I installed a chatbot and now everything is different.” That is not what happened. The interesting shift is from temporary AI conversations to repeatable workflows that can inspect files, run tools, remember stable context, delegate work, and leave behind enough evidence that I can debug what happened later.
What I mean by an agent workflow
A normal AI chat is mostly a conversation. You paste something in, get something out, and move on.
An agent workflow has more shape than that. It has inputs and outputs. It runs somewhere. It has tools. It has state. It has logs or artifacts. It has boundaries around what the agent is allowed to do. Ideally, it also has a way to stop and ask for human judgment.
That sounds less exciting than “autonomous software engineer,” but it is much more useful.
For me, the practical question is not whether an AI can write code. It can. Sometimes it writes good code. Sometimes it writes nonsense with confidence. The better question is: can I place a model inside a workflow where its output is constrained, reviewed, tested, and useful?
That is the thread behind this series.
Where OpenClaw fits
OpenClaw was the first environment where this started to feel real for me.
It moved the assistant closer to the places where work actually happens: local files, repos, infrastructure notes, GitHub, and chat. Instead of treating the model as a tab I visited when I needed help, I could start treating it as a tool that lived near my work.
That was the important lesson. Not that the agent was magical. It was not. The lesson was that proximity matters.
When an assistant can inspect files, edit drafts, run commands, and remember some context, the kinds of tasks worth delegating change. You stop asking only isolated questions. You start asking for work products: a patch, a review, a draft, a runbook update, a summary of what happened last time.
OpenClaw proved that direction was worth exploring.
It also had the feel of an experiment. Useful, but still experimental. Once I started using it for more real work, the next questions became obvious:
- How should durable memory work?
- How do reusable procedures become skills instead of repeated prompts?
- How do I search old sessions without pretending every old task belongs in permanent memory?
- How do I run the same assistant from terminal and chat?
- How do I schedule work without creating noise?
- How do I split work across subagents without losing track of the result?
Those are runtime questions, not just chatbot questions.
Where Hermes fits
Hermes is the system I am using now for that runtime layer.
Hermes is an AI agent runtime from Nous Research. It can run from the terminal, connect to messaging platforms like Discord or Telegram, use tools, keep memory, load reusable skills, search past sessions, schedule jobs, and delegate work to subagents.
That list matters less as a feature checklist and more as a set of building blocks.
A coding workflow can use files, terminal commands, project context, tests, and subagents. A blog workflow can use session search, repo inspection, Markdown drafts, and WordPress drafts. A GitHub automation workflow can use a webhook receiver, a queue, a worker, and Hermes-generated review output.
The same runtime can support all of those because the unit of work is not just “chat message in, chat message out.” The unit of work is closer to: task, context, tools, artifacts, verification, result.
That is the part I care about.
OpenClaw vs Hermes, in practice
This is not meant as a formal product comparison. It is how the transition feels from my workflow.
| Question | OpenClaw | Hermes |
|---|---|---|
| Role in my setup | Earlier experiment | Current foundation |
| Main value | Proved agents should live near real work | Makes that setup feel like a runtime |
| Mental model | Assistant with useful capabilities | Agent environment with tools, memory, skills, sessions, cron, and subagents |
| Best use in this series | Origin story and motivation | Main platform for concrete workflows |
| Risk | Easy to talk about it as the system even though I have moved on | Easy to over-explain implementation details too early |
The important point is that OpenClaw helped me find the shape of the work. Hermes is where I am trying to make the work repeatable.
Why start here?
I think this should be the first post because it gives the rest of the series a vocabulary.
If I start by describing my setup, I have to explain too much at once: Discord, CLI, Hermes, local repos, webhook services, GitHub PR review, memory, skills, subagents, scheduled jobs. That becomes an architecture post before readers know why any of it exists.
Starting with Hermes and OpenClaw is cleaner.
First define the tools and the shift in thinking. Then show the setup. Then walk through concrete workflows.
The series I have in mind looks roughly like this:
- What are Hermes and OpenClaw?
- Hermes as a personal agent runtime
- From OpenClaw to Hermes: why I am rebuilding my agent workflow
- Agentic workflows need boring guardrails
- Building a Hermes-backed GitHub PR reviewer
- Structured agent outputs: reviewer, fixer, arbiter
- What belongs in memory, what belongs in skills, and what should just be a file
That order lets the implementation details land later, when they are useful instead of overwhelming.
The opinionated bit
I am skeptical of agent demos that start with autonomy.
Autonomy is not the point. Leverage is the point.
A good agent workflow should make useful work cheaper without making responsibility blurry. If an agent edits code, posts a comment, or runs a scheduled task, I still own the outcome. That means the system needs boring things: logs, tests, queues, state, boundaries, and human escalation.
Hermes is interesting to me because it gives me a practical place to build those boring things around the model.
OpenClaw was the experiment that convinced me this was worth doing.
Hermes is the foundation I am building on now.
1 Response
[…] the first post in this series, I defined the split between OpenClaw and Hermes: OpenClaw was the earlier experiment, Hermes is […]