Multi-Agent Orchestration Patterns with Hermes

Beyond One Agent’s Sub-Agents

Module 4’s contained sub-agents (Lesson 12) solve delegation within one Hermes process: ephemeral, shared terminal backend, torn down after the sub-task. This lesson is about a different problem: coordinating multiple independent Hermes installations, each with its own persistent memory, skills, and lifecycle, working together on a shared goal.

flowchart TB
    SUP["Supervisor agent\n(Hermes instance A)"]
    RES["Research agent\n(Hermes instance B,\nown memory + skills)"]
    WRITE["Writing agent\n(Hermes instance C,\nown memory + skills)"]

    SUP -->|MCP tool call| RES
    SUP -->|MCP tool call| WRITE
    RES -.->|result| SUP
    WRITE -.->|result| SUP

    style SUP fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style RES fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style WRITE fill:#f0fdf9,stroke:#0D9488,color:#0F172A

The Supervisor Pattern, via MCP

The cleanest way to wire this up reuses infrastructure you already have: Module 3’s MCP integration. Expose each specialized agent as its own MCP server; the supervisor connects to each one the same way it would connect to a GitHub or Stripe MCP server from Lesson 9.

# supervisor's ~/.hermes/config.yaml
mcp_servers:
  research-agent:
    url: "https://research-agent.internal.corp/mcp"
    headers:
      Authorization: "Bearer ${RESEARCH_AGENT_TOKEN}"
    tools:
      include: [research_topic]

  writing-agent:
    url: "https://writing-agent.internal.corp/mcp"
    headers:
      Authorization: "Bearer ${WRITING_AGENT_TOKEN}"
    tools:
      include: [draft_from_brief]

From the supervisor’s point of view, delegating to the research agent is indistinguishable from any other tool call, it’s a <tool_call> (Lesson 7.2), executed, and the result comes back as a <tool_response>. Everything you learned about tool filtering, reachability checks, and hermes doctor diagnostics in Module 3 applies here directly, with no new mental model required.

Each specialized agent keeps its own memory and skills, a research agent accumulates domain knowledge and search strategies over time (Module 4), independent of whatever the writing agent has learned about tone and formatting. That independence is the actual benefit multi-agent coordination buys you, not available from contained sub-agents, which share everything and persist nothing.

When This Is Worth the Complexity

Coordination overhead is real: more MCP servers to configure and guardrail (Module 7 applies to every agent in the system, not just the supervisor), network calls between agents, more surfaces that can fail independently (Lesson 21’s symptom-to-module map gets correspondingly larger).

If none of these apply, a single agent with well-scoped tools (Module 3) and contained sub-agents (Lesson 12) for exploratory work usually beats a multi-agent system on simplicity, without giving up capability.

Common Failure Modes

• Coordination without contracts. If the supervisor’s MCP tool schema for research_topic is vague (violating Lesson 7.1’s advice on tool descriptions), the whole multi-agent system inherits that ambiguity, now across a network boundary where it’s harder to debug.
• Guardrail drift. Each independent agent needs its own Module 7 treatment, curated toolsets, approval gates for risky actions. It’s easy to guardrail the supervisor carefully and forget that the research agent, reachable via MCP, needs the same discipline.
• No shared observability. hermes doctor and session traces (Lesson 21) are scoped to one installation. For a multi-agent system, you need a plan for correlating a failure in the supervisor with what actually happened inside the agent it delegated to.

Exercise: sketch a two-agent system for a real task you’d want to automate (a “monitor” agent and an “action” agent is a common, low-risk starting split). For each agent, list its own toolset and guardrail decisions (Module 7) separately, don’t assume the pair shares one policy. Note where you’d need the MCP include filter (Lesson 9) to keep the supervisor from seeing more of the delegated agent’s capability than it needs.