Kanban: A Multi-Agent Coordination Board

Hermes Kanban is a durable task board shared across all your Hermes profiles, designed for multiple named agents to collaborate on work without fragile in-process subagent swarms. Every task is a row in a SQLite database, every handoff is a row anyone can read and write, and every worker is a full OS process with its own identity. It covers workloads that a simple function call can't — research triage with a human in the loop, scheduled ops building a journal over weeks, persistent digital-twins that accumulate memory, and engineering pipelines that decompose → implement → review → iterate → PR.

Two Front Doors, One Board

The board has two surfaces, both backed by the same ~/.hermes/kanban.db:

• Agents drive the board through a dedicated kanban_* toolset — kanban_show, kanban_list, kanban_complete, kanban_create, kanban_block, kanban_comment, kanban_attach, and more. A spawned worker gets these tools in its schema and reads its task by calling tools, not by shelling out to the CLI.
• Humans (and scripts, and cron) drive it through hermes kanban … on the CLI, /kanban … as a slash command, or the dashboard.

Both routes hit the same kanban_db layer, so reads see a consistent view and writes can't drift.

Core Concepts

• Board — a standalone queue of tasks with its own SQLite DB, workspaces directory, and dispatcher loop. You can run many boards, one per project, repo, or domain; single-project users stay on the default board.
• Task — a row with a title, optional body, one assignee (a profile name), a status (triage → todo → ready → running → blocked → review → done → archived), and optional tenant and idempotency fields.
• Link — a task_links row recording parent→child dependencies; the dispatcher promotes todo to ready when all parents are done.
• Comment — the inter-agent protocol. When a worker is (re-)spawned, it reads the full comment thread as part of its context.
• Workspace — the directory a worker operates in, chosen at creation: a disposable scratch dir, an existing shared directory via dir:<path>, or a git worktree for coding tasks.

The Dispatcher

The dispatcher is a long-lived loop that runs inside the gateway by default. Every tick (default 60 seconds) it reclaims stale or crashed workers, promotes ready tasks, atomically claims work, and spawns the assigned profile as a worker. Each worker is spawned with the board pinned in its environment so it can't see other boards. After a configurable number of consecutive spawn failures (default 2), the dispatcher auto-blocks the task with the last error as the reason — preventing thrashing on tasks whose profile doesn't exist.

Kanban vs. delegate_task

They look similar but are different primitives. delegate_task is an RPC call — fork then join, parent blocks until the child returns, anonymous subagent, no resumability, hierarchy is caller→callee. Kanban is a work queue and state machine — fire-and-forget after create, named profiles with persistent memory, block/unblock/re-run and crash reclaim, humans in the loop via comment/unblock at any point, peer coordination where any profile reads or writes any task, and a durable audit trail in SQLite. Use delegate_task when the parent needs a short reasoning answer before continuing; use Kanban when work crosses agent boundaries, needs to survive restarts, may need human input, or must be discoverable later. They coexist — a kanban worker may call delegate_task internally during its run.

Multi-Project Boards

Boards separate unrelated streams of work into isolated queues, and each has an entirely separate DB, workspaces, and logs. Workers see only their board's tasks. Creating a new board is easy:

hermes kanban boards create atm10-server --name "ATM10 Server" --switch
hermes kanban --board atm10-server create "Restart ATM server" --assignee ops

Board slugs are validated to prevent path-traversal tricks, and the dashboard shows a board switcher as soon as more than one board exists. You can store file attachments (PDFs, images, source documents) on tasks — capped at 25 MB each — so a worker has the source material without you pasting paths into the body.

How Workers Interact

When the dispatcher hands a task to a worker, that worker's model drives the task through kanban_* tool calls rather than CLI commands. A typical flow ships completion checkpoints near 90% of the iteration budget, letting a worker verify the task contract or persist a progress comment before the hard cap. The shared completion boundary checks task contract ownership, and a durable audit trail plus a consecutive-failure circuit breaker keep the board reliable.

Key Takeaways

• Kanban is a durable, profile-shared task board backed by SQLite — a distinct primitive from delegate_task's one-shot RPC.
• Agents drive the board through kanban_* tools; humans drive it through the CLI, /kanban, and the dashboard.
• A gateway-embedded dispatcher reclaims crashes, promotes dependencies, and spawns named profile workers every ~60 seconds.
• Tasks carry assignees, statuses, weights links, comment threads, workspaces, and file attachments.
• Multi-project boards keep unrelated streams isolated with separate DBs and workspaces.