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 genuinely mounted in the live API (src/mindroom/api/main.py) — it isn't just a design doc. But it ships off by default (MINDROOM_EDGE_FLEET_ENABLED=false), and the project's own portfolio register is explicit about why:

“P9 — GATED — Production activation awaiting explicit security approval from Dwayne, do not activate.”

docs/dev/portfolio-register.md

The only thing that has ever exercised the full loop is edge_fleet_cross_device_demo.py at the repo root — a script that spins up one synthetic openclaw identity and one synthetic hermes identity and drives enroll → heartbeat → lease → execute → complete against a local instance. It's a correctness demo, not a real OpenClaw or Hermes binary talking to MindRoom.

There is no Hermes service, repository, or binary anywhere in this codebase. The name shows up in two places, and they mean different things:

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 this sends a network request anywhere. It's a consistent naming convention for a runtime the code anticipates, not one it has met.

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.

Placeholder: OpenClaw as a network peer

Everywhere OpenClaw shows up as something MindRoom would talk to — an edge-fleet worker runtime, a mesh gateway peer, a learning-loop publish target — it's the same kind of placeholder as Hermes. src/mindroom/mesh/enrollment.py says this outright about the one place a real handshake is even discussed:

“The real OpenClaw gateway enrollment handshake is an external side effect (a network round-trip to the OpenClaw gateway authority).”

src/mindroom/mesh/enrollment.py

That round-trip isn't implemented. The mesh code reuses edge fleet's cryptographic scheme locally for consistency; it doesn't call out to anything.

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. Its live configuration, though, is deliberately thin: each agent is little more than a role description and a couple of tools (shell, coding); there's no live instructions: block on the team itself.

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.

This is the answer worth remembering: the AI-DLC team built the edge-fleet and mesh code as engineering deliverables — it doesn't call either of them at runtime. No tool under src/mindroom/tools/ references the edge-fleet job queue, and no live aidlc_* agent config lists edge-fleet, mesh, Hermes, or OpenClaw access. The connection between them is authorship, not 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.