Kanban Worker Lanes and Review Gates

A Kanban worker lane is the execution path for a class of task. The board owns lifecycle truth; the lane performs the work and reports the result through the Kanban contract.

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

The lane contract

Every lane needs an assignee identity, a spawn mechanism, and one terminal outcome. For the default Hermes lane, the assignee is a profile name and the dispatcher launches that profile inside the card's pinned workspace. The worker receives task and run context automatically.

A healthy run must end by completing the task or blocking it with a reason. A process that exits without either outcome is treated as a failure. This prevents a worker's final chat message from silently becoming the board's source of truth.

Lane checklist

• Name profiles by durable role, not by a temporary project nickname.
• Give each lane only the tools and skills its role needs.
• Pin the task workspace before the worker starts.
• Record changed files, tests, decisions, and artifact paths in a comment.
• Use a completion call only when the card is truly terminal.
• Use a block with a clear reason when approval or information is missing.
• Set maximum runtime and failure limits for expensive work.
• Keep an orchestrator focused on decomposition instead of implementation.

Review-required work

For changes that need a person to inspect code, copy, or a public artifact, block with a review-required reason after posting structured evidence to the comment thread. A reviewer can approve and unblock, or add requested changes for the next run. That makes review a visible state rather than an informal promise.

External coding CLIs are not a universal built-in lane. The spawn hook is extensible, but each integration must still map workspaces, authentication, exit behavior, and lifecycle calls safely. Do not assume an arbitrary CLI name can be assigned and dispatched automatically.

Pitfalls

• Letting worker output replace the canonical board state.
• Completing a run without tests, artifacts, or a useful summary.
• Using one powerful profile for every lane.
• Forgetting that misspelled or non-spawnable assignees remain ready.
• Retrying a superseded run without checking its current run identity.
• Treating a reviewer as optional after labeling the work review-required.

Verification steps

1. Assign a harmless card to a real profile lane.
2. Confirm the worker starts in the pinned workspace.
3. Inspect the task run and event records for the correct profile and run ID.
4. Have the worker post evidence, then block for review.
5. Add a reviewer comment and unblock the card.
6. Confirm the next run receives the prior thread and terminates exactly once.
7. Check hermes kanban tail and run history for crashes, timeouts, or duplicate endings.