Durable Kanban Boards for Multi-Agent Work

Hermes Kanban is a local, durable task board shared across profiles. It is designed for work that may cross agent roles, pause for a person, survive a crash, or need an audit trail after the original conversation is gone.

Official documentation: https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban

Kanban or delegated task?

Use delegate_task when a parent agent needs a short reasoning result before it can continue. Use Kanban when the work should become a durable card with an owner, status, comments, dependencies, retries, and a history that another profile or person can inspect.

A Kanban card moves through a visible lifecycle such as triage, ready, running, blocked, done, and archived. The board stores this state in local SQLite rather than only in a model context window.

Board design checklist

• Give each board one project, repository, or operational domain.
• Write a bounded goal and a concrete definition of done on every card.
• Assign a named profile whose tools and skills fit the work.
• Link dependencies instead of relying on prose such as “do this later.”
• Pin a workspace when file changes matter.
• Use comments for durable decisions, test evidence, and review notes.
• Block a task when human input is required rather than guessing.
• Set retry and runtime limits for unattended workers.

Operating pattern

Start with one small board and a disposable task. Inspect it with the CLI or dashboard, promote it to ready, watch the dispatcher claim it, and review the recorded run. Useful operator verbs include init, create, show, link, watch, tail, diagnostics, complete, block, and unblock under hermes kanban.

Kanban is deliberately single-host. A board database and its worker process checks belong to one machine. Separate hosts need separate boards or an explicit external coordination layer.

Pitfalls

• Treating Kanban as a faster form of synchronous delegation.
• Creating cards without acceptance criteria or a verification surface.
• Assigning a profile that does not exist and leaving work stranded in ready.
• Hiding important decisions only in worker logs instead of board comments.
• Assuming local PID and crash detection coordinates workers across hosts.
• Marking code work done before the required review or test gate.

Verification steps

1. Create a test board and one low-risk task.
2. Confirm the task is visible from both the CLI and dashboard.
3. Assign a disposable worker profile and promote the task to ready.
4. Watch one claim, heartbeat, and terminal state in the event history.
5. Add a dependency and confirm the downstream task waits.
6. Block and unblock a test task and verify the comment thread survives.
7. Run hermes kanban diagnostics and resolve every stranded or unhealthy signal.