Q & Hermes
Hermes Harness on Tower
Standing up Hermes on the home Tower as Mallory's dev-driver + memory brain, wearing two hats from v1 — without disturbing mallory-vm.
Situation
Mallory's roadmap has a *Hermes integration (dual memory)* track that assumed Hermes would run on mallory-vm. That box is resource-starved (2 vCPU, ~650 MiB free, no GPU) — running a persistent agent there alongside the existing cron jobs is a real OOM risk, and a local model is impossible without a GPU. This spec refines the host assumption: Hermes runs on the Tower (Unraid) instead, which has RAM and GPU headroom to spare.
v1 wires Hermes to wear two hats at once: a dev-driver (git/gh/Node/wrangler/vitest, opening real PRs) and a memory brain (its own multi-layer memory, plus vault recall). The edge-Worker router + digest-sync-back half of the dual-memory track is explicitly deferred to later phases.
Key decisions
Dedicated VM, not a container
A lightweight Ubuntu KVM VM on Unraid — Hermes' install is native (uv + Python 3.11, systemd gateway service), so a real systemd host is the path of least resistance and stays GPU-passthrough-ready for later.
Access via Cloudflare, not open ports
cloudflared in the Tower VM exposes SSH behind CF Access — same trust model as the existing Worker↔Hub stack, no inbound router ports. One manual bootstrap step from Alex, then Claude Code proceeds autonomously via an ssh ProxyCommand alias.
Claude via OpenRouter for v1
Hermes has no first-class Anthropic wizard entry, so OpenRouter proxies Claude for all reasoning; local vLLM on the GPU is a Phase 3 follow-on for cheap/bulk task-classes.
Vault two-writer model: disjoint ownership, not locks
The vault already has live Hub writers (briefing, calendar-sync, vault-sync…). Hermes gets its own Hermes/ namespace; every path has exactly one owner, so concurrent writes never content-conflict — a git rebase-push retry loop handles the resulting non-fast-forward pushes.
Telegram as the v1 chat gateway
Simplest, mobile-friendly, independent of work Slack. A read-through or bidirectional Mallory-native interface is a deferred future flavour.
Architecture
A phased build: access → Hermes install → dev-driver toolchain, with vault brain and edge integration explicitly held for later phases.
~/.hermes/ (SQLite, three-layer memory).tower-hermes SSH alias.Hermes/ without racing the Hub.mallory and mallory-runtime.Risks & guardrails
Hermes is pre-1.0
~Monthly releases with shifting APIs/behaviour — pin a known-good release and treat upgrades as deliberate.
OpenRouter cost/latency vs. native Anthropic
No native Anthropic adapter confirmed at design time; compare against a native path at install time if one exists.
Tower uptime (home server)
Acceptable for a dev-driver today; revisit before Hermes becomes load-bearing for Mallory's live assistant duties.
cloudflared bootstrap
Requires one manual local/LAN step from Alex before Claude Code can proceed autonomously.
Delivery
Phase 0 — Access
cloudflared SSH-over-Access to the Tower VM; Claude Code verifies VM specs and toolchain.
Phase 1 — Hermes up
VM created, Hermes installed, Claude via OpenRouter wired, CLI + Telegram gateway live, a hello-world task round-trips.
Phase 2 — Dev-driver
git/gh + Node/wrangler/vitest wired; Hermes runs a real Mallory build/test round and opens a PR.
Phase 3 & 4 — deferred
Vault brain + local model, then edge digest-sync and atomic Hub→Hermes note migration are each their own later increment.
Out of scope
docs/superpowers/specs/2026-06-14-hermes-harness-on-tower-design.mdplan ·
docs/superpowers/plans/2026-06-14-hermes-harness-on-tower.md