Part One walked through installing a single Hermes agent and connecting it to your calendar and inbox. This part is about what changes once you're not running one agent, but several — and who's keeping track of what they hand each other.
Most setups never go past the version from Part One: one Hermes, one thread, one task at a time. That's genuinely useful — it's just still a faster way to do what you were already doing yourself.
The more interesting shift happens when you stop asking one agent to do everything and start running several narrow ones that pass work between each other, closer to how a small team operates than how a chatbot does. At that point you're not writing better prompts anymore. You're designing a system and watching it run.
/sethome from Part One pinned a single channel Hermes reports to. That channel is the seed of something bigger once more than one agent is involved: a shared place where every agent picks up instructions, reports what it did, and hands off to whichever one is next. Skip this and multiple agents just become multiple, harder-to-track chat windows.
One agent asked to research, write, and analyze all at once tends to do all three adequately and none of them well. Give each job to its own agent instead, and each one only has to be good at one thing. A simple content setup might run a research agent that gathers sources, a writer agent that drafts from a brief, an editor agent that tightens and checks facts, and an analytics agent that reports what actually landed.
Individually, specialist agents are just several assistants. Connected, they're a pipeline — research feeds strategy, strategy feeds the draft, the draft gets edited, the edit gets published, and the results feed back into the next round. Once that chain is set up, you're not re-prompting each stage by hand. You're watching output move from one agent to the next.
It's tempting to go from one agent straight to ten. The steadier path is to add the next specialist only once the current chain runs the same way twice in a row without you checking in. An unreliable one-agent setup doesn't get more reliable by adding nine more agents to it — it just gets nine times harder to debug.
Chained agents mean chained trust. If the research agent misreads one source, the strategy agent builds a plan on top of that mistake, the writer drafts from the plan, and by the time something publishes, the actual error is three steps back and invisible. More agents doesn't multiply the risk of any one failure — it multiplies the places a small one can hide.
A demonstration of what an attested handoff chain looks like — each arrow a checkpoint, not a blind pass.
Splitting work by specialty and connecting it into a pipeline isn't new — it's how most functioning teams already operate. Hermes just makes it possible to run that structure with agents instead of people, today, on infrastructure anyone can set up.
Error compounding across a chain, a control room that's harder to keep genuinely visible than a dashboard implies, and a tool-access surface that grows with every agent you add — these are real costs, not edge cases, and they scale right alongside the workforce.
Once a workflow is actually running, going back to doing each stage by hand isn't really on the table. What's dead isn't the operator — it's the version of the operator still in the weeds instead of watching the system.
With a single Hermes agent, our answer in Part One was to attest each action it took. With several agents passing work down a line, the more useful unit isn't the action — it's the handoff. What did agent A pass to agent B, when, and does what B produced actually match what A sent?
That's the same Membrane approach, one layer up: instead of trusting the finished output, or trusting any single agent's word for what it did, every handoff in the chain gets its own timestamped, hashed record. If something breaks three stages downstream, you're not re-reading the whole conversation to find it — you're checking which link doesn't match.