I migrated from OpenClaw to Hermes, and it wasn’t as simple as I thought

I run a persistent AI agent — a “clawbot” — that I use as a coding and research assistant and a handy way to keep up with AI developments. After about 6 months on OpenClaw, I migrated it to Hermes. What I expected to be a lift and shift turned into a two-day exercise in memory archaeology, a bunch of crons I’d forgotten about, and an essential semantic data script that had been broken since the day it was written. This is the breakdown of what I did, what broke, and what I’d do differently.

What are OpenClaw and Hermes?

Both OpenClaw and Hermes are known as clawbots (named after the former, which was one of the first of its kind and stillthe most popular today): persistent, autonomous and proactive AI agents, as opposed to the more familiar prompt-and-response assistants.

The distinction matters. A prompt-and-response agent — think a standard LLM chat interface — waits for you to ask, generates an answer, and forgets everything the moment the conversation ends. There’s no memory across sessions unless you build it, no scheduled execution, no ability to act on your behalf unprompted.

A clawbot changes that model. The defining properties are:

  • Persistence. It runs as a background gateway process, not a chat you open and close.
  • Memory. It keeps a durable, structured memory across sessions — a persona file, curated long-term memory, and sometimes a semantic/vector layer.
  • Autonomy. It runs scheduled jobs (cron), monitors systems, and initiates actions without being prompted.
  • (Often) Expanded Tools It typically has much more access to common system tools, allowing it similar control of its environment to that of a human operator.

Some examples of the broader ecosystem: OpenClaw is the most popular(openclaw.ai) Hermes Agent, by Nous Research, adds a self-improvement system that claims to get smarter over time (ask me in 3 months how well this works). Nanoclaw focuses on security through a simpler approach Nemoclaw is backed by Nvidia and focuses on enterprise uses

The clearest illustration of the proactive/reactive gap is Corvus Latimer — an agent that was granted full autonomy and runs continuously, publishing its own field notes and taking initiative without a human prompting each action. That’s the entire point: a reactive agent would never act unless asked, so it could never run something like that. A clawbot is the class of tool that makes proactive behaviour possible at all — the difference is persistence plus autonomy, not just a fancier model.

The OpenClaw setup

I built my agent to be three things:

  1. A coding and research assistant. I delegate a lot of coding work to it, and it maintains a searchable store of technical research — competitor analysis, library evaluations, architecture notes.
  2. A scheduler for background work. It runs a set of cron jobs: a daily news briefing, a Polymarket trends report, a dream-diary image generator (used as an unconventional way of debugging the memory layers), various ongoing bits of market research, TickTick overdue-task triage, and price watches.
  3. A learning experiment in recent AI developments. Because it’s an autonomous agent, it doubles as my test bed for what the current generation of agentic tooling can actually do — its capabilities are the field moving forward.

Architecturally it had the standard pieces: a persona file, a curated long-term memory, a chronological daily-notes store, a set of skills, and a semantic memory layer. Over three months of use it accumulated real history — 84 daily note files, dozens of research documents, and the operating texture of my working life. I’d also been running a semantic layer on top that was supposed to make that record more easily searchable.

Why move?

The trigger wasn’t a single outage. It was a pattern of stability issues that made me stop trusting the underlying engine.

The honest list:

  • Something broke with every release. Every. Single. Time. The OpenClaw project has been a victim of its own success - it went from a handful of PRs each week to hundreds every day, many of them low quality. AI makes it very easy to write code, and I dont doubt that their authors are well intentioned, but without the QA process to counterbalance it they’ve introduced more bugs than they’ve fixed.
  • Memory was unreliable. The bot seemed to suffer from amnesia sometimes. I’d have a great conversation with it about hardware tradeoffs, only for it to have no recollection when I asked the next week in order to purchase some of it. This turned out to not be an Openclaw problem, but it came up in the migration nonetheless.
  • I wanted to experiment. Honestly I just wanted to tey something different. The Claw ecosystem has really taken off and there’s so many variants out there now. One of the reasons I started the bot was to learn, and this is the natural extension.

We explored alternatives before settling. As Clawbot frameworks themselves, we looked at Soulclaw and Letta; the search also surfaced Honcho, a memory/personality layer from Plastic Labs rather than a full agent runtime. Each was a serious candidate on paper, but none fit the full picture. The reasons Hermes won:

  • Active development and a clean model/tooling offering. This was the biggest factor - I wanted something that was going to continue to evolve, but was also stable. As the second most popular Claw, Hermes fit the bill.
  • Native memory providers — including support for external memory layers and a proper memory tool, rather than a bolt-on. Shoutout to Memclaw here, which specialises in this and was a close contender.
  • Self-improvement was an interesting feature. Hermes claims to get smarter over time by remembering how it solved problems, and creating skills to use the next time around. Results are promising so far, but I’m still not sure how it’ll work in the long term

So the decision was made. The plan was simple. The reality was not.

The plan

On paper this was a simple data migration. Six things to lift and shift over, one-to-one:

  1. Persona (SOUL.md)
  2. Long-term memory (MEMORY.md, USER.md, semantic memory)
  3. Daily notes and research docs (84 files)
  4. Skills (24)
  5. Cron jobs
  6. Secrets and configuration

I figured I’d make a backup, have OpenClaw get everything ready, switch over, and have Hermes verify the move. I budgeted half a day.

How it went

It did not go to plan.

Stage 1: The memory didn’t fit

The first blocker was a hard constraint in Hermes memory.md: a 2,200-character cap on curated long-term memory. My agent’s memory file was 26,762 characters — twelve times over, and in a format the new platform didn’t recognise. The intention here is to use the context window efficiently by focusing only on the memories that matter, which makes sense but is hard to do in practice and is an active area of research.

This forced a real curation exercise: distil 26KB of accumulated notes, config detail and half-remembered decisions down to the 2.2KB that actually matter. The full version went to a (searchable) archive and a curated version took its place. I went from a huge sprawl to a focused collection, with an archive search when needed.

Stage 2: The format guard bit

The target platform has a drift-guard on its memory tool: it writes against a snapshot taken at session start, not live disk. A mid-migration memory write collapsed my freshly-curated 2,199-character file to a single 165-character entry. It was recoverable (the file was restored from disk), but it made me read the platform’s memory semantics carefully instead of assuming they matched the old one.

Stage 3: Dead paths everywhere

The old agent had been built one script at a time, each hardcoding absolute paths like ~/.openclaw/workspace/scripts/calendar_check.py. The migration renames that directory. Every script referencing it broke — not with a crash, but silently: a cron stopped firing, a search returned nothing, a helper no-oped. The tell-tale was a search that was “working” but taking over a minute for 84 files, recomputing embeddings on every query. Easy enough to fix but a bit of an oversight in the migration plan.

Stage 4: The semantic layer had never been used

This came as a shocker: the semantic memory store, which I’d counted on to give my agent long term memory, had been essentially empty the whole time — 8 facts after three months. The real remembering had been happening in the plain markdown daily notes all along. The script populating it had never been running as expected, so no memories ever got written or read.

Initially I thought this was a migration issue, maybe the semantic store hadnt copied over properly, but the fact that it had some memories was the giveaway. A more thorough investigation from Openclaw confirmed that outside of the initial setup, there weren’t any hooks set up to make use of it.

Stage 5: The memory pipeline rebuild

The fix wasn’t trivial, it was a redesign:

  • Daily notes became the explicit source of truth. Plain markdown, chronological, human-readable. This forms the backbone of the agentic memory system.
  • The semantic store became a search index for the notes Every fact carries a provenance link back to the note it came from. It cannot drift from the source of truth because it is derived from it.
  • Facts are extracted by an LLM, not regex. The old system used regex patterns on raw conversation, which produced “facts” like “what is the capital of France?” The new pipeline distils from the curated notes and cross-checks against an authoritative memory file.

The result: 8 facts → 456 facts, all source-linked. Search went from over a minute to 0.1 seconds by caching embeddings keyed to file content.

Stage 6: The “research is not a decision” bug

The LLM-based extraction had its own sharp learning curve. On the first full run it stored, with confidence, that my startup “will use PaddleNLP for theme extraction” — because a research note had evaluated PaddleNLP as a candidate. The actual decision, sitting in the authoritative memory, was that I’d built the extraction with NMF. The extractor couldn’t tell “we looked at this” from “we chose this.” The fix was to feed it the authoritative context as ground truth and instruct it explicitly: research and exploration are not decisions.

Stage 7: The supporting cast

The rest was the less glamorous work:

  • Secrets. A manifest now documents every key, what uses it, and where it lives — no more “where does this come from?” detective work.
  • Backups. The existing backup script had been committing locally but never pushing — the GitHub fine-grained PAT had read-only access to the repo it was supposed to push to. Months of “running” backups that weren’t backing up. Fixed by switching the remote to SSH.
  • Agent architecture. The old platform’s three-agent setup (main/background/heavy) didn’t map cleanly onto the new delegation model. The answer was to let scheduled jobs run in native isolation and use a heavier model on demand per task, rather than force the old topology.

How it’ll be easier next time

Everything that cost time this migration is now mitigated, and most of it is in version control:

  • A single runbook (SYSTEM.md) documents the architecture — directory map, state stores, the memory pipeline, the secrets inventory, the cron schedule, and a copy-paste migration checklist. The next move doesn’t start from zero.
  • Git version control on the whole config with a weekly automated backup to a private repo, verified to push (via SSH). A future migration becomes a git diff, not a forensic investigation.
  • A portable export path. A script exports the entire memory system — daily notes plus facts as JSONL with provenance — into a platform-agnostic bundle, on a monthly schedule. The memory is no longer hostage to a proprietary schema.
  • A health-check script that verifies no dead paths, all cron dependencies resolve, and all required secrets are present — run it after any platform change for an instant gap report.
  • A design rule that prevents recurrence: single source of truth, derived layers with provenance, no hardcoded absolute paths, one secrets manifest, and backups that are verified to land rather than assumed.

Summary

Migrating a persistent agent between frameworks is a migration of memory and behaviour, not just files. The two things that cost me most were not technical incompatibilities — they were an uncurated memory and a semantic layer that looked important but carried nothing. Both are now fixed at the design level, and the fixes are documented, versioned, and backed up.

If you run a clawbot or are thinking about building one, my advice is shorter than the post: curate your memory from day one, make the source of truth boring and portable, and verify your backups push. The fancy layer is not what saves you.