Hermes Agent vs OpenClaw

Method.This is drawn from each project’s repository and documentation — commands, config paths, backends and licences are quoted from primary sources. We have not run either agent against a controlled task set, so nothing here is a performance claim. Both projects move very fast; verify anything operational before acting on it.

The short answer

If you want the one-line decision: OpenClaw if you want your agent’s state to be plain files you can read and edit; Hermes if you want the agent to accumulate capability over time. Everything below is why that is the actual axis.

The migration command tells you the most

Read what that implies. A project does not build and document a migration path out of a competitor unless it expects meaningful traffic in that direction — and the specificity here (a named file, a secrets allowlist, a dry-run flag) is the work of someone who has actually done the migration repeatedly.

hermes claw migrate                     # full import
hermes claw migrate --dry-run           # preview what would be imported
hermes claw migrate --preset user-data  # memories and skills, no secrets

The practical consequence for you is good, though: the switching cost in one direction is close to zero. That lowers the stakes of the decision considerably, and it argues for choosing on the property you care about rather than agonising over it.

Hermes Agent

Installation bundles its own toolchain — the installer ships uv, Python, Node.js, ripgrep, ffmpeg and Git Bash — which removes the dependency-wrangling that usually accompanies this class of project and is worth noting as a genuine usability decision.

Configuration lives in ~/.hermes/config.yaml (or %LOCALAPPDATA%\hermes on Windows) and is manipulated with hermes config set / get. The CLI surface is small and legible: hermes for the interactive TUI, hermes model to switch provider or model, hermes gateway to run the messaging bridge, and hermes setup for the configuration wizard.

The selectable backend is the underrated feature

Seven execution backends is unusual, and it matters more than the number suggests. An agent with shell access is only as contained as the thing running its shell — and being able to point tool execution at Docker, a remote host over SSH, or a hosted sandbox rather than your laptop is the difference between an agent you can give real work and one you supervise nervously. Hermes also documents running isolated subagents in containers, plus a command approval system for messaging and DM pairing for platform authentication.

OpenClaw

Its defining design decision is that memory and data are stored as Markdown files on your disk. That sounds mundane and is actually the most consequential property in this comparison, because it means the agent’s entire state is legible, greppable, version-controllable and editable by hand.

It reached a very large number of GitHub stars within days of launch, and was among the fastest-growing open-source repositories on record. Both projects have adoption numbers that get quoted constantly; treat all of them as directional, since the interesting question for you is fit rather than popularity.

Where they actually differ

The state row is the philosophical core. Plain files give you inspection and correction; a managed store gives you retrieval at a scale files cannot serve. If you have a thousand sessions, grep stops being an interface. If you have fifty, it is the best one.

The self-improvement loop, honestly assessed

Hermes writing its own skills is the more ambitious design and the harder one to evaluate without running it. The upside is real and matches something we would argue for independently: an agent that solves a multi-step problem, records the procedure, and reuses it is strictly cheaper and more consistent than one that re-reasons from scratch.

The corresponding caution is equally real, and it is not a criticism of the implementation. An agent that writes its own skills is an agent whose future behaviour you have not reviewed. For a personal agent that is an acceptable trade — you are the only one exposed. It is not an acceptable trade for anything acting on customers, which is the point of the section below.

Skills are portable, and that is a big deal

This deserves more attention than it gets, because it inverts the usual lock-in calculus. Normally the artefacts you build inside a tool are the reason you cannot leave it. Here the artefacts are the portable part and the runtime is the swappable part.

Practically: invest in skills freely. It is the one asset in this stack that survives your choice of runtime, and it accrues to you rather than to whichever project wins.

Neither is a product runtime

This is the most important thing in the article for anyone evaluating them for work, and it is not a flaw in either project. A personal agent should optimise for capability: you are the principal, the subject and the only party at risk. An agent acting on customers has three different parties in those roles, and that changes what the architecture must contain.

Both do ship real safety machinery — command approval for messaging, DM pairing, container isolation, a secrets allowlist on import. That is appropriate protection for a personal agent. It is not the same thing as governance, which is about what the agent may do to other people and who answers for it. For the distinction and what filling the gap involves, see the seven-layer stack and the agent threat model.

Choosing

Two things to do before granting either one real access, regardless of choice. Point tool execution at a container rather than your primary machine — Hermes makes this a configuration choice, and it is the single highest-value setting in either system. And run the migration with --dry-run if you are moving, because a secrets allowlist is a good default and not a substitute for looking at what is about to be copied.

A last note on where the interesting design work is. The most transferable idea in either project is Hermes’s skill loop — writing the procedure down once instead of re-deriving it every run — and it is transferable precisely because the skill format is portable. You can adopt that pattern in a system you build yourself without adopting either runtime, which is probably what most teams reading this should do.