The Kanban Board: Coordinating Multiple Agents

Where This Fits Next to Delegation

Lesson 8 covered delegate_task -- a parent agent spawning short-lived children for one turn. The kanban board solves a different problem: persistent, asynchronous coordination across multiple agent profiles (from Hermes Agent Fundamentals Lesson 4) over time, not just within a single turn. Tasks survive between sessions, can be picked up by whichever agent profile is free to claim them, and form a real audit trail of who did what.

Getting Started

hermes kanban init

This creates a local kanban.db that holds your boards and tasks.

Boards

hermes kanban boards list
hermes kanban boards create <slug>
hermes kanban boards switch <slug>
hermes kanban boards show
hermes kanban boards rename <slug>
hermes kanban boards rm <slug>

Boards let you separate unrelated streams of work -- a "website" board and a "infra" board, for instance, rather than mixing every task into one undifferentiated list.

The Task Lifecycle

hermes kanban create "Migrate database schema"
hermes kanban list                          # or: ls
hermes kanban show <id>
hermes kanban assign <id> <profile>
hermes kanban claim <id>
hermes kanban comment <id> "found the issue, fixing now"
hermes kanban complete <id>

assign directs a task at a specific agent profile deliberately. claim is the opposite direction -- an agent picking up an available task on its own rather than waiting to be assigned one. Both patterns are supported because some workflows benefit from explicit assignment and others benefit from a pool of agents pulling from a shared queue.

Dependencies Between Tasks

hermes kanban link <parent> <child>
hermes kanban unlink <parent> <child>

Linking establishes that one task depends on another -- useful for structured handoff, where a "write the migration" task should not be claimable until a "design the schema" task is actually done.

When Work Cannot Proceed

hermes kanban block <id> "waiting on API credentials"
hermes kanban schedule <id> "revisit after the Q2 release"
hermes kanban unblock <id>

block and schedule serve slightly different purposes: block signals something is actively stopping progress right now, while schedule parks a task for later without implying anything is currently wrong -- a useful distinction when you are reviewing a board and trying to understand which stalled tasks need your attention versus which are simply not due yet.

Cleanup and Observability

hermes kanban archive <id>       # Hide from the active list without deleting
hermes kanban tail <id>          # Follow a task's event stream live
hermes kanban dispatch           # Run a dispatcher pass
hermes kanban context <id>       # Print the context a worker would see for this task
hermes kanban specify <id>       # Flesh out a vaguely-defined triage task
hermes kanban decompose <id>     # Fan a large task out into smaller ones
hermes kanban gc                 # Remove archived workspaces

tail is particularly useful while a multi-agent workflow is actually running -- you can watch one task's events arrive in real time rather than polling show repeatedly. specify and decompose exist for the common case where a task starts as a rough idea ("improve onboarding") and needs to become something concrete and actionable before any agent can usefully claim it.

A Practical Pattern

A reasonable way to start using this for real: create one board per project, write tasks as you think of them rather than trying to plan a whole project's task list upfront, use link for genuine sequencing dependencies (not for loosely related tasks), and check in with tail or show on anything you have assigned to a specific profile rather than just claimed-and-forgotten. The board is most useful when it reflects real, current state -- a kanban board nobody updates is worse than no board at all.

With cron, skills, messaging, MCP, the API server, delegation, voice, browser, vision/generation, and the kanban board all covered, the next lesson turns to making everything you have built reliable under real-world failure conditions.