Kanban Execution
What it is
A visible execution workflow where the agent uses boards to track and move work.
In plain terms
An auto repair shop’s job board keeps each car’s ticket in a column — waiting, in the bay, test drive, ready for pickup — and the mechanic ending their shift pins a note to the ticket explaining exactly where the job stands before the next mechanic picks up the keys. Kanban Execution is Hermes running that same board for its own work: tasks move through columns as agents pick them up, and nothing gets handed off in silence — every transition carries a written reason the next worker can actually read.
Why it matters
A kanban task carries one of seven explicit states — triage, todo, ready, running, blocked, done, archived — and kanban_block records why a worker stopped: dependency auto-resumes once the blocking task finishes, needs_input and capability surface a human-readable reason on the board, and repeated block/unblock cycles for the same reason auto-escalate the task to triage. kanban_complete then forces a structured handoff, a summary plus machine-readable metadata, and any listed artifact file uploads straight to the subscribed human’s chat. State, reason, and handoff replace a transcript nobody has time to read.
How it works
A board isn’t just a display — an embedded dispatcher inside the gateway ticks on an interval, looking for tasks that are ready, assigned, and not yet claimed by a worker, and spawns an agent process for each one (gateway/kanban_watchers.py). While running, that worker can fan out further work of its own: kanban_create adds a child task gated on its parent, so the child only becomes eligible once the parent finishes, and kanban_link can wire that same parent-to-child dependency onto tasks that already exist (tools/kanban_tools.py). Workers don’t hand off through a shared chat log; kanban_comment appends a note to a task’s thread, and that note gets stitched directly into the next worker’s system prompt the next time someone picks the task up, making the comment thread the deliberate channel for passing context forward.
A concrete example
Three subagents are working through a migration: one converts the database schema, one rewrites the API layer, and one updates the tests — the API rewrite can’t start until the schema conversion is done.
- The schema task is created first; the API and test tasks are created as children pointing back to it.
- The API task stays in todo until the schema task moves to done, at which point it auto-promotes to ready.
- Partway through the API rewrite, the worker needs a decision only a human can make, so it calls kanban_block with kind=‘needs_input’ and a short reason describing what it needs; the board surfaces that reason to the person watching it.
- Once they answer in the task’s comment thread, the worker resumes and later calls kanban_complete with a summary of what changed.
How it connects
This note belongs to the Workflow Patterns family. Its closest neighboring concepts are: Slack Second Brain, Agent Team Delegation, Agent Runtime.
Source evidence
vendor/hermes-agent/toolsets.py#<file>— Structural Source Map fallback for toolsets.py. A core source file in the Tool Registry and Toolsets structure within Tools, Toolsets, and MCP.tool:kanban_block— Explicit Source Map scope boundary: tools/kanban_tools.py is outside the approved Core scope.tool:kanban_complete— Explicit Source Map scope boundary: tools/kanban_tools.py is outside the approved Core scope.
Workflows
- Kanban Agent Execution
Related articles
- Six Hermes Use Cases for a More Intentional Personal Operating System
- Ten Hermes Workflows That Turn a Chatbot into a 24/7 Assistant
- How to Use Hermes Better Than Most People: Architecture, Project Isolation, and Scalable Workflows