Hermes Kanban

A durable queue your profiles work out of. You create cards; the dispatcher claims them and spawns the assigned profile as a real process. You already run Hermes. This is the part of it that behaves differently.

The loop

A card names a profile. The dispatcher sweeps the board every 60 seconds, claims what is ready, and spawns that profile as its own OS process with the kanban_* tools in its schema. The worker reads its card, works, and writes a summary and metadata back onto the run. Nothing is held in a session. Every handoff is a row in ~/.hermes/kanban.db that any profile, or you, can read.

It is not delegate_task

delegate_task is a function call. Fork, join, one anonymous subagent, answer returns to your context. Failed is failed.

Kanban is a queue with a state machine. Fire and forget. Named profiles with their own memory. Block, unblock, re-run; crash and reclaim.

They are not alternatives. A kanban worker can call delegate_task inside its own run.

Two front doors

Agents drive the board through the kanban_* toolset. A worker never shells out to hermes kanban.

You drive it through hermes kanban …, /kanban …, or the dashboard.

Both routes go through the same kanban_db layer, so the two views cannot drift.

One pass, in order

1 Reclaim stale claims.
2 Reclaim crashed workers: pid gone, TTL not yet expired.
3 Promote todo → ready where every parent is done.
4 Claim atomically, one worker per card.
5 Spawn the assigned profile.

That order is why a card can sit in ready for one tick and move in the next. Open the board and step it yourself.