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:
- 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.
- 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:
- Never modify the primary delivery path first. The thing that works keeps working, untouched.
- Add the new path alongside the old — purely additive. It can fail without taking anything down with it.
- Keep one global kill switch. A single place to stop everything the moment it misbehaves.
- Make delayed delivery visibly delayed, not silently delayed. A wait with no signal is indistinguishable from a failure.
- 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.
Top comments (3)
"The model matters less than whether the system around it gives up." — that's the line that matters most in this entire post.
I run multiple AI agents across different business verticals and the lesson is identical. The model is interchangeable. The harness — the retry logic, the approval gates, the persistence layer, the fallback routing — that's what makes it production-grade or a demo.
Your mirror pattern is smart. I use a similar approach when rolling out changes across my platforms: the old path stays untouched, the new path runs in shadow mode alongside it, and nothing gets cut over until I've watched a full cycle complete without intervention. The moment you modify the primary path before the replacement has proven itself, you've turned a migration into a gamble.
The offset lesson is underrated. I've seen the same thing in agent orchestration — a process that's working exactly as designed looks broken because there's no observability on the intentional delay. Silence and failure are indistinguishable without a signal. That applies everywhere, not just notifications.
Good writeup. The discipline of letting the replacement earn the handoff instead of forcing a cutover is something most teams skip because it's slower. It's also why most migrations break.
I appreciate this perspective. Maintaining "shadow mode until a full cycle completes cleanly" is exactly the right standard. The reason we can afford to be patient is that the primary path remains byte-for-byte untouched. If you modify the very thing you are replacing, you lose your control group.
Your point about observability is what resonated with me most. The offset itself wasn't the bug; the missing heartbeat was. From an external perspective, a 20-second delay and a dead process look identical: they both produce nothing. Logging every mirrored dispatch with a timestamp is what finally allowed me to distinguish between a "quiet" state and a "broken" one.
"Letting the replacement earn the handoff" is well-said. It is a slower process, but the alternative is discovering which assumptions were wrong only after they reach production.
"Logging every mirrored dispatch with a timestamp is what finally allowed me to distinguish between a quiet state and a broken one" — that's the exact lesson I keep relearning in different contexts.
The heartbeat problem shows up everywhere once you start looking for it. I run background generation jobs that write to a database 24/7. Early on, I had a script that went silent for 90 minutes and I assumed it crashed. Turns out it was running fine — the logging was going to stdout instead of the log file, so when I ran it as a background service instead of a terminal process, the ticks disappeared. The job was healthy. My observability wasn't.
Same primitive you're describing: silence and failure are indistinguishable without a signal. I now treat "no output" as a bug in the monitoring, not evidence of a failure in the process. Every long-running job gets a heartbeat line in the log regardless of whether it produced a result on that cycle.
Your point about the control group is sharp too. The moment you modify the primary path, you've lost your ability to prove the replacement is better — you can only prove it's different. That distinction matters more than most teams realize.