The Hermes Experiment: An Agent That Hires Other Agents

The Pitch I Made to Myself

By June the lab already had a coding agent I could text. The obvious next question — obvious to anyone who has read too many multi-agent papers — was: what if the agent I text isn't the one doing the work? What if it's a dispatcher that understands the request, then delegates the actual engineering to specialist agents?

So LXC 124, hostname hermes, was born: an Ubuntu container running a NousResearch Hermes agent as the orchestrator, equipped like a tiny employee — its own headful browser (real Chrome, not headless, for sites that fight automation), its own Telegram line, shared access to my memory backend over MCP (the same Hindsight instance my other agents use), and runtime secrets injected at launch.

For coding tasks, Hermes delegated to headless Claude Code runs via a wrapper CLI — dispatcher decides what, specialist does how, results flow back up.

What Actually Worked

More than I expected, less than the papers promise:

• The shared memory was the sleeper hit. Hermes recalled infrastructure facts stored by my other agents' sessions — different model, different vendor, same brain. Two agents disagreeing about what your network looks like is chaos; a common memory backend quietly fixes it. That idea outlived the experiment.
• The headful browser earned its RAM. A dispatcher that can genuinely operate web UIs closes tasks that API-only agents bounce off of.
• Delegation itself worked — for well-scoped tasks. "Add feature X to repo Y" flowed down to Claude Code and came back done.

The Four-Hour Hang

What ended the experiment wasn't intelligence. It was plumbing.

The delegation wrapper (a then-young CLI called clarp) hit a compatibility break with a Claude Code update and left an orphaned child process hung on open API sockets for about four hours — silently blocking one of my automation watchers downstream. No crash, no error, no timeout. Just a zombie holding sockets while everything behind it quietly starved.

Debugging that taught me the real lesson of multi-agent systems in 2026: every layer between you and the working agent is a place where failure hides. A human noticing a stuck terminal takes seconds. A dispatcher noticing a stuck subprocess requires engineering nobody has written yet — supervision trees, heartbeats, kill policies. The orchestration layer needs to be more reliable than the agents it manages, and mine was less.

The wrapper got uninstalled the same week. Hermes lingered a while longer, then didn't survive the July census. Container 124 is gone.

The Verdict

Was it a failure? The container's gone, so by lab rules, yes. But three things I now consider settled came out of those two weeks:

1. Shared memory across agents is table stakes, not an exotic feature. Every agent I run now points at the same Hindsight bank.
2. Direct beats delegated at my scale. One human texting one competent agent has no coordination layer to hang. The dispatcher added latency, opacity, and a new failure class — and saved me approximately zero effort, because describing a task to Hermes cost the same as describing it to Claude directly.
3. Orchestration is a systems problem wearing an AI costume. The models were fine. The subprocess management killed it. When multi-agent setups mature, it'll be because someone wrote boring supervision code, not a smarter prompt.

I'll try again when the plumbing grows up. The hostname is reserved.