OpenClaw vs Hermes Agent: picking the right agent for the job

I've spent the last few weeks running both OpenClaw and Hermes Agent against real work — monitoring a couple of xCloud sites, summarizing customer-success channels, automating a few PR-review rituals, and one slightly-too-ambitious experiment where I let an agent watch a flaky CI job for three days. They are not the same shape, even though every benchmark thread treats them as alternatives.

The short version: OpenClaw is a personal AI assistant; Hermes is a self-improving coding agent. They overlap in install instructions and lobster jokes, and almost nowhere else. If you pick by GitHub stars instead of by problem shape, you'll end up fighting the tool you chose.

What each one actually is

OpenClaw, by Peter Steinberger, is a local-first gateway that connects your messaging platforms to an LLM-backed assistant. You install it, point it at WhatsApp or Telegram or Slack or any of the two dozen channels it supports, and an agent starts answering you on whichever one you happen to be in. Configuration, memory, and skills live as plain files in ~/.openclaw, which the agent (and you) can read, edit, and version. Skills are folders with a SKILL.md describing tool usage. The product is the assistant. The Gateway is just plumbing.

Hermes Agent, by Nous Research, is a self-improving agent framework. It has the same multi-channel pitch on the surface — Telegram, Discord, Slack, WhatsApp, the rest — but the interesting part lives further down. Hermes runs on one of seven terminal backends (local, Docker, SSH, Singularity, Modal, Daytona, Vercel Sandbox), so where the agent executes is decoupled from where you talk to it. After completing a multi-step task, it can autonomously write a reusable skill capturing the procedure. The next time a similar task appears, it loads that skill instead of starting from zero.

OpenClaw is your assistant. Hermes is your colleague-shaped daemon. The difference shows up the moment the task gets boring.

Architecture, where it gets interesting

Both products are gateway-plus-agent. Both treat messaging surfaces as first-class UI. Both store configuration as plain files. But the architectural emphasis is different in ways that matter for the work I do.

OpenClaw — channels first

• One Gateway routes inbound channels and accounts to isolated agents — workspaces with per-agent sessions.
• The Live Canvas, voice wake on macOS/iOS, and continuous Talk Mode on Android make it feel like a phone assistant that lives on your machine.
• Skills are dropped into ~/.openclaw/workspace/skills/<skill>/SKILL.md. Bundled, managed, and workspace skills coexist; workspace skills win.
• The default mental model is "I message my assistant; my assistant does the thing".

Hermes Agent — execution first

• Seven terminal backends. The same agent can run on your laptop, in a Docker container, on a $5 VPS over SSH, or on a Modal serverless worker that hibernates when idle.
• A closed learning loop: when a complex task succeeds, the agent writes a structured skill markdown — procedure, pitfalls, verification — that future runs load instead of re-deriving.
• Model-agnostic by design — Nous Portal, OpenRouter, OpenAI, Anthropic, Gemini, DeepSeek, any OpenAI-compatible endpoint. Switching models is one command and no code changes.
• Subagents are isolated. They have their own conversations, terminals, and Python RPC scripts, so you can pipeline work without it costing your main session's context budget.
• The default mental model is "I describe a goal; the agent does the thing now, and remembers how, so next time it's faster".

Both have OAuth, both have MCP tool integration, both have cron jobs. But "what is the first thing this system makes easy?" is different. OpenClaw makes chatting easy. Hermes makes compounding easy.

Use cases where I'd pick OpenClaw

OpenClaw shines wherever the bottleneck is "I want to do this from my phone, without opening a laptop, without thinking about it twice".

1. Life admin and inbox triage. Triage emails, monitor bills and deadlines, surface daily briefings on the channel I already check. There's a reason the community guides are mostly about this — it's where OpenClaw obviously wins.
2. Customer-facing channels with curated permissions. A scoped assistant on a Discord or Slack that can answer questions, run a few specific automations, and forward edge cases to a human. The per-channel allowlists matter here; you don't want every member of a community DMing your agent into oblivion.
3. Voice-first quick wins. "Hey OpenClaw, what's on my calendar?" from a phone, with continuous voice on Android. Sounds frivolous. Saves real minutes per day.
4. Personal knowledge agents. Point it at your Obsidian, your notes, your saved transcripts. Let it answer in the channel you already use to take notes.

What I would not pick OpenClaw for: long-running technical jobs that need their own execution environment, anything that should outlive my laptop's uptime, or work where I want a sandboxed execution surface separate from my personal channels.

Use cases where I'd pick Hermes Agent

Hermes earns its keep when the task is technical, repeatable, and benefits from a memory that survives logout.

1. "Watch this repo and tell me when something starts smelling bad." Hermes on a Modal backend can sit on a CI job, file an issue when tests flake three times in a row, and never expense an idle minute. The fact that the watching thing doesn't have to be your machine is the whole point.
2. Codebase-aware refactors with a learning curve. The first time you ask it to do a tricky migration, it costs a lot of tokens. The fourth time, the auto-generated skill loads the procedure and it's a fraction of the cost. That curve doesn't exist in stateless agents.
3. Customer-environment automations over SSH. The SSH backend lets you run an agent inside a VPC for a consulting engagement without exposing the inference layer to that environment. Useful for the regulated-data crowd.
4. Pipelines of small subagents. A "spec a feature → write the diff → run the tests → write the PR description" chain, where each step's context doesn't pollute the next. The subagent isolation pays off here.
5. Anywhere persistent memory beats clever prompting. If you've ever written a 400-line CLAUDE.md just to keep an agent aware of your codebase conventions, you'll recognize what Hermes's skill loop is trying to fix.

What I would not pick Hermes for: pure personal-assistant work where the conversation surface matters more than the execution surface, or anywhere I want a turnkey "chat with my life" experience without a meaningful setup commitment.

Where they overlap, and how to choose

There's a real overlap zone where both will technically work and you have to pick based on taste:

• Multi-channel chatops. Both expose the same set of messaging platforms. OpenClaw is friendlier out of the box; Hermes wins if you want the same chat surface to drive sandboxed code execution.
• Personal automation. Both can run cron jobs and natural-language schedules. OpenClaw treats it as a feature; Hermes treats it as a side effect of the agent loop.
• Skill libraries. Both have a skill abstraction. OpenClaw's skills are author-curated; Hermes's are author-curated plus agent-generated. If you trust the agent enough to let it write its own playbooks, Hermes is more interesting. If you don't, OpenClaw's discipline is a feature.

My rule of thumb, when I have a new task and both could plausibly do it:

Pick OpenClaw if the goal is "answer me on Telegram". Pick Hermes if the goal is "do this for a month while I'm asleep".

The security conversation, briefly

Both projects have an honest problem: an autonomous agent on your machine, connected to your messaging accounts, talking to a big LLM, is a serious blast radius. The OpenClaw team has publicly warned that if you can't run a command line, the project is too dangerous for you to use safely — and Cisco's AI security group has already published findings about a third-party OpenClaw skill performing data exfiltration without user awareness. Skill repositories aren't vetted.

Hermes inherits the same class of problem from a slightly different angle. Every MCP server you install is code running with the agent's authority. There's no signing, no sandbox, and the discovery surface (a GitHub link, a Slack rec, a blog post) is the same surface that made npm a decade-long supply-chain problem. The day a popular community MCP server goes bad, a lot of dev machines find out at once.

Practical things I do regardless of which agent I'm running:

• Bind the gateway to localhost and put a real authentication layer in front of any remote channel.
• Allowlist who can DM the agent. Phone numbers, account IDs, Discord member IDs — name them explicitly.
• Audit every community skill or MCP server before installing. If you can't read the code, don't run it.
• Don't give the agent credentials it doesn't strictly need. The session log is a searchable archive of everything it saw — treat it like a secrets database, because it is one.
• Start with low-stakes tasks and graduate the agent to more access only after you've watched it work for a week.

How I actually use both right now

OpenClaw lives on my MacBook. It handles morning briefings, calendar nudges, and "hey, summarize this thread before I open it". It's the assistant my partner and I both talk to on a private Signal thread.

Hermes lives on a small Hetzner box. It watches a couple of repos, runs scheduled audits, drafts release notes, and accumulates a slowly-growing folder of skills that are starting to feel less like "AI output" and more like genuine institutional knowledge written down. The first time it pulled up a skill it had written a month ago and used it to nail a near-identical task in a quarter of the time, I started taking the framing seriously.

Neither tool replaces my IDE-bound coding agent or my CI. Both have started replacing certain rituals I used to do by hand. That's the right level of ambition for them, at this stage.

What I'm watching next

Three things will decide whether either of these matters in 2027:

1. Will skills become portable? Right now my Hermes skill folder is a private artifact. If a real exchange standard (something like agentskills.io) emerges and gets adopted across agents, the network effects are huge. If everyone hoards, both projects stay personal tools forever.
2. Will an enterprise distribution land? Signed skills, audit logs, role-based approval, a real control plane. Someone — possibly Nous, possibly a third party — will ship it. When it does, regulated workloads get an answer.
3. Will the security model harden faster than the attack surface grows? Both projects are racing the same supply-chain problem npm took ten years to half-solve. Whoever gets to "you can install a community skill safely" first wins the prosumer mind-share.

For now, both are worth running. Not as the answer, but as a useful preview of what working alongside a long-lived agent feels like. Pick one for the chat surface, one for the execution surface, and resist the urge to make either of them do the other's job.