shannholmberg hermes agent control room four levels

Why this is in the vault

Shann Holmberg (same person as "Shannon Holmberg" in [[2026-04-08-four-levels-of-ai-use]]) extends his earlier four-levels framework from per-user maturity into per-fleet architecture: how one operator scales from one agent to a coordinated specialist team on one VPS. Load-bearing idea — "the control room is the brain that defines the system, the live runtime is the body that runs it; you can rebuild the body from the brain, you cannot rebuild the brain from the body" — names the control-plane-vs-runtime split RDCO has operated on implicitly via ~/.claude/ + vault but never formalized. Engagement: 6,679 bookmarks vs 2,067 likes on 1.2M impressions = reference-grade "save to study."

The four-level architecture

Four parts. You (operator), control room (docs/runbooks/registry folder that governs the fleet, does not execute), specialist agents (domain-bounded workers w/ own credentials/memory/skills), task bus (optional async handoff desk between orchestrator and specialists).

Four levels. L1 = one agent. L2 = multiple direct specialists, no orchestrator. L3 = orchestrator added as front door, specialists still reachable directly. L4 = L3 plus cron-driven workflows running without operator initiation — "a marketing department in your terminal that doesn't need you to start the day." Trap: don't add an orchestrator until 2-3 specialists prove useful directly.

Each agent: brain (MEMORY.md + USER.md, injected at session start), personality (SOUL.md), skillset (123 bundled skills + closed loop where agent writes new skills as it works). Filesystem split: control room (/root/vps-agents) = docs, no secrets; runtime (/srv/<agent>/data/) = secrets, memory, skills, sessions, crons.

Mapping against Ray Data Co — port delta

What RDCO already has

Control room (docs, registry, runbooks, env-map) → ~/CLAUDE.md + SOUL.md + ~/.claude/skills/ + ~/.claude/state/working-context.md + ~/.claude/projects/-Users-ray/memory/MEMORY.md + ~/rdco-vault/
Specialist agents w/ role-cards → ~/.claude/skills/ (each SKILL.md is a role-card) + sub-agent dispatches w/ implementation-notes contract per [[../02-sops/2026-05-18-implementation-notes-pattern-for-sub-agent-dispatches]]
Orchestrator (router/synthesizer/front door) → Ray-the-parent session + /check-board + /process-newsletter / /process-inbox (router-shaped skills that fan out)
Brain split (stable facts vs personality vs working state) → MEMORY.md + SOUL.md + working-context.md — exact three-file shape, different filenames
Closed learning loop (agent writes new skills as it works) → /skillify — codifies last conversation into a permanent skill
Verification specialists w/ bounded scope → /verify-vault-write, /verify-strategic-output, /verify-dispatch, /design-critic, /video-critic per [[../02-sops/2026-05-19-verification-as-independent-worker-pattern]]
Prototype → production lifecycle → IC-mode vs production-mode distinction (feedback_ic_vs_production_mode)

What RDCO is missing or under-formalized

Explicit task bus between specialists. Every specialist dispatch today returns through Ray-the-parent's context window — no persistent queue where one specialist drops a handoff for another to pick up async. Fine at current scale (one operator + Ray), load-bearing the moment SEO-agent needs to hand off to copy-agent without round-tripping the parent. Gap: no ~/.claude/state/task-bus/ directory; no inter-specialist handoff convention.
Control-room-vs-runtime naming not formalized. RDCO has the split de facto — ~/.claude/ + vault are the brain; running sessions + Notion board + Alpaca scripts are the body — but unnamed. When something breaks in runtime, no rule says "rebuild from brain, don't patch the body." One-line CLAUDE.md addition fixes it.
No multi-agent fleet on a VPS. RDCO runs on Ray's Mac Mini + founder's laptop + ad-hoc cron. Shann's L3/L4 picture (orchestrator + specialists each in own docker container on Hetzner, talking via task bus) would let specialist skills run concurrently rather than serially in one Ray session. Open question for founder: premature for L4-position RDCO, or exactly the unhobbling-the-COO move from project_l5_north_star_strategic_direction?
Per-agent credential isolation. Every skill Ray invokes inherits the full parent credential set (1Password, all MCPs). Shann's per-agent-credentials pattern means each specialist holds only the keys it needs. Useful for blast-radius reduction, not urgent.

Tactics worth porting

Name the control-room-vs-runtime split in CLAUDE.md. One sentence: the vault + ~/.claude/ are the brain (control plane); running sessions, the Notion board, deployed scripts are the body (runtime). The body is disposable, the brain is canonical. Near-zero cost, closes gap 2.
Stand up ~/.claude/state/task-bus/ + convention for one specialist to drop work for another to pick up async, even if today it's just a JSON file consumed by /check-board. Building the surface before we need it makes L3-style orchestration a config change, not a refactor.
Extend the "don't write skills on day one, run the work and let the harness write them" rule. /skillify already implements this — add a "ran-3-times-manually-first" precondition to skill creation so we stop reaching for SKILL.md before discovering the real shape.
Evaluate Hermes as L3 substrate after brain/runtime naming and task-bus surface land. Hermes ships strong defaults (memory, skill-writing loop, 20+ messaging surfaces); Claude Code is the "linux primitives" alternative we run. Worth a 2-hour spike on github.com/shannhk/hermes-agent-control-room to scope port-vs-stay tradeoffs.