OpenClaw vs Hermes Agent: Two Open-Source Visions for Personal AI Agents

Two projects both advertise "open source, model-agnostic, multi-channel, MCP support." A builder picks one, ships it, and discovers the real difference the first time the process restarts, the channel count grows, or an approval prompt has to reach a phone. The feature list was never the comparison.

Why Feature Tables Fail for Agent Harnesses

OpenClaw and Hermes Agent overlap on almost everything a marketing page would list. Both are open source and MIT-licensed. Both are model-agnostic and connect to messaging surfaces. Both support MCP and run on your own hardware. That overlap is real, and it is also uninformative, because the features that converge are not the features that decide whether a deployment survives contact with production.

A harness is defined by four structural commitments: where state lives, who owns the control loop, where the trust boundary sits, and what the process lifecycle looks like. Feature tables flatten all four into checkmarks. Architecture does not.

I compare these two systems along five axes for the rest of this article: capability boundary, state ownership, execution model, autonomy and approval surface, and operational assumptions. The goal is not to declare a winner. It is to let you predict which system fits a given deployment before you commit a host to either one.

One evidence boundary up front: architecture claims here come from project documentation and independent write-ups, and both projects move fast. Treat version-specific behavior as something to verify against the running build, not something to assume from a description.

Two Mental Models: Control Plane vs Single Process

The single structural distinction that predicts most downstream differences is where each system puts its center of gravity.

OpenClaw is a persistent gateway daemon that owns all messaging-surface connections and coordinates clients, tools, and device nodes over a typed WebSocket protocol. The agent loop is one component inside a control plane. The gateway dispatches; the loop is a guest.

Hermes Agent is a single long-lived process whose role is fixed by the entry point used to launch it. Its gateway sub-command drives messaging surfaces through a two-tier adapter system — in-tree adapters plus a plugin tier for surfaces like Google Chat, IRC, and Teams. The loop is not hosted inside a dispatch layer. It is the process.

That difference is the same design-space question covered in the plugin-harness explainer, applied to two concrete systems rather than to a slogan. In OpenClaw, the center is dispatch and routing. In Hermes, the center is the process and its session. Everything below follows from that.

Capability Boundaries: What Each System Refuses to Own

Define the capability boundary as the set of things the system does not do. Boundaries are more diagnostic than capabilities, because every project eventually adds features, but few change what they refuse to own.

OpenClaw draws its boundary at the perimeter. It owns channel connections, identity, and access control, and treats the agent loop as a hosted component. It can even host an external harness — Claude Code, for example — as a guest over ACP. The gateway does not care what runs inside the loop as long as the loop speaks the protocol.

Hermes draws its boundary at the process. It owns the loop, the session, and the surface adapters, and pushes model and memory backends out to pluggable interfaces. The process is the product; the backends are configuration.

The practical test is this: ask which component must be replaced to change a behavior.

To change...	OpenClaw	Hermes Agent
A messaging channel	Gateway adapter	Surface adapter (in-tree or plugin)
The model	Hosted loop config	Provider config, per-skill routing
The memory backend	Gateway capability	Pluggable interface
The loop itself	Swap the hosted harness	Replace the process

When not to use each: if the requirement is a single scriptable process on a small VPS, a gateway-shaped control plane is overkill — you are paying for routing you will never use. If the requirement is governed multi-channel routing with identity and access control at the edge, a single-process runtime is the wrong shape, because the boundary lives in the wrong place.

State: Where Memory and Session Data Actually Live

State ownership determines restart behavior, portability, and how you debug. It is the axis where the two systems diverge most visibly.

Hermes persists session and multi-agent-board state to on-disk SQLite files rather than to a network protocol. State is inspectable with ordinary tooling — open the file, read the row — and it survives process restarts by construction. When something goes wrong, you read the database.

OpenClaw binds state to the gateway and its typed protocol. Cross-channel coordination becomes natural because every client speaks the same protocol, but state is less trivially portable. When something goes wrong, you read the log.

Memory is a separate axis from session state, and the distinction matters. Both projects support local embedding models for memory search, but they consume them differently. Hermes consumes embeddings through an endpoint configured in its config file — you run the embedding server, Hermes points at it. OpenClaw can download and serve a model itself, which collapses a moving part but also means the gateway owns a process you did not explicitly start.

Debugging consequence: with file-backed state you can read the row; with protocol-backed state you read the log. Plan observability before you plan features, because the failure you cannot see is the failure you cannot fix.

Execution and Autonomy: One Loop, Many Surfaces

Autonomy is not a dial. It is a placement decision: gate at the boundary, or gate at the action.

OpenClaw concentrates safety at the perimeter. Identity and access control decide what the agent may reach at all. Once a request is inside the boundary, the gateway trusts it. This is coarse-grained and cheap to reason about, and it scales cleanly across many channels because the rule lives in one place.

Hermes renders per-action approvals across many surfaces. The approval prompt follows the user rather than the terminal — the same gate appears in the desktop app, the messaging surface, or the IDE. This is fine-grained and expensive to reason about, because every action is a potential interrupt.

Sub-agent models differ in the same spirit. Hermes spawns isolated sub-agents that report back and disappear. That is fast for parallel work but weak for peer-to-peer collaboration, because the sub-agents never talk to each other. OpenClaw's persistent agent teams support cross-agent coordination, which is slower to spin up and stronger for team behavior.

Two failure paths deserve planning before either system ships:

• An approval that cannot reach the user is an implicit deny. The action silently does not happen, and nothing in the happy path tells you why.
• A perimeter rule that is too broad is an implicit allow. The action silently happens, and nothing in the happy path tells you it should not have.

Both are silent until something goes wrong. That silence is the cost of the placement decision, not a bug in either system.

Operational Assumptions: Hosting, Footprint, and Model Choice

Architecture becomes budget here.

OpenClaw is documented as deployable on a self-hosted Linux VM with network hardening and managed access — NSG rules and Bastion-secured SSH on Azure, for example. That fits teams that need the runtime inside their own infrastructure boundary and can explain the boundary to IT.

Hermes is documented as running across terminal, desktop, messaging, and IDE surfaces with a broad provider list including local endpoints. That fits bring-your-own-model and scriptable-server setups where the operator wants one process to reason about.

Resource profiles differ in reported guidance, but treat published RAM and vCPU minimums as starting points to measure, not guarantees. The model backend usually dominates the footprint, and a 7B local model on a small VPS has a different cost curve than a hosted API behind the same harness.

Model flexibility is not the same as model portability. Per-skill routing and provider-agnostic configuration change how much work a model swap costs. Swapping a provider in a config file is cheap. Swapping a provider when skills assume a specific model's tool-calling behavior is a migration.

Verification step: run the same task on both, restart each process mid-task, and compare what survives. The answer tells you more about state ownership than any architecture diagram.

Choosing Between Them: A Decision Rule

Here is the rule I would use, stated so it can be falsified.

Choose the gateway-shaped system when the problem is orchestration: many channels, governed access, persistent collaborating agents, and a runtime you host inside your own boundary. The center of gravity is dispatch, and you want it there.

Choose the single-process system when the problem is a scriptable, long-running operator: one process, bring-your-own model, file-backed state you can inspect, and parallel sub-agents under one controller. The center of gravity is the session, and you want it there.

Both are MIT-licensed and model-agnostic, so license and provider lock-in are not the tiebreakers. State ownership and trust boundary are. State the criteria explicitly before you pick: how many surfaces, who must approve actions, where state must survive a restart, and who operates the host.

Do not treat either as a drop-in replacement for the other. Migration between them is an architecture change, not a config change, because the state and the trust boundary move.

The Experiment That Resolves the Decision

Pick one recurring task — something you actually run weekly, not a demo. Run it on both runtimes. Kill each process mid-task. Then compare three things: what state survived, what approval was required, and what the logs told you about the failure.

That single experiment resolves more of the OpenClaw vs Hermes Agent decision than any feature table, because it forces the architecture to show itself under the one condition that matters: interruption. The system that recovers cleanly is the system whose state model you can live with. The system whose failure you can read is the system you can operate.