From OpenClaw to Hermes: why I rebuilt my agent workflow

In the previous post, I described Hermes as a personal agent runtime. That explains the setup, but leaves an obvious question: why change the setup I already had?

OpenClaw had already convinced me that an assistant was more useful when it could work near my repositories and files. I could ask it to inspect something instead of assembling a context packet by hand. That was enough to make me keep experimenting.

The harder question came afterward. How much of that work could I repeat without reconstructing the conversation that made it succeed?

What I wanted to keep

I wanted both a terminal interface and a messaging interface. When I am actively debugging, the terminal makes sense. For a draft, a review request, or a status check, Discord is often more convenient.

I also wanted the assistant to retain useful context. Repeating project conventions at the beginning of every task gets old quickly. But keeping every detail forever is not a sensible alternative. A preference about how to review code has a different lifetime from the result of yesterday’s test run.

OpenClaw was where I explored that workflow. Hermes became the place to consolidate it.

That is a description of my experience, not a claim that OpenClaw lacks every feature I use in Hermes. I am not trying to maintain a product comparison matrix. Both projects change, and a list of checkmarks would tell you little about whether either fits your work.

Giving context a home

The part I like about Hermes is having explicit places for different kinds of context.

A reusable procedure belongs in a skill. Stable preferences belong in memory. Previous decisions can be recovered from session history. A draft belongs in a file where I can inspect it and decide whether it is any good.

Consider this blog. Asking an agent to continue a series should start with the published posts and the existing drafts. It should not start with the model inventing a plausible series from the word “continue.”

The same applies to code. Before a reviewer explains what a service does, it should inspect the service. An old implementation plan may describe a feature that now exists, or one that was never built. Remembering the plan is useful; treating it as current evidence is not.

Hermes gives me tools for that separation. I still have to use them properly.

The work outside the runtime

A runtime does not remove the need to build ordinary software around it.

My PR reviewer has a small webhook receiver because receiving GitHub events is a service problem. Request validation, duplicate detection, and worker dispatch should not depend on a model interpreting a paragraph correctly.

The model gets a narrower job: examine a change and produce a review. The surrounding code decides how that result enters the workflow.

I could put more of the process into one long agent session. That would be quicker to demonstrate and harder to inspect when it failed halfway through. For recurring work, I prefer a little more explicit plumbing.

What the move does not prove

Moving to Hermes does not prove that the reviews are more accurate, that I ship faster, or that the system is safe to leave unattended. Those need their own evidence. I do not have a benchmark to offer here.

It also means maintaining another environment: tools, credentials, saved procedures, and whatever small services connect it to the rest of my work. That cost is real. For an occasional coding question, a normal chat may be enough.

For the recurring workflows I want to build, the tradeoff makes sense. I want the next run to start from a known procedure and leave an artifact I can inspect, rather than depend on a particularly good conversation.

The next post is about the constraints around those runs: what an agent may do, what counts as completion, and when it must stop.