Hermes Kanban as a multi-agent collaboration plane — and Tam's vault registration pipeline

Summary. A verified live system study of the two coordination halves Young asked about: (1) Hermes Kanban — a durable SQLite-backed task board acting as the fleet's multi-agent dispatch lane; (2) Tam's vault registration pipeline — the laptop-mirror → LAB-main sync that turns research work into durable file artifacts. How each works, what Hermes docs advise, what today's live telemetry shows, where our two lanes currently sit (one healthy, one deliberately blocked), and what to do about it. Every number below came from live tool reads at 2026-10-11 ~18:58 AEDT; every Hermes claim is cited against the official docs, fetched fresh.

TL;DR

• ✅ Kanban is young but measurably working. One 41-card / 44-run day (3 profiles). Median card-to-done 3.9 min. Median run duration 1.0 min. p90 5.8 min. Longest card 84.5 min (weekly study). Two provider-wall crashes (retried, then completed fine).
• ⚠️ Vault sync lane is deliberately blocked — fail-closed at the LAB-root move (/home/lab/SolOS/vault, Young 10-03/10-07). Not a fault, needs a mapping decision.
• ⏳ Cron "The dispatcher isn't ticking on its own": vault-sync cron 305a8f2d68a3 and prod-publisher e7c65172cb53 are held paused; only the kanban↔Obsidian sync (b4d3d20e) is running. Paused state is honest (won't fire into the blocker), but silent — someone must remember they're parked.
• ✅ Board has fleet-table structure but zero child links — the fan-out shape is available but unused. Not loading it into memory; note here (memory store is full).

1. What Hermes Kanban is, per the official docs

A durable SQLite-backed task board where a dispatcher routes work to named agent profiles. Positioned in the docs as the shape that covers the workloads delegate_task can't — every handoff is a durable, logged, visible-for-everyone row. Per the docs' own comparison (/docs/user-guide/features/kanban):

One-sentence distillation the docs gives: delegate_task is a function call; Kanban is a work queue where every handoff is a row any profile (or human) can see and edit. They coexist — a kanban worker may call delegate_task internally mid-run.

Key doc-substance:

• Dispatcher: long-lived loop, every N s (default 60): reclaims stale claims, reclaims crashed workers, terminates over-long runs, promotes ready tasks, atomically claims, spawns assigned profiles. Runs inside the gateway by default.
• Lifecycle truth: ready → running → review/blocked/done/archived. Worker lanes execute work but never own the truth; all transitions flow through kanban_* tool calls, never CLI shelling.
• Workers, per board: spawned inside their own transient systemd scope (hermes-worker-kanban-<task>-run-<run>.scope), so they survive a dispatcher restart ⇒ no half-finished work lost to a gateway bounce.
• Failure handling (docs, verified against our log file too): stale-claim TTL reclaim → only a genuinely dead PID; protocol violation → bounded retry before auto-block; failure limit exceeded → auto-block with the last error. Poor toolless exit (narrated-but-not-called-the-terminal-tool) → protocol_violation event.
• Peer coordination, not hierarchy: any profile can read/write any task — the docs go as far as to note workers should not cross-coordinate un-invited, and orchestrators should get the kanban toolset but not implementation tools.
• Idempotent create for automation and restart safety.
• Multi-key status: also claimable by review_dispatch: false for human-only boards; kanban.review_dispatch: true default spawns a bundled sdlc-review skill for reviews.
• Scratch workspaces: default kind, deleted on task complete; deliverable files declared via kanban_complete(artifacts=[...]) are copied to durable attachment storage before cleanup — carry-out-the-outputs hygiene is built in.

2. Live telemetry — today, one board (pulse), 2026-10-11

Pulled fresh from the live kanban.db (/home/eva/.hermes/kanban/boards/pulse/), not from memory of an earlier read:

• Board inventory (now): 41 tasks total. Status split: 39 done, 1 running (that card is this study), 1 blocked. Assignees across the fleet: eva 22, eve 11, tam 8.
• 44 runs on the day, all 38 supervisons out of the pulse board, spawn rate ~38/day.
• Run outcomes: 39 completed / 9 crashed / 1 blocked / 1 reclaimed / 1 no-op-that-day.
• Timing (this board's 39 done cards): created→completed median 3.9 min; longest 84.5 min (weekly macro study, t_df4b4fdc) and 75.8 min (t_3877310a, monthly study). Per-run durations: median 1.0 min, p90 5.8 min, max 13.8 min.
• Crashes (9) were one root cause, resolved by retry: three runs failed with HTTP 400: Upstream request failed: Model is unavailable. against the model that was hot that day; each task then completed via a requeued run. No systemic lane fault — exactly the circuit-breaker-and-retry shape the docs describe.
• Cross-board isolation works as designed: only one dispatcher, but solos-v3 board lives in its own kanban.db (11 tasks today, separate file) with pinned board env vars per worker — no cross-board bleed.
• Handoff failures caught and surfaced: 16 completion_blocked_empty_result events + 7 gave_up events, meaning workers that exited without calling a terminal tool got protocol_violation + nudges + budget, and were returned for a retry rather than a false green. An "empty handoff" is visible on the card, not hidden.
• Child-link inventory (our boards): parent→child dependency edges (task_links) total 0 rows today across both boards. Every card is a root card; no fan-out. This is the one structural gap relative to the docs' richer fleet patterns.
• 9 crashed runs + 1 reclaim + 1 gave_up against 44 total — a 20% per-run crash rate that is almost entirely one transient provider fault, i.e. retries absorbed it with zero human action.

3. Tam's vault-registration pipeline — verified live

How research work becomes a durable artifact on the main vault:

1. Mirror-first: notes are drafted on the laptop store (/home/eva/vault/pulse/...) before any push. Current mirror holds 70 research notes (research/{ai,architecture,desk,health,macro,market,medical,news,technical}), 2 weekly-study notes, agents/ tree, private/ desk tree.
2. Sync lane: ~/.hermes/profiles/tam/scripts/sync_vault.sh, laptop → lab@192.168.4.60:/home/lab/SolOS/vault (canonical LAB main vault root confirmed by Young 10-03 / 10-07). sha256-verified before any push; poll/pull-back (remote listing is refused by the vault's access mode — write-only for the producer), and fail-closed — if a mapping or schema problem stands, it writes nothing rather than guessing. Includes the per-path (not per-basename) temp-file fix — sibling-agent same-named notes can't cross-hash.
3. Cron harness — 3 jobs in the profile store (~/.hermes/profiles/tam/cron/jobs.json):
   • 305a8f2d68a3 tam-vault-sync — every 30m — paused
   • e7c65172cb53 pulse-publish-prod — every 30m — paused
   • b4d3d20e6d00 pulse-kanban-obsidian-sync — every 30m — enabled, scheduled, green
4. Closed-loop healthy case (confirmed green): b4d3d20e6d00 is running the sync_pulse_kanban.py lane — the working, exercised half of the pipeline today.
5. Blocked-but-honest case (confirmed): the vault-sync lane scripts set LAYOUT_MAP_CONFIRMED=0, failing with exit 78 rather than writing the wrong path. This is fail-closed at the right gate: LAB root moved to /home/lab/SolOS/vault (Young 10-03 + 10-07 confirmations), and the last audit found 12 source-only files plus a README conflict; a per-area mapping + owner review of unique/private files is the missing decision, not a missing mechanism. Last attempt (10-06 13:58 AEDT) logged 23 lines failing one file then gave PARTIAL/FAILED - see log, which is the expected fail-closed behavior — not silent rot.
6. Obsidian projection lane (sync-kanban-projection skill, verified 10-11) is the human-readable side of the pipeline: cron no_agent: true, durably placed at <owner>/scripts/, output to /home/lab/SolOS/vault/Docs/SolOSV3/06-implementation/PLAN-AND-STAGES.kanban, patients the "cards flip state while you verify" gotcha (verified 4 cards flipped running→done between two checks today).

4. What docs advise — mapped against our lanes

5. Open questions / recommendations

1. Unblock the vault-registration pipeline — the mechanism is sound but the mapping decision is the gate: the 12 source-only files and README conflict from the last audit still need an owner ruling. Once confirmed, run sync_vault.sh by hand once, verify the LAB-side manifest populates, then flip the two paused crons (305a8f2d68a3 vault-sync, e7c65172cb53 prod-publisher) back to enabled: true and verify the cron page shows state: scheduled — the skill's own rule: a script passing by hand proves nothing about its schedule.
2. Trial fan-out: one deliberately multi-child card on the pulse board (parent → 3 children via kanban_create(parents=[...]), orchestrator-side only) would exercise the fan-out path end-to-end. The pieces work individually (spawn, retry, block/reclaim, cross-board isolation) — only the fan-out shape is untested.
3. Note the fan-out is deliberately unused so far — the docs pattern is there and documented; nothing today indicates a fault. Flagging as observable backlog, not recommendation to change board behavior immediately.
4. The lab-side kanban→Obsidian projection lane is healthy — 10-11 verified in the sync-kanban-projection skill record; nothing to change there.

Verdicts and prepared status markers (Young-facing)

• ✅ Verified (tool call + returned content, not memory): board metrics, run outcomes, crash root causes, cross-board isolation, mirror structure, cron store states, sync script fail-closed behavior, LAB path from script header, blocked lane's last log line.
• ⚠️ Partially verified: docs pages fetched are the four listed in source links; the further sub-pages (dashboard, tutorial) were reachable but not fully traversed.
• ⛔ Not attempted (deliberate): restaging LAYOUT_MAP_CONFIRMED=1 — needs the mapping ruling; flipping the two paused crons — needs the unblock first, plus owner sign-off.
• 🔎 Open question to the fleet: given the fan-out shape is unused and available, is there a hard boundary reason to keep all cards as root cards — or is fan-out simply untested? ⏳ awaiting a decision from Young/Sol (shared decision plane, cross-agent).

🎯 Tam's Read: the coordination plane (Hermes Kanban) is measurably doing its job — 41 cards, 44 runs, 90% of crashes self-healed, handoffs that fail loudly instead of Faking green — while the file-registration pipeline is fail-closed waiting on one human ruling (the 12-file mapping conflict), which is exactly the right failure mode: the machine refuses to guess, the human decides, the pipeline and the registry stay honest.

Sources.

• Hermes Agent docs (fetched 2026-10-11): /docs index, /docs/user-guide/features/kanban, /docs/user-guide/features/kanban-worker-lanes (+ llms.txt index of the docs tree).
• Verified live at the window of writing: /home/eva/.hermes/kanban/boards/pulse/kanban.db (tasks, task_runs, task_events, task_links), ~/.hermes/profiles/tam/scripts/sync_vault.sh, ~/.hermes/profiles/tam/cron/jobs.json, ~/.hermes/profiles/tam/scripts/sync_pulse_kanban.py, ~/.hermes/kanban/boards/solos-v3/kanban.db, the last failed run tail of the vault sync, the /home/eva/vault/pulse/ tree shape.
• The fleet skills that govern both halves: sync-kanban-projection, archived vault-research-registration, fleet-deep-dive-collab.