What Is Kanban
Hermes Agent is an open-source AI Agent framework that runs on multiple platforms including the terminal, Telegram, Discord, and Slack. Its Kanban feature is a persistent multi-Agent collaboration task board that lets multiple independent named Agents (called profiles in Hermes) work together through a shared task queue — no fragile in-process subagent scheduling required.
Each task is a row in a SQLite database; every handoff is persistent data any agent or human can read and write; each worker is a full operating-system process with its own identity and memory. This complements Hermes’s existing delegate_task (one-shot, function-call-style subagent dispatch): delegate_task is for quick question-and-answer exchanges, while Kanban is for workflows that need sustained state, multi-role relay, and human intervention.
What It Can Do: Starting from a Real Scenario
Say you need to write a technical research report. The traditional approach is to let a single AI Agent do it end-to-end, which often results in: shallow research depth, a monotonous writing style, and mid-course deviations nobody corrects.
With Kanban, the flow becomes:
- You create a task in triage state: “Research the Hermes Kanban feature and produce an analysis report for developers”
- The system’s automatic orchestrator (decomposer) splits it into three subtasks: a researcher handles information gathering, an analyst does the synthesis, and a writer is responsible for the final text
- Two researcher subtasks run in parallel, each covering different information sources
- When they finish, the analyst starts automatically, reading both research outputs and synthesizing them
- When the analyst finishes, the writer starts and produces the report based on the synthesis
- Throughout the process, you can comment, adjust direction, or block and wait for a decision at any time
- The final output includes a complete audit trail: who did what, how long it took, and how many iterations occurred along the way
This isn’t a hypothetical — it’s Kanban’s standard working mode.
What Are Kanban’s Core Concepts
Kanban is made up of six components that work together.
Board is an independent task queue with its own SQLite database, working directory, and scheduling loop. A single installation can create multiple boards, isolated by project or domain.
Task is the basic unit on a board, containing a title, body, one assignee (the assigned profile name), a state-transition chain (triage → todo → ready → running → blocked → done → archived), and optional tenant namespaces and idempotency keys.
Link (dependency) records parent → child relationships between tasks. When all parent tasks complete, child tasks automatically move from todo to ready, where the scheduler picks them up. This enables “fan-out + fan-in” parallel orchestration.
Comment is the communication protocol between Agents. Both Agents and humans can append comments, and when a worker is (re)scheduled it reads the full comment thread as context. This is essentially a task-scoped conversation channel that doesn’t depend on the main chat’s context window.
Workspace is the directory workers operate in. scratch is a temporary directory, auto-cleaned when the task completes; dir:\<path\> points to an existing persistent directory; worktree is a Git worktree, suitable for coding tasks.
Dispatcher is a long-running loop that runs one round every 60 seconds by default: reclaiming expired claims → detecting crashed workers → promoting ready tasks → atomic claiming → spawning the assigned profile. It runs inside the Hermes Gateway process and needs no separate management.
How Humans Intervene in the Agent’s Work
The fundamental difference between Kanban and pure automated batch processing is that it leaves human intervention points at every stage of the workflow.
Entry control (Triage): tasks can be created in the triage state, which acts like a “parking lot.” You can first review whether the task description is clear and the decomposition reasonable, then decide whether to advance it into the execution queue.
Blocking mid-execution (Block/Unblock): when a worker hits a decision that needs human judgment, it calls kanban_block to pause proactively. For example, a translation task hits a technical term that needs confirmation, or a technical plan needs you to pick a direction. Once you decide, you unblock and the worker continues.
Ongoing comments (Comment): you can append comments to a task thread at any time, e.g. “please write in Chinese, under 3,000 characters” or “this direction is wrong, please follow X’s approach.” Workers read these comments the next time they’re scheduled.
Output review (Runs): every execution attempt is recorded in the task_runs table. You can inspect each attempt’s duration, result summary, and error messages; if you’re unsatisfied, edit the task description and reschedule.
Acceptance criteria in Goal mode: specify acceptance criteria when creating a task, and the worker self-checks against them after each round. The more explicit you write them, the more controllable the output.
What Collaboration Modes Does Kanban Support
Kanban isn’t a fixed orchestration scheme — it’s infrastructure that supports many collaboration modes. The official docs list nine typical modes:
| Mode | Shape | Example Scenario |
|---|---|---|
| Fan-out | N same-role workers in parallel | Research 5 technical options at once |
| Pipeline | Chained role relay | Collect → analyze → write → review |
| Vote/arbitration | N parallel + 1 aggregator | 3 researchers → 1 reviewer synthesizes |
| Long-running log | Same profile + shared directory + cron | Auto-generate an Obsidian journal daily |
| Human-in-the-loop | worker block → human comment → unblock | Tasks needing decision confirmation |
| @mention | Inline routing | @reviewer in a comment to request a review |
| Thread workspace | One dedicated board per chat thread | Managing multiple projects in parallel |
| Fleet farming | One profile manages N objects | Managing 50 social accounts at once |
| Triage specifier | One-line idea → system expands into a full task spec | Quickly capturing rough ideas |
How Tasks Are Assigned to Different Agents
Kanban doesn’t require multiple profiles. A single profile works fine — in that case it’s just a persistent, retryable, auditable work queue. Multiple profiles are for specialization.
Task assignment has three precision levels:
Manual assignment: explicitly pass --assignee <profile-name> when creating the task — you fully control who does what.
Orchestrator auto-assignment: the Orchestrator agent reads your profile list and descriptions and decides which profile to assign based on the task content. Precision depends on the quality of the profile descriptions.
Auto-decomposer: when a triage task comes in, the system uses an auxiliary LLM to read the profile roster, automatically decomposes it into a subtask graph, and routes each piece to the most suitable expert. If the LLM picks a profile that doesn’t exist, the task falls back to the default assignee.
Two Entrances, One Database
Kanban’s design has an important architectural choice: it has two operation interfaces, but the backend shares a single SQLite database.
Agents via tool calls: when the dispatcher spawns each worker, it automatically injects the kanban_* toolset (kanban_show, kanban_complete, kanban_block, etc.) into the model’s schema. Workers call these tools directly, without going through the command line. The benefits: no matter whether the worker’s terminal backend is local, Docker, or remote SSH, tool calls always reach the database; structured JSON parameters avoid shell quoting issues; and ordinary chat sessions carry zero schema overhead.
Humans via CLI or slash commands: hermes kanban create/list/show/... or /kanban create/list/show/... in chat platforms. The argument format is identical, and both entrances produce consistent read/write results.
There’s also a Dashboard GUI providing a drag-and-drop board interface with inline creation, multi-select batch operations, dependency editing, and real-time WebSocket updates.
What Scenarios Fit Kanban
Kanban’s applicability boundary can be drawn in one sentence: Kanban is worth starting only when what you need isn’t just an answer, but a stateful, interruptible, traceable work pipeline.
Three task types are its sweet spot:
- Multi-role relay needed: research → analysis → writing → review, multi-stage pipelines where each stage needs different expertise
- Human intervention mid-flight: confirming terminology in translations, adjusting research direction, approval for sensitive operations
- Parallel execution + result aggregation: N same-type workers running different subtasks simultaneously, with aggregation automatically triggered on completion
Conversely, simple Q&A, one-off small tasks, and fully automated unattended pipelines are fine with delegate_task or cron — no need for Kanban’s extra overhead.
Comparison with delegate_task
These two capabilities look similar, but their positioning is completely different:
| Dimension | delegate_task | Kanban |
|---|---|---|
| Shape | Function call (fork → join) | Persistent message queue + state machine |
| Parent-child relation | Blocks waiting for child return | Fire-and-forget after creation |
| Subagent identity | Anonymous subagent | Named profile with persistent memory |
| Recoverability | Fail is fail | block → unblock → re-run; crash → reclaim |
| Human interaction | Not supported | Comment / unblock at any time |
| Agents per task | One call = one subagent | N agents across a task’s lifecycle |
| Audit trail | Lost after context compression | Permanently stored in SQLite |
One sentence to tell them apart: delegate_task is a function call; Kanban is a work queue where every handoff is a row visible and editable by any profile or human.
Quick Start
Operating from a chat platform is just as simple: /kanban create "Research the AI Agent framework ecosystem" --assignee researcher.
References
Author: Cyber Herald
Original URL: https://torchtree.com/en/post/hermes-kanban-multi-agent-collaboration/
Publish Date: 2026-06-07
License: CC BY-NC-SA 4.0