Comparison
AI4Kanban vs.
Hermes Agent Kanban
Both products give agents a kanban board. The architectural boundary is different: AI4Kanban keeps the board as a portable project layer in your repository, while Hermes Agent Kanban makes it part of the Hermes runtime.
A Markdown board that lives with your code. Choose or change the agent that works from it without changing the board itself.
A unified system in which the board, dispatcher, and named agents share one durable Hermes runtime.
The practical difference
The two products solve much of the same problem, but at different layers. AI4Kanban is a portable planning system for the agent environment you already use. Hermes Kanban is an operational queue within Hermes, designed to coordinate multiple workers and recover interrupted work.
AI4Kanban — planning stays with the project
- Tasks and plans are Markdown files in your repository, so every change can be reviewed and versioned.
- The board has no database, gateway, or background service of its own.
- Claude Code, Codex, Cursor, Hermes, or another file-capable agent can execute the work.
Hermes Kanban — execution stays with the runtime
- A durable SQLite queue at ~/.hermes/kanban.db is shared by named agents and people.
- A dispatcher assigns ready tasks and recovers work after an interrupted run.
- The board is integrated with the Hermes / Nous stack and its kanban_* tools.
How to choose
Choose AI4Kanban when you want planning versioned with the code, prefer your current agent environment, or do not need a dedicated orchestration service. Choose Hermes Kanban when Hermes is already your operating environment and you want its dispatcher, named profiles, chat controls, and recovery model. The durable record is different too: AI4Kanban relies on files and git; Hermes stores queue state in SQLite.
Which agents can run the board?
This is the clearest dividing line. Because AI4Kanban uses ordinary repository files, any agent that can read and edit the project can use the board, including Hermes. Hermes Kanban is exposed through the runtime's kanban_* tools and is therefore specific to Hermes.
OpenClaw
Hermesany file-reading agent
Hermes only
OpenClawHermesOpenClawHermesAI4Kanban also works with Windsurf, OpenCode, Gemini CLI, and other tools that can read project files. Hermes Kanban is available only through the Hermes runtime.
AI4Kanban vs. Hermes Kanban
A marks a clear advantage; a dash marks a trade-off. AI4Kanban favors portability and operational simplicity. Hermes favors coordinated, recoverable execution across multiple agents.
A repository-native planning layer built from Markdown files.
A durable kanban queue integrated into the Hermes agent runtime.
None for the board itself; it uses files already stored in your repository.
A Hermes gateway, SQLite database, and dispatcher process.
In your repository, under the same version control as the code.
In ~/.hermes/kanban.db, with changes recorded as events rather than repository diffs.
One setup prompt installs a skill file and a small script.
Install Hermes, configure agent profiles, and run the gateway.
Your agent environment supplies parallelism; scheduled work is represented in the recurring/ folder.
The dispatcher claims ready tasks automatically and starts a worker process for each one.
No runtime-level recovery queue; interrupted scheduled work is picked up on a later run.
The queue recovers in-flight work with claim TTLs, heartbeats, stale-claim reclamation, and retries.
Refinement turns a card into concrete todos and explicit task relationships such as groups, blockers, and related work.
An LLM decomposer expands a task into a child-task graph and routes each child to a specialist.
Curated project memory preserves decisions and shipped work to improve future planning.
An append-only event log and per-attempt history support audit and recovery.
A local web board where card actions hand implementation, review, and archiving to an agent.
A live dispatcher view with drag-and-drop, run details, and controls available from chat apps.
Best suited to an individual or small team working in one repository.
Designed for many agents and boards, with multi-tenant operation and control from chat, email, and SMS.
Two different kinds of history
AI4Kanban keeps planning context so future proposals reflect earlier decisions. Hermes keeps an execution record so operators can inspect and reconstruct what happened. Each is useful, but for a different purpose.
AI4Kanban
Preserves decisions, not every event.
Four deliberately concise files capture what matters next, kept in one folder per module: readme.md records what shipped, decisions.md records the calls that were settled and why, rejected.md records what we turned down and why, and redesign.md records design mistakes not to repeat. goal.md sits on its own at the top of the memory folder. Agents read them before proposing or refining work; git retains the full change history.
“Why isn't idea X on the board?”
rejected.md records the idea and the reason it was declined, so it is not proposed again without new evidence.
Hermes Kanban
Preserves the complete execution trail.
Every state transition is written to an append-only log, and every attempt retains its exit code and worker output. That detail supports audit and crash recovery rather than future product planning.
“What happened to task 42 overnight?”
claimed → crashed → reclaimed → completed, with a separate log for each attempt.
Curated memory informs the next decision; an audit log explains the last execution. Neither replaces the other.
How much autonomy does the agent get?
Hermes Kanban is designed for "drop a one-liner, walk away" execution. AI4Kanban uses reviewed autonomy: you capture an incomplete idea, refine develops it into concrete requirements, and implementation waits for your approval.
You plan everything
No autonomy
Human-driven
Traditional kanban
You think of every task and break it down — Trello or Jira just records it.
Reviewed autonomy
Agent proposes, human approves
AI4Kanban
refine identifies gaps, develops the requirements, and presents the result for review before implementation.
Full autonomy
Unattended execution
Hermes Kanban
A short request becomes a task tree that is decomposed and executed without supervision. Claude Code's /goal follows a similar model.
Agent plans everything
Unattended execution: an early misunderstanding can propagate through an entire task tree before anyone reviews the result.
Reviewed autonomy: a flawed Markdown plan reaches review, but implementation has not started.
A refinement pass fills gaps, separates adjacent ideas into their own cards, recognizes work that is already complete, and turns judgment calls into questions. Once those questions are resolved, the card becomes ready for final review and implementation.
Two boards, two roles
Both provide a web interface. AI4Kanban's board is a control surface for project work: card actions start agent runs. Hermes's board is an operational view of the dispatcher: it shows the current state of the agent fleet.
AI4Kanban — local board
A local web interface for the Markdown board. Actions such as implement, review, and archive hand work to an agent, stream its output, and pause when human input is required.
Hermes Kanban — live dispatcher view
A live view backed by the event log, with drag-and-drop columns, run history, exit-status badges, and controls available from Discord, Slack, or SMS.
Where each one wins
The better choice depends on the operating model. AI4Kanban minimizes infrastructure and keeps planning portable. Hermes Kanban provides a durable shared queue for coordinated, unattended execution. Both can support parallel work, orchestration, and a dashboard; the advantages below are the capabilities that genuinely distinguish them.
AI4Kanban
No board service to operate
There is no board database, gateway, or daemon. Beyond the agent you already use, AI4Kanban is a set of Markdown files that works locally and offline.
Planning that travels with the code
The board is versioned in the repository and follows the project wherever it goes. Task and plan changes use the same review workflow as code, without an external database or dependency on one agent stack.
Memory designed for future decisions
AI4Kanban records rejected ideas, design lessons, and shipped work so future proposals build on earlier decisions. It deliberately retains planning signal rather than a complete execution log.
Fits the agent environment you already use
One setup prompt installs a skill file and a small script. There are no profiles or dispatcher settings to manage, and any file-capable agent can use the result, including Hermes.
Hermes Kanban
A shared queue for named agents
Multiple named agents and people can claim and hand off work on one durable board. The dispatcher monitors ready tasks and launches the assigned agent for each one.
Automatic recovery for in-flight work
Claim TTLs, heartbeats, stale-claim reclamation, retries, and circuit breakers let the queue recover tasks after a worker fails. AI4Kanban preserves the task, but recovery is left to the next agent or scheduled run.
Automatic decomposition and routing
The dispatcher's LLM decomposer turns a rough request into a graph of child tasks and routes each one to a specialist agent. AI4Kanban develops the plan through iterative refinement and human review.
Multi-agent operations at fleet scale
Hermes Kanban is designed for many agents across multiple boards, supports multi-tenant operation, and can be controlled from Discord, Telegram, Slack, email, and SMS.
Which should you use?
Choose AI4Kanban when
- You want tasks and plans versioned and reviewed with the code.
- You prefer a portable, offline-capable board with no service to operate.
- You want to choose your own agent environment, including Claude Code, Codex, Cursor, or Hermes.
- You are an individual or small team that values a focused planning layer.
Choose Hermes Kanban when
- Hermes is already your primary agent runtime, with profiles, gateway, and chat controls in place.
- You need one durable queue shared by multiple named agents and people.
- You need automatic recovery for interrupted work.
- You want the dispatcher to decompose tasks and route them to specialist agents.
- You operate many agents across multiple boards and communication channels.
Choose AI4Kanban for a repository-native planning layer that remains independent of the agent runtime. Choose Hermes Agent Kanban for a durable shared queue with integrated dispatch, recovery, and multi-agent coordination. The right choice is not about which board has more features; it is about whether planning should belong to the project or to the runtime.
They can also complement each other: use AI4Kanban to refine and review work in git, then use Hermes as the durable execution queue for approved, shared work.