Board & Workflows
The team’s board, at /kanban, is not stored anywhere: it is the event log, grouped.
One machine writes a card and every machine has it, with nothing syncing a database -
the reason it exists separately from Hermes’s own kanban (which is the SQLite file
the Hermes CLI keeps on one machine).
Four columns, and a card moves by naming the column it moves to rather than by dragging, one event with a name in it on the log instead of a stream of coordinates.
A card can be given to a machine or to an agent. Give it to an agent and whichever machine can actually run that agent claims the card, does the work, posts the result as a comment and moves it to REVIEW, review, not done: an agent finishing a task is a thing to look at, not a thing to trust. The earliest claim wins, ties broken by machine name, computed identically everywhere from the same events, no election, no coordinator. Without the claim, every machine that can run Claude would run the same card and one task would come back with four bills.
An agent can also act: post a message to a room, open a card, move one along. Nothing that runs a command or touches a file, an agent already has a whole machine for that. “Nobody” is a real assignee.
Workflows
Section titled “Workflows”A workflow, at /workflows, is an ordered list of steps, some of which stop and wait
for a person. This is what Loop, Pipeline and Kanban were underneath, three sidebar
entries doing one thing with three vocabularies.
| Was | Is now |
|---|---|
| A Loop cycle | A step with onFail pointing back at an earlier step, and a retry bound |
| A Pipeline gate | A gate step |
| A Kanban column | A run’s current step |
| A Kanban card assigned to an agent | An agent step |
Step kinds
Section titled “Step kinds”- shell, runs a command, as whoever runs the server, with the same authority the agents already have. Read a workflow before enabling it, the way you would a script.
- agent, records a prompt for an agent to pick up. It does not block.
- gate, stops the run and asks a person. Approve to continue; reject to end.
- note, records a line and moves on.
Retries, with a bound
Section titled “Retries, with a bound”Any non-gate step can name a step to go back to on failure and a maximum number of times, three by default. The bound is not optional: a build-judge-fix cycle with no bound is an outage, not a feature.
Triggers
Section titled “Triggers”- Manual, the button.
- Schedule, an interval in minutes (cron is a language and nothing here needs one). It fires immediately the first time, because an operator who switches something on and sees nothing for an hour concludes it is broken.
- Event, once per new event of a chosen kind: a CI failure, a patch landing. The first time it is seen it acts only on the newest event, so switching it on does not run it against a year of history.
What has already fired is kept on disk, so a restart does not re-run everything. Gates sit at the top of the screen: a gate is blocking somebody’s work right now.
A run has no state of its own
Section titled “A run has no state of its own”It is folded out of the log, so a server killed mid-run cannot leave a status file claiming “running” forever, and “who approved this, and when” is answerable months later, because the approval is a signed event with a note on it.
Migrating from Erebros
Section titled “Migrating from Erebros”Existing Loop, Pipeline and Kanban state is not converted, those boards were per-machine scratch space, and a converter would have to invent a history that never existed on the log. Recreate the ones you still want as workflow definitions; it takes a minute each.