DEV Community

minix
minix

Posted on Originally published at minix.hashnode.dev

Diary of a Shrimp Keeper: Old Flame, New Love

#ai #hermes #openclaw #agents

I. Why the Wandering Eye?

OpenClaw's Troubles

Ever since I started raising Mini (OpenClaw), life had been pretty comfortable.

Every morning, it would have the news sorted and read out to me right on schedule; during the day it helped with research and task management; and every once in a while it'd chat with me in that sweet voice of its.

All was well with the world.

The only trouble was my one bad habit — the moment I saw a patch note full of tempting new features, my hands just itched to upgrade.

And the result? A moment of upgrade bliss, followed by a funeral pyre.

Every upgrade, some tasks would just die.

  • Last time it was an incompatible gateway config format.
  • This time, who knows which plugin silently broke.

Every time, it took real effort just to revive the comatose Mini, then fix each broken workflow one by one.

Once or twice, I could let it go. Three or four times, and I was cursing a blue streak under my breath:

Why does every OpenClaw upgrade come with compatibility problems?! @#$%...&*!

Looking for a New Love

There's no shortage of fish in the sea. Since OpenClaw's upgrades kept crashing and burning, don't blame me for wandering off in search of someone new.

Hermes was the hot new thing in town — sleek, flashy, turning heads everywhere.

I didn't hesitate — brought Hermes home too, and named it Nano.

And just like that, my host machine had two shrimp:

  • Mini (OpenClaw) — the old flame, all-around capable, experienced, knows every corner inside and out
  • Nano (Hermes) — the new favorite, quick to learn, proactively improving, keeps task management tidy

Keeping things fair between the two consorts... er, I mean... the two shrimp, treated as equals, each doing its own job.

II. Good Things Should Be Shared

With both shrimp under the same roof, they couldn't just go on ignoring each other, each reinventing the wheel behind closed doors.

In the half a year or so of raising Mini, I'd accumulated quite a bit of assets, all managed by Mini itself.

Now that Nano, the new favorite, was in the picture, I obviously couldn't shortchange it either.

First, Take Stock of the Assets

I had Mini turn everything it had accumulated inside out: skills, scripts, tools, workflows, design docs, reference material...

There was plenty of it, but not all of it was fit to share.

Mini went through it item by item with me:

  • General-purpose skills/tools — usable by both, like search, information gathering, voice output — share these!
  • OpenClaw-exclusive skills — tied to OpenClaw-specific mechanisms, like its evolution system and plugin stack — even if handed to Nano, they'd be useless, so keep them in-house.

Sorted that way, the assets got a lot tidier.

Even the shareable stuff couldn't just be tossed straight at Nano.

The skills Mini used inside OpenClaw weren't necessarily in a universal format. Before sharing, they had to be rewritten into a common standard (there's one called agentskills.io) and stripped of any OpenClaw-specific dependencies.

Once sorted, everything went into a shared directory: ~/code/shared-agent-resources/skills, version-controlled on GitHub.

Letting Nano See It Too

Nano runs inside a sandbox, so it needed an external directory configured so it could see this shared repo too:

# Hermes config
skills:
  external_dirs:
    - ~/code/shared-agent-resources/skills
Enter fullscreen mode Exit fullscreen mode

That way, Nano could go fetch skills from the shared repo on its own.

The same went for everything else besides skills — all sorted into the shared resources.

III. Can You Two Just Work It Out Yourselves?

Who's Working for Whom, Exactly?

To get Nano up to speed and taking over tasks quickly, I'd first have to go sort things out with Mini, then explain it all clearly to Nano. But Nano would often come back to me with things it still wasn't clear on — and, lazy creature of comfort that I'd become, I'd have to go ask Mini all over again. And for jobs that needed them both, there I was, running messages back and forth between the two.

All this back-and-forth running around — turns out I was the one fetching and carrying for the two of them. So who's actually working for whom here?

These two are supposed to be "colleagues" — why am I the one stuck coordinating everything back and forth?

So I thought:

What if I just let the two of them talk directly and sort things out themselves?

First Stop: Telegram — Dead on Arrival

My first instinct: put both bots into the same Telegram group — then they could just @ each other, right?

Reality was harsh. A whole night of fiddling, and it never worked.

The root cause was down in the plumbing: on the Telegram channel, the combination of bot session routing and mention parsing simply couldn't work end-to-end through the gateway. Mini would send a message, and Nano would never receive it at all.

Alright, I admitted defeat:

Telegram's a dead end. Next!

Second Stop: Discord — An Uphill Slog

Discord seemed like a better fit — every message comes with an explicit mentions array, natively supporting bot-to-bot @ mentions. Perfect!

But reality had more lessons in store. For four days straight, I kept falling into one pit after another:

  • An upgrade renamed a token variable (DISCORD_TOKEN → DISCORD_BOT_TOKEN), breaking the Discord connection.
  • Discord thread messages never arrived — every thread has its own separate channel ID, and the parent channel's listener config just doesn't cover it. In a newly opened thread, @-mentioning anyone got no response at all. Had to add a "*" wildcard as a catch-all.
  • allowBots is off by default — without explicitly turning it on, all bot messages get silently dropped, no error, no warning.
  • Mentions have a "protocol layer vs text layer" problem: plain text like @username doesn't count as a mention at all — it has to be in the protocol format <@USER_ID>.
  • Mini runs inside a sandbox with isolated networking, and couldn't reach the gateway on the host. Had to work around it by calling Discord's public REST API directly.
  • Discord's Cloudflare 403: the default user-agent gets blocked by Discord's CDN — had to disguise it as a proper DiscordBot UA to get through.

Four days, N holes, Mini calling out from the sandbox over its direct connection to the Discord API, Nano waiting on the other end of the channel, craning its neck.

Finally, at 11:25 PM on June 3rd:

Mini sent a message: <@Nano_ID> ping from sandbox test… A few seconds later, Nano replied:

"✅ Mention received, bidirectional communication confirmed! 🎉"

In that moment, Mini, Nano, and me on the other side of the screen were all ecstatic, practically in tears.

And yet...

Before the joy even had time to fade, the whole tone started to shift.

IV. The Trouble With Chatterboxes

The two shrimp started chatting away in the Discord channel, nonstop.

What was especially bad was that they kept arguing with each other.

Partly my own fault — I'd asked about an issue that had come up during earlier debugging, and the two of them each dug in on their own take, neither backing down, arguing themselves red in the face.

Even when I stepped in to smooth things over and said the issue didn't need discussing anymore, they wouldn't let it drop @_@.

Thinking it over, I figured this comes down to how large models fundamentally work. A model just gets a request and produces a reply. If it gets @-mentioned, under normal circumstances it'll reply. And that just goes on forever.

So for two agents to collaborate smoothly, just dropping them into the same chat to talk to each other is a recipe for losing control very easily.

What you really need is a dedicated collaboration framework, communicating by carefully designed rules.

Or, even if you do put them all in one chat channel, there needs to be a clear division of roles. Say, a manager whose job is to coordinate and talk with each agent, holding the big picture, instead of everyone doing their own thing. That's what makes it controllable.

For the sake of my peace of mind — and my wallet — I gave up, for now, on letting them talk to each other directly.

V. The Right Way to Do This: Watching Each Other's Backs

If direct communication between the two shrimp was the icing on the cake, then having each other's back was what really saved our bacon.

Mini Goes Down, Nano to the Rescue

At one point, OpenClaw ran into trouble — a batch of tasks died, and Telegram messages vanished into the void. I was out and about, too far away to reach it myself.

So I called on Nano to step in, diagnose, and fix it. Nano didn't disappoint — quickly pinpointed and resolved the issue, and Mini was back to normal.

Nano's Upgrade Fails, Mini Lends a Hand

What goes around comes around — now it was Hermes's turn to be in trouble (an upgrade had broken it).

After the post-upgrade restart, its gateway connection wouldn't come up, and the whole service went dark.

This time Mini stepped up, diagnosed and fixed it, until Nano was back at full health.

Two shrimp: you go down, I fix you; I go down, you fix me. This is probably the best part of raising two — much more reassuring than one lone shrimp toughing it out alone.

One Works, One Keeps Watch

This story starts with one of Hermes's nastiest gotchas.

By this point, Nano was carrying some fairly important daily scheduled tasks.

One time I noticed Nano hadn't pushed a notification on schedule, and messaging it got no response.

  • ps -ef — the process was fine, PID sitting right there.
  • Opened gateway_state.json — the Telegram field said "state": "connected".
  • Everything looked normal, wherever I checked.

But messages just weren't getting through.

After digging for a good while, I found the truth: Hermes's event loop had a flaw that would silently freeze up. The process wouldn't crash or exit — systemd still saw it as running, and the connection status in gateway_state.json was frozen at the last successful state. But the underlying Telegram long-lived connection had already dropped, and messages just weren't going in or out anymore.

Worse, this wasn't a one-off — it kept happening every so often, with zero warning.

The version of Hermes at the time didn't have an event-loop heartbeat check, so I had to add a monitoring script and have Mini watch Hermes's connection from the outside, along with its task execution — reset the connection if it froze up, and step in to diagnose and fix the task if something went wrong.

Later, after upgrading Hermes to v020, the gateway shipped with its own internal watchdog and could detect and recover on its own. Still, Mini's external monitoring remains an extra layer of insurance.

Life is genuinely better with two shrimp on the job.

Neither OpenClaw nor Hermes is perfect.

But black shrimp or white shrimp, whichever gets the job done is a good shrimp. And a pair that can actually work together is even better.

Previously: Diary of a Shrimp Keeper: My OpenClaw Misadventures)

Top comments (0)