Hermes Kanban multi-agent collaboration — the method, and how Pulse registers on vault

Summary

• Hermes Kanban is a durable SQLite board where every task row is also a live worker process, while delegate_task is a function call — reach for Kanban when work crosses profiles, survives restarts, or needs a human in the loop.1
• One board per unit is the right shape for Pulse: boards are hard-isolated (separate DB, workspaces, logs, env), so the pulse board is the unit's single coordination surface.1
• The vault is a projection, never a second source of truth. Hermes owns the truth; the .kanban file is rendered, verified, and pushed on a cron. Cards created in Obsidian would fork the board.1
• Goal-mode cards (--goal) run a judge-driven loop inside one card's worker session — the right primitive for open-ended work, while /loop is a session-local timer and not a board bridge.[1]5

The board, in one paragraph

A task is a row with a title, optional body, one assignee equal to a profile name, and a status from triage|todo|ready|running|blocked|review|done|archived.1 The dispatcher lives inside the gateway with kanban.dispatch_in_gateway: true and a 60-second tick, claims ready tasks atomically, and spawns hermes -p <assignee> with the HERMES_KANBAN_* env set so workers only see their own board.1 Workers never shell out to the CLI, because that env var flips on a task-scoped kanban_* toolset while KANBAN_GUIDANCE is injected into their system prompt automatically.[1]3 Every claim must terminate in exactly one of kanban_complete, kanban_request_review, kanban_block or process exit, and a clean exit without a terminal tool call is treated as a protocol violation.3

The primitives that matter for a multi-agent fleet

Assignment = a worker lane

A lane is an assignee string plus a spawn mechanism and a contract.3 For Hermes fleets the assignee is simply a profile name, so "multi-agent collaboration" means creating a profile per role and assigning one task to one profile.3 An unresolvable assignee leaves the card on ready with a skipped_nonspawnable event rather than silently executing elsewhere.3 The dispatcher injects the profile-scoped HERMES_HOME, so each worker reads its own profile's model, keys and skills, which makes the natural cost split possible — expensive model on the orchestrator, cheap models on worker profiles.1

Dependencies, handoff, and review

link PARENT CHILD (or parents=[...] at create) gates a child in todo until all parents are done, and a card whose parent is already done is created straight into ready — the pattern for remediation work after a merged change fails CI later.[1]2 When a child worker starts, kanban_show returns the parents' completion summaries and metadata plus this card's own prior attempts, so a retrying worker does not repeat a failed path.2 Review has two valid models: same-card review, where kanban_request_review is approved with kanban_complete or returned with kanban_request_changes, and a pre-created downstream review child, where the implementer must kanban_complete instead of stalk-blocking the parent.3

Goal-mode cards — the autonomy primitive

--goal on the CLI, or goal_mode=True on the tool and dashboard, runs that one card's worker in a Ralph-style loop: after every turn an auxiliary judge compares the output against the card's title and body as acceptance criteria and continues in the same session until the judge agrees, the worker self-terminates, or the budget runs out, which blocks the card for human review rather than exiting silently.1 The --goal-max-turns N budget defaults to 20, an unachievable goal blocks immediately and refuses kanban_complete and kanban_request_review, and a broken judge fails open to allow the lifecycle handoff.1 I verified the flags against the installed CLI help on this machine, where --goal, --goal-max-turns, --max-retries, --idempotency-key, --triage, --initial-status and --completion-contract all exist as documented.1

Boundary worth stating plainly: goal-mode cards borrow the /goal engine, not state. A chat-session /goal never creates or moves a card, and a card's loop is invisible to /goal status.1

/loop is a session timer, not a board bridge

The /loop command re-runs a prompt on a cadence inside the current session, which suits polling external state during a work session, and it allows one loop per session while leaving unattended schedules to cron.5 There is no documented mechanism where a loop hands tasks to Kanban, so the documented-adjacent pattern is the loop's session acting as orchestrator and calling kanban_create and kanban_link each tick, which keeps durable state on the board rather than in the loop.[1]5 A related verified negative: no dispatch_profiles routing key exists, because routing is purely task.assignee-driven and the real dispatcher key is the gateway's dispatch_in_gateway.[1]3

How Pulse registers on the vault — the working pattern

The question was "how to register on vault"; the answer that survives contact with the board is a four-stage projection loop, because a projection that quietly disagrees with the board is worse than no projection.1 The rule the file itself carries is that Hermes owns the truth, so dragging a card in Obsidian is overwritten by the next sync.

1. Fetch — run hermes kanban --board pulse list --json inside the script, never from a human's memory of the board.1
2. Render — emit one Obsidian list per Hermes state (Ready/Doing/Todo/Blocked/Triage/Review/Done), so a card's list is its state, plus an explicit Unmapped catch-all so a newly added state can never be silently dropped.1
3. Verify — re-parse the rendered file and diff it against the same task list: card count, missing ids, and per-card list↔status equality. A script that printed "synced" without this step is a claim, not a result.
4. Push — write to /home/lab/SolOS/vault/Pulse/Kanban/ and report the file's sha256 as the ground-truth artifact.

Format keys come from the installed plugin's main.js, not a README, because a settings block that does not parse makes the file render as plain markdown — it looks fine and does nothing. The file's own preamble carries the rule: Hermes owns the truth; drag a card here and the next sync overwrites it.

The lane runs unattended as a cron configured no_agent: true with script:, a 30-minute interval, local delivery and failure delivery to origin, so breakage reaches the principal instead of vanishing.5 Two traps cost real time on this build: cron-spawned subprocesses cannot find hermes on PATH, so call the absolute launcher, and multi-line card bodies mangle through the plain --body flag, so write the body to a file and pass --body-file.1

Registration conventions that keep one board honest

• One board per unit. hermes kanban boards switch pulse is sticky via ~/.hermes/kanban/current — pin it inside the sync script rather than trusting a shell's state.1
• Migration with provenance. Porting cards between boards works by re-creating each with the same title, assignee and body, passing --idempotency-key port-<old-id>, recording the origin id in the body, then completing it.1 A re-run is a no-op rather than a fork.
• Registry cards must not be claimable. An inventory card created ready will be dispatched to a live worker that "works" the inventory, so park it with --initial-status blocked or --triage to exist for reading without burning a model.1
• Cron registration is two cards, not one. One card per job carrying schedule, state and owner, plus a unit roll-up card that flags paused jobs for owner confirmation — observed live on this board, where both of Tam's jobs were paused.
• --idempotency-key on every automated create. A retried automation returns the existing id instead of duplicating work.1

What we should actually use (recommendation)

• Keep the Pulse unit on one pulse board — research, crons, studies and tasks coexist there, which is what makes the vault projection worth reading, and boards are hard-isolated so a second board would be a separate world rather than a convenience.1
• Profile-per-role for collaboration. Name profiles after the role, give each a description so the built-in decomposer can route to it, and keep orchestrator profiles off the implementation toolsets so they must decompose rather than execute.[1]3
• Goal-mode for open-ended lanes. The /goal feature's standing budget auto-pauses rather than reversing on exhaustion, so a study card written with explicit acceptance criteria and a --goal-max-turns budget keeps working across sessions without a human re-poking it.[1]4
• Health over optimism. Before believing a stale board, run hermes kanban diagnostics and hermes kanban log <id> — on this build the board's own diagnostics surfaced a capability-blocked registry card that a plain "done" reading would have hidden.1
• Never hand-edit a done card's status. Status changes come from lifecycle events driven by a worker or a human on the board, not from editing the projection or force-editing a row; the correct close-out verbs are complete and archive.1
• Profile names are the routing table. The dispatcher resolves task.assignee against installed profiles, so a fleet is wired by naming each profile after its role, and profiles that lack a description are still routable by name.[1]6

Relation

2026-10-08-hermes-multi-tenant-hosting

Sources

1 https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban2 https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban-tutorial3 https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban-worker-lanes4 https://hermes-agent.nousresearch.com/docs/user-guide/features/goals5 https://hermes-agent.nousresearch.com/docs/user-guide/features/loops6 https://hermes-agent.nousresearch.com/docs/user-guide/profiles