Hermes Agent vs OpenClaw: Which open-source agent should you run?

The choice between Hermes Agent and OpenClaw is really a choice between an always-on chat assistant and a worker you invoke from a terminal. If you want a helper that waits inside Telegram, Slack, or Discord and answers when people write, start with OpenClaw. It is a gateway-first agent platform, and a resident daemon owns channels, sessions, routing, and named agents, which is what lets one agent stay connected to your chat apps. If you want work you launch from a command line, start with Hermes Agent. It is a Python runtime from Nous Research whose core is the AIAgent conversation loop, with the messaging gateway and execution backends attached as options.

Both projects are MIT-licensed, self-hostable, and describe themselves as model-agnostic, so this is not a choice between tightly locked ecosystems. What differs is practical: which process you supervise, where generated files land, how memory is stored and searched, how scheduling is wired, and what a later migration would actually copy.

How does setup compare between Hermes Agent and OpenClaw?

The setup steps matter less for your decision than the process each project leaves you running afterward. Both projects provide guided onboarding. OpenClaw runs openclaw onboard after an npm or Docker install; Hermes runs hermes setup after its install script. Hermes also offers hermes setup model when all you need is to connect a provider and key. Command names in both projects change frequently, so recheck the current official documentation before running a command saved from an older note.

OpenClaw leaves you with a gateway; Hermes leaves you with a runtime

The setup prompts matter less than what you are left running afterward. Start OpenClaw and you start a gateway daemon that stays alive. It owns the channel integrations, keeps sessions and routing in one place, and attaches each named agent to its own workspace. Start Hermes and you start a conversation through the AIAgent core. The messaging gateway is a separate mode you launch only when you want chat input, and the same agent can be called again from a script or a terminal. That contrast is why descriptions call OpenClaw a control plane and Hermes a runtime. After onboarding, OpenClaw expects you to supervise a resident process; Hermes expects to be invoked when a task arrives.

The workspace is the default directory, not a sandbox

File placement is the setup detail that changes daily use, and it is easy to overstate. OpenClaw gives the agent a workspace under ~/.openclaw/workspace/ by default, so generated files land there rather than in the repository where you typed the command. Current documentation describes that workspace as the agent’s default working directory, not as a hard sandbox. Commands and absolute paths can reach outside it unless you enable sandboxing separately, so treat security as its own configuration step: explicit sandboxing plus approval policies, not a property of the file layout. Hermes runs local execution against the directory you launch it from, so a file it writes appears in the project you are standing in. That is convenient for repo work and worth knowing before you let it near a production tree. For install and first-run steps, use the Hermes Agent setup guide for beginners, which shows where each guided-setup value is stored before you edit config by hand.

How do memory and retrieval compare?

Each agent keeps a deliberately bounded, human-readable memory, and each provides retrieval over its history, so the decision is where the stores live and how you search them, not whether either agent remembers anything at all. Both keep session history separate from the curated facts they inject into prompts, and both let you inspect what is stored.

OpenClaw memory: curated notes and search on demand

OpenClaw memory starts from a compact, curated MEMORY.md file rather than from a raw transcript dump, according to its current documentation. Daily notes are indexed as the agent works and are consolidated over time. Retrieval happens on demand through memory_search and memory_get, which combine keyword and vector search. Nothing in that design requires every past conversation to be fed back into the model on every recall. Conversation history is still kept separately, which is useful when you want to know what happened in a session, but the curated notes and the indexed search surface are the parts the agent consults for steady-state knowledge.

Hermes memory: small curated notes with a searchable session log

Hermes documents a two-layer design with different mechanics. Agent facts and user preferences live in editable MEMORY.md and USER.md files under ~/.hermes/memories/, with character budgets of 2,200 and 1,375 respectively, so the block injected at session start stays small. Full session history lives separately in a SQLite database, ~/.hermes/state.db, with FTS5 full-text search, and the session_search tool pulls matching messages from that database on demand. The agent curates the note files itself through its memory tool, and you can read or edit the same files directly because they are plain Markdown on disk.

What to evaluate when memory tips the decision

Both designs keep the curated notes as files on disk, so auditability is not a reason to pick one over the other. The practical differences are layout and search surface. OpenClaw pairs a concise MEMORY.md with indexed daily notes and keyword plus vector search over that store. Hermes injects MEMORY.md and USER.md at session start and searches a separate SQLite archive with FTS5 when you need an older conversation. Decide which retrieval surface matches the questions you actually ask across weeks of use, then test each agent against those questions. Memory formats and defaults change between releases, so check the current memory documentation for each agent before you rely on a stored fact.

Which agent is better for scheduling and unattended workflows?

Any built-in schedule puts you in charge of keeping a process alive: both agents require their scheduler process to be running on a host you supervise, so neither agent runs scheduled jobs by itself. An execution backend is a different thing from a scheduler: a remote execution target can run the heavy command, but the scheduler that fires the job still lives in a gateway process. Compare restart behavior and failure handling in your own environment instead of assuming one architecture is inherently more reliable.

Hermes built-in cron runs from the gateway daemon

Hermes documentation is explicit that cron execution is handled by the gateway daemon, which ticks the scheduler every 60 seconds and starts a fresh agent session for each due job. The cronjob tool and the hermes cron command create, pause, resume, run, and remove jobs, and each job stores its definition in ~/.hermes/cron/jobs.json. Output goes to a configured delivery target such as a chat channel, local files, or another platform. Jobs can be one-shot or recurring, and a script-only mode runs without an LLM for watchdog-style checks. The scheduler also records each attempt and distinguishes execution failure from delivery failure, so a job whose output never reaches you is flagged rather than reported clean. Model choices can be pinned per job, so an unattended run does not silently inherit a model change you made in your chat session.

OpenClaw scheduling lives in its resident gateway

OpenClaw offers scheduling through the same gateway daemon that owns its channels and sessions. Because the gateway is the component that stays resident, an OpenClaw job fires when that process is up and healthy, which is the normal expectation for an always-on assistant that is already connected to your chat platforms. Plan the host supervision yourself. Know how the gateway is restarted, whether it starts again after a reboot, and how you would notice a scheduled run that never fired. Those are operational questions for whichever agent you choose, not a measured difference between the two projects.

Backends and schedulers are separate concerns

Remote execution options can blur this distinction. Hermes documents local, Docker, SSH, Singularity, Daytona, and Modal as execution backends, which means the agent can send terminal work to a cloud environment that spins up on demand. That does not move the scheduler anywhere. An externally invoked CLI job does not need the gateway daemon, but a built-in cron job does, because the daemon is what ticks the schedule and starts the session. If your workflow is a script on a schedule, check which process owns the schedule in the tool you pick, then test what happens after a host restart, a missed tick, and a credential expiry before you trust the job to run unattended.

How do tools and skills compare between the two agents?

Tool choice should follow the actions your workflow needs. Both agents expose tools to the model, and both support MCP in their current documentation, but the shared skill format does not by itself make a skill executable. Count the integrations, file operations, and command approvals your task actually requires, then verify that the agent you choose has those tools in the version you install.

SKILL.md is a shared format, not a compatibility guarantee

Both projects adopted the AgentSkills SKILL.md format, in which a skill is a Markdown procedure with frontmatter rather than a compiled binary. That shared format lowers the cost of reading a skill and moving it, but it does not establish that the skill will run unchanged on the other agent. A skill can call runtime tools, environment variables, credential files, or shell commands that exist in only one project, and a missing dependency fails at execution time no matter how clean the document looks. After you move a skill, check that every tool and dependency it references exists on the destination runtime before you rely on it.

Match skill choice to the workflow’s concrete actions

The two agents approach skills from different directions, and neither direction is a universal advantage. OpenClaw is skill-driven: you install and curate skills, and registry-based discovery helps you find community-contributed procedures for common jobs such as calendar handling, note synchronization, and issue triage. Hermes ships built-in tools and can generate or refine skills from repeated work in supported configurations. That is valuable when a workflow recurs, but whether the generated skill is correct depends on the task, the model, and your review of what the agent wrote. Verify what the agent creates through inspected outputs instead of expecting self-improvement as a guaranteed outcome. Marketplace size moves, so check it on the day you need a skill rather than reading it as a fixed ranking between the projects.

How does model access differ between Hermes Agent and OpenClaw?

Model access is configured per agent, per provider, and per endpoint, so the practical question is whether the model you want is reachable through the agent’s documented integration path, using the API mode that supports tool calling. Both agents list multiple providers and custom endpoint options in their current documentation, and neither guarantees that a model usable in one agent works unchanged in the other. Compatibility depends on the provider format the agent expects, the model IDs the upstream exposes, and whether the model supports the function-calling behavior the agent needs.

Provider lists change; configuration compatibility does not transfer automatically

Provider catalogs are the fastest-moving part of both projects. Current documentation and feature descriptions for Hermes mention providers such as Nous Portal, OpenRouter, OpenAI, and custom OpenAI-compatible endpoints, while OpenClaw descriptions mention OpenAI, Anthropic, OpenRouter, local models, and configured providers. Verify the list against the project documentation when you build a config, because a provider that was present last quarter may have changed its onboarding or its model IDs. The same caution applies to local models. An Ollama endpoint or another local server may work with either agent, but only if you follow the agent’s documented configuration for that endpoint, including the model name the server actually exposes.

MixRoute as a shared, optional endpoint

MixRoute is an optional upstream for either agent, not a requirement. Each agent works with its own provider keys and provider configuration. To connect MixRoute, follow the documented path: the base URL ends in /v1, you supply a MixRoute API key, and the model ID must be one MixRoute exposes. That configuration still lives inside each agent’s provider block, and the two agents may require different config shapes for the same endpoint. For Hermes, use the custom endpoint recipe for Hermes Agent to place the MixRoute URL and key correctly. For OpenClaw, follow the OpenClaw model provider guide, which maps the same values into OpenClaw’s provider configuration. Neither guide replaces a compatibility check for the specific model and task you plan to run.

How much maintenance and migration does each agent require?

Both agents require ongoing upkeep across the host, its state files, credentials, and the scheduler process, and neither is maintenance-free because both are self-hosted. The real difference is the shape of the state you manage and what a later switch would actually transfer. With either choice, plan for updates, backups, credential rotation, and restart procedures.

State, credentials, and process supervision apply to both

With OpenClaw you supervise a resident gateway, its channel tokens, its workspace, and its memory and note files. You also configure the approval policy that decides which commands run without a human sign-off. With Hermes you maintain the install, the ~/.hermes state including memory files and the SQLite session database, any messaging gateway you enable, and the profile or config that pins providers and models. Both projects store state in files that survive restarts, and both expect you to back those files up if the state matters. A command-approval or write-approval setting can reduce risk in either system, but it is a policy you configure and test, not a default property of one project.

Migration exists in both directions, with different scopes

Switching later is possible in both directions, but the scope differs. Hermes ships hermes claw migrate, which imports an OpenClaw setup and provides a --dry-run preview before the real import. Importing API keys requires the explicit --migrate-secrets flag; neither preset imports secrets by default. Which persona, memory, skill, configuration, and credential fields a given release copies should be confirmed in the current documentation. OpenClaw documentation, in turn, describes importing Hermes MEMORY.md and USER.md. That is a memory-only import and does not carry over full settings, credentials, or skills. During a trial, keep the original state backed up, run the two agents in separate hosts or isolated containers with separate credentials, and check each platform’s token constraints rather than assuming one rule applies to every messaging channel.

Should you choose Hermes Agent or OpenClaw?

Let the channel-first versus terminal-first distinction pick a trial candidate, then confirm the choice by running the same real task through the agent you selected. Both tools support memory and scheduled work, so scheduling and memory capabilities alone will not separate them. Your operating style and the workflows you actually run drive the decision.

Pick OpenClaw for an always-on assistant bound to channels

Choose OpenClaw first when the agent should live inside your chat applications and respond throughout the day, or when you need several named agents bound to separate channels, such as one assistant that watches Slack and another that handles Telegram. Its resident gateway is built for that resident role, and registry-based skills give you a way to extend it with community procedures. Expect to invest in supervision. The gateway process, its channel tokens, and its approval policy are the parts you maintain.

Pick Hermes Agent for terminal-first and file-native work

Choose Hermes Agent first when you want to invoke the agent from a terminal, or want file operations to happen directly in the directory you launch it from. It is also a candidate for repeated automation that records what it did, but only when you keep its gateway daemon running for built-in cron jobs and review the skills it creates. Where OpenClaw binds an agent to channels, Hermes binds a task to a working directory, and each shape fits a different style of work.

Run a small same-task trial before committing

A short comparison in your own environment will tell you more than another feature list. Pick one repetitive task that matters to you, run it through both agents with the same model and the same provider configuration, and compare the outputs, the effort to set up each run, and the operational behavior such as restart handling and delivery of results. Inspect what each agent remembers afterward, test whether a skill you rely on survives a move, and keep your original state backed up so the trial does not put real work at risk. This is a comparison you conduct for your own workload, not a benchmark that any vendor needs to supply. When you have matched an agent to the workload, decide whether a MixRoute credit tier fits the workload you chose.