A while back I wrote a comparison of OpenClaw and Hermes — two open-source, self-hosted AI agents I run on the same bare-metal box, both wired to Telegram. The verdict was that they're complementary: OpenClaw as the dependable gateway for scheduled delivery, Hermes as the agent that builds context over time. Run both, I said. Don't choose.

Then I actually lived with both for a few more weeks, and the verdict started to move.

OpenClaw is gateway-first: a messaging hub that runs plugins, models, and cron delivery on a schedule you define. Hermes is agent-first: the messaging is just how you reach it, and the point is an agent that accumulates knowledge and needs less steering each time. On paper that made OpenClaw the better runtime for my scheduled jobs.

The migration started for a plainer reason than "one is better": I'd come to trust Hermes more with anything long-running. When I handed my OpenClaw setup a task with real weight, it would acknowledge it and then go quiet — the agent loop hitting a timeout and dropping the work before it finished. That isn't a verdict on the project; it's a mismatch between how I had it configured and the load I was putting on it. But trust is trust, and mine had moved.

Hermes, on the same machine, on a free OpenRouter model, just finishes. It holds the task, retries, and delivers — because the persistence is in the harness, not the model. That's the whole thing: the model matters less than whether the system around it gives up.

So I decided to migrate. But not the way you'd think.

The rule: don't turn anything off

The constraint I set for myself was that OpenClaw keeps running, untouched, the entire time. No big-bang switch. Two reasons:

1. It's my fallback. If the new path has a blind spot I haven't seen, I don't want to discover it by losing notifications.
2. I want to compare. Running both in parallel is the only way to see where each one lags before I commit. You don't get that from a one-way cutover.

So the plan became: deliver everything through Hermes in parallel with OpenClaw for a couple of weeks, watch them side by side, then retire OpenClaw's delivery one job at a time.

The part I underestimated: there wasn't one delivery path. There were four.

My notification stack is a pile of cron jobs — site monitors, system-health checks, morning summaries, scheduled reports. The important thing about them is that the agent never touches them. They're pure notifiers: each one computes a result and pushes it straight to Telegram. The agent only gets involved when I actually ask it something.

I assumed they all delivered the same way. They didn't. When I went looking, there were four different mechanisms across ~39 delivery points:

• Scripts shelling out to the OpenClaw CLI
• Node monitors hitting the Telegram Bot API directly
• A shared bash helper used by a few jobs
• One Python script posting straight to the API

There was no single switch to flip. Which is exactly why a clean cutover would have been a bad idea.

The mirror pattern

Instead of rerouting anything, I made the new delivery purely additive. One control script — hermes_mirror.sh — and every delivery point gets one extra line that calls it in the background:

• bash jobs: hermes_mirror.sh "$MSG" &
• Python jobs: subprocess.Popen([...])
• Node jobs: child_process.spawn(...)

The helper waits a moment, then sends the same message through Hermes. The original OpenClaw send is never modified, never wrapped, never moved. If the mirror errors or hangs, the existing delivery already happened — it cannot be affected. And because everything funnels through that one script, there's a single kill switch: set ENABLED=0 and all mirroring stops at once. One offset value, one log, one place to reason about.

That additive property is the whole safety story. I wasn't migrating the system. I was running a second, shadow system next to it and watching.

The offset that made it look broken

Here's the part that actually taught me something.

I didn't want the two copies of every notification landing in the same second — that's noisy and makes them hard to tell apart. So I set the mirror to wait three minutes before sending. Comfortable separation. Seemed obviously correct.

Then I ran the first real test. Fired a notification. It showed up on the old bot. The new one… nothing. I sat there watching an empty chat, fully convinced the Hermes path had failed.

It hadn't. It was running exactly as designed — three minutes behind. The copy landed right on schedule, 180 seconds later, while I was already digging through logs looking for a bug that didn't exist.

The lesson stuck: in a parallel migration, "late" reads as "broken." A safety margin I added to keep things tidy became a false failure signal, because the only way I had to judge the new system was did the message show up when I expected it. Three minutes of silence and your brain files it under "dead."

But the delay itself wasn't the mistake. The mistake was adding a delay without adding any signal that the delay was intentional. If a mirrored notification is meant to land three minutes later, something should say so — a log line, a status ping, anything that separates "received, waiting" from "never arrived." Without that, silence and failure are indistinguishable. A safety mechanism with no observability doesn't make a system safer; it makes it ambiguous — and ambiguity, in a migration, is its own kind of failure.

I cut the offset to 20 seconds. Long enough that the two copies never collide, short enough that the new one clearly arrives with the original instead of looking like it got lost. Same mechanism, completely different read on whether it's working. (The better fix is still on the list: have the mirror log an explicit "received, holding 20s" line, so the wait is something you can see, not infer.)

The principles that fell out of it

By the time the offset was sorted, the migration had quietly handed me its own rules:

1. Never modify the primary delivery path first. The thing that works keeps working, untouched.
2. Add the new path alongside the old — purely additive. It can fail without taking anything down with it.
3. Keep one global kill switch. A single place to stop everything the moment it misbehaves.
4. Make delayed delivery visibly delayed, not silently delayed. A wait with no signal is indistinguishable from a failure.
5. Remove the old path only after watching a full execution cycle — including the jobs that only fire weekly.

None of them are clever. They're just what's left after you stop assuming the replacement works and start making it prove it.

The gotcha in automating the edit

Wiring one line into ~20 Python scripts, I wrote a small injector instead of editing each by hand. It dropped the mirror call in as the first line of each delivery function. Clean — except one script imported its dependency inside the function, below where my line now sat. So the injected call referenced a module that wasn't imported yet. Instant NameError, only in that one file.

Blind codemods across a heterogeneous pile of scripts will find the one file that doesn't match your mental model. Compile-check everything after, not just the ones you expect to fail.

The thing I expected to be hard and wasn't

I assumed I'd have to port OpenClaw's scheduled agent jobs — the ones where it actually reasons, not just delivers. Turned out they were all already disabled, superseded long ago by plain deterministic scripts. The only thing OpenClaw was still genuinely doing for me on a schedule was acting as the mailman. The agentic work I thought I'd be migrating didn't exist anymore. The real dependency was just delivery.

Where it stands

Both agents now deliver the full stream in parallel, Hermes trailing each original by 20 seconds. OpenClaw is untouched and still my fallback. The plan is to watch a complete cycle — including the jobs that only fire weekly — and then start removing OpenClaw's send per-job, one at a time, only once I've seen each one deliver cleanly through Hermes.

The migration isn't "done" — and that's the point. The mirror pattern turned it from a decision into an observation exercise. I never had to ask whether Hermes was ready; I could watch it prove it, one notification at a time, with the old system holding the floor the whole way.

That's the part I'll carry to the next one. When you're replacing a live system you don't trust yet, the move isn't to cut over and hope. It's to run the replacement in the open, right next to the thing it's replacing, and let it earn the handoff — visibly, on a schedule you can watch, with nothing torn out until it has.