MindRoom, AI‑DLC, Hermes & OpenClaw

MindRoom is a Matrix-native multi-agent runtime: agents live as ordinary Matrix accounts in rooms and reply through the same protocol any bridge speaks, which is how one instance ends up reachable from Telegram, a web client, or a phone without agent-specific plumbing on the other end. The core lives in src/mindroom/: an orchestrator that boots agents and teams from config.yaml, a turn pipeline that takes one inbound Matrix message from ingress to a delivered reply, and a tool system with a hundred-plus integrations.

Everything below is a subsystem or a satellite team built on top of that core, none of them replace it, and (this is the point of this page) most of them don't yet talk to each other either.

This is the piece that actually names Hermes and OpenClaw in the code, so it's the right place to start. Internally it's tracked as P9: a narrow, well-specified enrollment-and-job-queue system for external worker processes.

“Authenticated network boundary for OpenClaw and Hermes edge workers.”

src/mindroom/api/edge_fleet.py, module docstring

Mechanically it's a coordinator/worker handshake:

1. The coordinator issues a short-lived HMAC-signed enrollment token to a specific node_id and Ed25519 public key.
2. A worker node redeems it at POST /api/edge-fleet/enroll, then heartbeats its capabilities.
3. The coordinator queues jobs; the node leases one at POST /lease, executes it, and returns an Ed25519-signed result at POST /complete.

The router is mounted in the live API (src/mindroom/api/main.py), and on 2026-09-04 the gate came off: security approval was given, and production now runs with MINDROOM_EDGE_FLEET_ENABLED=true and the fail-closed node allowlist pinned to the two real workers.

Two real worker daemons run as launchd services (chat.mindroom.edge-openclaw, chat.mindroom.edge-hermes; source in ops/edge-workers/). Each holds an Ed25519 identity under ~/.mindroom/edge-identities/, mints a single-use HMAC enrollment token from the coordinator's admin API, enrolls, heartbeats, and leases jobs in a poll loop. Job execution goes through SubprocessJobExecutor into per-runtime executor scripts that drive the actual local openclaw and hermes CLIs, so a leased job is a real agent turn, not an echo. Workers re-enroll automatically after a coordinator restart.

Live end-to-end evidence, 2026-09-04: job e2e-openclaw-001 (17×23) returned 391 through the real OpenClaw gateway; jobs e2e-hermes-001 (31×7) and e2e-hermes-002 returned 217 and “MindRoom.” through the real Hermes agent. edge_fleet_cross_device_demo.py remains as the synthetic correctness demo the live system superseded.

Hermes now exists as a real edge worker on this machine: the chat.mindroom.edge-hermes daemon enrolls in the edge fleet with a real Ed25519 identity and executes leased jobs through the local Hermes CLI. Below is the history of how the name got there before the worker did; the two meanings still both exist:

1. As a competitor, in the README

“OpenClaw and Hermes Agent are self-hosted assistants that pipe an agent into chat apps you already use. MindRoom plays in the same space but makes different architectural bets…”

README.md, positioning copy, referring to Nous Research's Hermes Agent

That's marketing language comparing MindRoom to an external project, not an integration.

2. As a placeholder identity, in scaffolded subsystems

Beyond edge fleet's WorkerRuntime literal, "Hermes" is used as a stand-in target across a few speculative features:

• src/mindroom/provenance_overflow.py assumes a hypothetical "Hermes-native memory" with a 50,000-character ceiling, and builds an overflow store for records that exceed it, no such memory backend exists to overflow from.
• src/mindroom/learning_loop.py, when it promotes a learned skill to "stable," writes into both an openclaw_root and a hermes_root filesystem path.
• src/mindroom/skill_registry.py has a translate_hermes_skill() function that maps an assumed "Hermes skill descriptor" shape into MindRoom's own skill manifest format, there's no published Hermes skill spec in the repo to translate against.

None of that speculative plumbing sends a network request anywhere. The one real wire is the edge fleet: a Hermes worker enrolled, heartbeats, and executes jobs today.

OpenClaw is the more interesting case, because part of the integration is genuinely real and shipped, while the rest sits in the same placeholder category as Hermes.

Real: workspace and skill portability

docs/openclaw.md documents an actual, working compatibility layer, not a full gateway clone:

“MindRoom supports a practical OpenClaw-compatible workflow focused on workspace portability… MindRoom is compatible with OpenClaw workspace patterns, not a full OpenClaw gateway clone.”

docs/openclaw.md

Concretely, this means an openclaw_compat config preset that expands into native MindRoom tools, and the ability to drop OpenClaw-style workspace files (SOUL.md, AGENTS.md, USER.md, MEMORY.md) straight into an agent's workspace. It explicitly does not include OpenClaw's gateway control plane, device/canvas tools, or heartbeat runtime.

The other real piece is skill metadata: src/mindroom/tool_system/skills.py reads an openclaw block from a skill's SKILL.md frontmatter (os, always, required binaries/env/config) to decide whether that skill loads on the current machine, the same schema OpenClaw skills use. A skill folder written for OpenClaw can generally be dropped into ~/.mindroom/skills/<name>/ and just work.

Real now: OpenClaw as an edge-fleet peer

The edge-worker path is no longer a placeholder: an OpenClaw worker daemon enrolls against the coordinator with a real identity, heartbeats, and executes leased jobs through the local OpenClaw gateway. The mesh layer's own gateway-authority round-trip remains local (src/mindroom/mesh/enrollment.py still treats the OpenClaw gateway enrollment as an external side effect), but the network-peer claim is real where it matters: jobs flow both ways over the authenticated P9 protocol.

The 14-agent aidlc_team is real and running today, in the aidlc Matrix room, coordinated in coordinate mode, one lead delegates to the smallest useful subset of specialists rather than fanning every message out to all fourteen. On 2026-09-04 every aidlc_* agent gained the edge_fleet tool (list nodes, queue jobs, poll results), which is the runtime call path into the P9 fleet, and the whole team runs with governed learning enabled (learning_mode: agentic).

The fuller lifecycle methodology, inception, requirements/design, implementation, local validation, security review, a human-gated deployment step, operations validation, is written down, but deliberately kept out of the running config:

“Deliberately isolated under docs/dev/aidlc-agent-team/; it is not included by either repository config.yaml or the runtime .mindroom/config.yaml.”

docs/dev/aidlc-agent-team/implementation-started.md

A related draft, mapping the fourteen agents onto AWS SageMaker's AI-DLC capabilities and adding a Tailscale pre-flight gate, exists as a proposal only (aws-aidlc-redesign-plan.md, marked "no infrastructure changes executed"). It was never promoted: there is no tailscale_check tool anywhere in src/mindroom/tools/, and the live agents don't reference one.

The 2026-09-03 answer was that the AI-DLC team had built the edge-fleet and mesh code but never called either at runtime. That gap closed on 2026-09-04: src/mindroom/tools/edge_fleet.py gives every live aidlc_* agent a direct call path into the edge-fleet job queue, and real OpenClaw and Hermes workers execute what gets queued. Authorship is now also a wire.

• docs/openclaw.md: accurate and current; the OpenClaw compatibility section above draws directly from it.
• docs/skills.md: the OpenClaw-compatible SKILL.md metadata format.
• docs/edge-fleet-production-activation-security-architecture.md: the fullest edge-fleet security writeup; its crypto and threat-model content is accurate, but its "not mounted" claim is now stale: the router is mounted, just disabled.
• docs/agent-mesh-gateway-architecture.md: the real, tested P1 mesh gateway, distinct from edge fleet despite sharing enrollment crypto.
• docs/architecture/governed-learning.md: the unwired learning loop that targets both an OpenClaw and a Hermes root.
• docs/dev/aidlc-agent-team/implementation-started.md and aws-aidlc-redesign-plan.md: the only lifecycle documentation for AI-DLC; both explicitly non-live.
• docs/dev/portfolio-register.md: the master P1–P10 status table; the single best source for real-vs-gated-vs-aspirational across the whole project.