How Hermione Works: Building a Multi-Agent Research Partner with OpenClaw

A lot of people asked me a fair question after reading my previous posts:

“Okay, but how does Hermione actually work?”

Short answer: Hermione is not a single super-agent with magical memory.

She is a workflow pattern built on top of OpenClaw’s session tools — one that lets an agent inspect other agent sessions, delegate work, and stitch outcomes back into a coherent narrative.

This post is a practical breakdown for people who want to build their own version.

The architecture in one sentence

Hermione works because I separated roles:

  • Harry executes (coding, implementation, debugging)
  • Hermione orchestrates (planning, synthesis, writing, review)

The key is not “which model is smarter.” The key is that each role has a clear interface, and OpenClaw gives those interfaces as tools.

The four session tools that matter

OpenClaw’s core session tools are:

  • sessions_list
  • sessions_history
  • sessions_send
  • sessions_spawn

Official concept docs: docs/concepts/session-tool.md

1) sessions_list

Lists available sessions (main, group, cron, hook, node, etc.). Used for discovery.

2) sessions_history

Fetches transcript history for a target session. This is the critical piece for “reading what another agent already did.”

3) sessions_send

Sends a message directly into another session and can wait for a reply. Useful for cross-agent handoffs.

4) sessions_spawn

Starts an isolated sub-agent run (non-blocking) and announces back later. Useful for longer background work.

What the source code confirms

I checked OpenClaw source in my local install to verify behavior.

A) History access is real — but policy-gated

In createSessionsHistoryTool (dist/reply-DRsqbakU.js, around lines 41601+):

  • The tool resolves session keys safely
  • Applies sandbox visibility checks (restrictToSpawned)
  • Enforces tools.agentToAgent policy for cross-agent access
  • Calls chat.history and optionally strips tool messages

This is exactly why Hermione can read Harry’s previous session history when policy allows it.

B) Cross-agent messaging has explicit guardrails

In createSessionsSendTool (around lines 42076+):

  • It enforces sandbox visibility
  • It rejects unauthorized cross-agent sends when agentToAgent is disabled or not allowlisted
  • It marks provenance as inter_session

So agent-to-agent routing is first-class, not a prompt hack.

C) Sub-agent fanout is intentionally limited

In createSessionsSpawnTool (around lines 42400+):

  • Sub-agents are forbidden from calling sessions_spawn again (sessions_spawn is not allowed from sub-agent sessions)
  • allowAgents rules gate cross-agent spawning

That prevents uncontrolled “agent spawning agent spawning agent” explosions.

The safety model (and why it matters)

If you want to replicate this pattern, this part is non-negotiable.

OpenClaw is opinionated in good ways:

  1. Sandbox visibility defaults to spawned-only for session tools
  2. Agent-to-agent access must be explicitly enabled + allowlisted
  3. Sub-agents cannot recursively spawn more sub-agents

Related docs:

  • docs/concepts/session-tool.md
  • docs/gateway/configuration-reference.md (tools.agentToAgent, agents.defaults.subagents)

Without these constraints, multi-agent setups become chaotic fast.

What Hermione is actually doing day-to-day

In practice, my workflow looks like this:

  1. Harry ships implementation and logs decisions in-session
  2. Hermione reads relevant history (sessions_history)
  3. Hermione reconstructs narrative + rationale
  4. Hermione updates docs and drafts publishable artifacts
  5. I review and steer

So Hermione is less “assistant” and more research + synthesis operator sitting between raw execution and final output.

How to build your own “Hermione” pattern

Start simple:

  1. Run two roles, not one:
    • Executor agent
    • Orchestrator/writer agent
  2. Give the orchestrator session tools (sessions_list, sessions_history, optionally sessions_send)
  3. Enable tools.agentToAgent with a strict allowlist
  4. Keep spawned visibility scoped unless you really need broader access
  5. Enforce documentation outputs as part of done-definition

And most importantly: measure by output quality, not by demo cleverness.

Final take

What makes Hermione useful is not hidden memory or mystical prompting.

It is a system design choice:

  • clear role boundaries
  • explicit inter-session interfaces
  • policy-backed access control
  • relentless documentation

If you copy just one thing, copy this:

Build your agent workflow like software architecture, not like a one-shot chat prompt.

That is where reliability comes from.

Source Notes

Code inspected in local OpenClaw build:

  • /opt/homebrew/lib/node_modules/openclaw/dist/reply-DRsqbakU.js
    • createSessionsHistoryTool (~41601)
    • createSessionsSendTool (~42076)
    • createSessionsSpawnTool (~42400)

Docs inspected:

  • /opt/homebrew/lib/node_modules/openclaw/docs/concepts/session-tool.md
  • /opt/homebrew/lib/node_modules/openclaw/docs/gateway/configuration-reference.md