Kanban Worker Lanes — Division of Labor

Think of a busy kitchen: the head chef doesn’t cook every dish, they write orders on a whiteboard, and each station — grill, salad, plating — picks up what they need and marks it done. That’s exactly how Hermes Kanban works for AI agents.

What Is a Kanban Board?

It’s a shared task board for all your AI assistants. Every task lives in a single database file (~/.hermes/kanban.db), so any agent can view, claim, or update tasks at any time. Unlike asking one agent to “call” another (that’s delegate_task), the Kanban board survives crashes, timeouts, and bad luck — tasks don’t vanish just because one agent died mid-conversation. They also coexist inside one run. A kanban task executes in an isolated managed worker under the profile’s gateway, and its delegate_task children are reserved by that gateway under the worker’s execution: each child gets its own session (listed as a subagent of the card’s session), counts against delegation.max_concurrent_children and delegation.max_spawn_depth, returns its result inside the card’s turn, and ends with the worker. If the gateway goes down mid-child, the child is retired, never resumed. Work that must outlive the gateway, or needs its own reviewer, still belongs in child cards (kanban_create with parents).

Two Doors, One Board

You can use the board in two ways, but they always see the same data:

1. Agents use it via tools — they call kanban_show, kanban_create, kanban_complete, etc. No manual work from you; they just read and write the board.
2. You use it via the terminal — type hermes kanban or /kanban in chat to see and manage tasks yourself.

# View all tasks
hermes kanban list

# Create a new task
hermes kanban create "Write weekly report" --assignee weekly-reporter

# Mark a task done
hermes kanban complete 42

How the Columns and the Live Stream Behave

Queue columns list cards in dispatch order — priority first, then oldest first, so the top card spawns next. The done column is different: it’s history, and it lists newest-completed first. On the CLI you get that same order with:

hermes kanban list --status done --sort completed-desc

The --sort flag also accepts completed-desc, created, created-desc, priority, priority-desc, status, assignee, title, and updated.

If you’re watching the board live, the WS endpoint /events?since=<event_id> streams task_events rows. Without since, the stream starts at the board’s current tail — the /board snapshot already holds the past. Pass since=<latest_event_id> to catch up from there, or since=0 to replay history. When Kanban is open in a split tile, the same Board control sits in the board’s own header row, after the task count.

GitHub Logins Are Per Profile

When a card’s acceptance check runs gh, it uses the assignee profile’s own login — the GH_TOKEN and GH_CONFIG_DIR from that profile’s .env — never whatever login the process completing the card happens to have. This matters on multi-profile hosts where each profile represents a different GitHub identity (say, one per org): sign gh in per profile by setting GH_CONFIG_DIR in that profile’s .env.

A few caveats worth knowing:

• The token must live in the profile’s .env (or a configured secret source). A GH_TOKEN merely exported in your shell or a systemd unit is scrubbed from the gh child process and never re-added.
• An assignee profile with no gh login of its own — or one that no longer exists — is refused with not logged in instead of quietly falling back to ~/.config/gh.
• Unassigned cards still use the ambient login.
• A login that can’t see the repository is rejected with classification=auth, naming the profile and repository, rather than being treated as a retryable infrastructure failure.

When a Card Can’t Be Dispatched

If the dispatcher refuses to spawn a card because the assignee profile doesn’t exist in this home (or isn’t listed in kanban.dispatch_profiles), it writes a skipped_nonspawnable event with the {assignee}. That event is written once per card — repeated only when another event lands in between — so show and tail name the missing profile without adding a row every tick. The card stays in ready; reassign it or install the profile.

Why Not Just delegate_task?

Aspect	delegate_task	Kanban
Style	Like a phone call: wait for reply	Like email: drop it and move on
Failure	Task lost if agent crashes	Task stays; can retry or reassign
Human input	Not possible	Comment, block, or unlock anytime
Participants	One agent at a time	Multiple agents can work the same task

The key difference: Kanban is “fire-and-forget.” The task persists until someone marks it complete. Even if an agent crashes halfway, another can pick up the card and continue.

When Retries Run Out

After N consecutive failed attempts, a circuit breaker fires and emits a gave_up event carrying {failures, effective_limit, limit_source, error, terminal_provider?}. The task auto-blocks with the last error. The effective limit is resolved in this order: the task’s max_retries, then the dispatcher’s failure_limit / kanban.failure_limit, then the built-in default.

One special case: terminal_provider: true means the worker exited with code 78 on a provider error that a retry can’t fix — a revoked credential, a model that no longer exists, or a startup credential failure that explicitly requires re-login (hermes auth / setup), which exits 78 before the first turn. (Other startup failures exit 1.) In that case the breaker fires on the very first attempt and sticks, regardless of the configured limit.

A Quick Warning About Linking Cards

If a worker is blocked on a task and creates a support card to fix the missing piece, don’t link the support card as a child of the blocked task. That link would gate the support card behind the very task it’s meant to unblock, so neither ever runs. Instead, just mention the parent task’s id in the support card’s body. If you do create a bad link, hermes kanban unlink <parent> <child> releases it.

What Is Kanban Good For?

• Research teams: several agents gather data, one analyst synthesizes, one writer drafts the final piece
• Scheduled jobs: every morning, an agent generates a brief and appends it to a running log
• Engineering pipelines: break work into cards → parallel development → peer review → merge
• Batch management: one agent manages 50 social accounts, each with its own card

A Practical Tip for Beginners

Don’t over-engineer at first. Start with one simple scenario: create a task, let one agent complete it, and watch the status change from your terminal. Once that feels natural, try two agents — one collects information, the other writes the summary. Remember: the real power of Kanban is “tasks never get lost, and you can always check status,” not complex automation.

Summary: Kanban upgrades AI collaboration from “phone calls” to “whiteboard management” — more reliable, more flexible, and always open for human intervention. Next time you feel your AI agents are tripping over each other, give them a shared board.