Multi-Agent Board (Kanban)

13.3. Multi-Agent Board (Kanban) — When Subagents Aren’t Enough

The problem Kanban solves — what delegate_task cannot do

delegate_task is a synchronous RPC call: the parent agent forks a child, waits for it to finish, and receives a summary. Fast and useful for quick, tidy reasoning tasks — but it hits clear limits when you need to: coordinate a parallel research team with human participation mid-way, run a recurring operational process that must survive restarts, or build a pipeline where a PM writes the spec, an engineer implements, a reviewer rejects, the engineer retries, and the reviewer approves — all with a full audit history of every attempt.

Architecture — each task is a row, each worker is a real OS process

Kanban is a durable, SQLite-based work board (~/.hermes/kanban.db), shared across every Hermes profile on the same server — unlike subagents, which only exist within a single process. Each task is a row in the database; every handoff is a row anyone can read/write; each worker is a full operating-system process with its own identity — not a fragile “swarm of subagents in the same process”.

Two doors, one database

• Agents drive the board through the kanban_* toolset (kanban_show, kanban_list, kanban_complete, kanban_request_review, kanban_block, kanban_comment, kanban_attach…).
• Humans/scripts/cron drive it through hermes kanban ... (CLI), /kanban (slash command, working on the CLI and on every gateway platform), or the visual dashboard (a separate plugin).

Both doors go through the same kanban_db layer — ensuring every side sees exactly one consistent state, with no data drift.

The five standard Kanban work patterns it solves

• Research triage — multiple parallel researchers + one analyst + one writer, with humans stepping in mid-way.
• Scheduled operations — a daily newsletter that accumulates into a journal over several weeks.
• “Digital twin” — a durable assistant with its own name (inbox-triage, ops-review) that accumulates memory over time.
• Engineering pipeline — decomposition → parallel implementation across multiple worktrees (15.2) → review → retry → open PR.
• Fleet work — one specialist managing N targets (50 social accounts, 12 services to monitor).

Notes

• Choose Kanban over delegate_task as soon as any of the following conditions hold: you need human participation mid-way, survival across restarts, a full audit trail of multiple attempts, or work that must cross different profiles.
• For genuinely multi-host needs (separate physical servers), run an independent board on each host and use delegate_task or a message queue to bridge between boards — Kanban does not automatically sync across multiple servers.
• Don’t use Kanban for work that only needs a quick reasoning answer nobody will review — that is still delegate_task’s territory; using Kanban for such simple work is like bringing a sledgehammer to crack a nut.