Hermes Agent Kanban: Visual Task Boards Guide

The Hermes Agent Kanban is a built-in, durable task board where one or more Hermes agents pick up work, move it through columns, and finish it autonomously. According to the official Hermes Kanban docs, tasks flow through the states triage → todo → ready → running → blocked → done, and all state is stored locally in a SQLite database at ~/.hermes/kanban.db.

What the Hermes Agent Kanban board is

The Hermes Agent Kanban is a durable, SQLite-backed task board shared across all Hermes profiles on a single host. It exists so multiple agents can coordinate on a shared queue of work rather than each running in isolation, and so you can watch multi-step agent jobs as cards that move left to right.

Hermes Agent itself is Nous Research's open-source, self-hostable autonomous agent, released under the MIT license and documented on its public GitHub repository. It descends from the OpenClaw lineage and can import settings, memories, skills, and API keys from an existing OpenClaw install. The Kanban board is one of its workflow features rather than a separate product, so there is nothing extra to install once you are on a version that includes it.

Each card on the board carries an assignee (a profile name), an optional body, optional dependency links, a workspace kind, and an optional tenant namespace. That metadata is what lets the board act as both a human-readable status view and a machine-readable work queue at the same time.

The board columns and what they mean

The board uses six working columns plus an archive, and each maps to a precise state in the task lifecycle. The classic to-do / doing / done mental model still applies, but Hermes splits the early and stuck states out so coordination stays explicit.

The blocked column is the one most teams underestimate. Per the Kanban docs, blocks are routed by reason — dependency, needs_input, capability, or transient — so a stuck card tells you why it stopped, not just that it did.

How tasks get created, claimed, and run

Tasks are created from the CLI, assigned to a profile, then picked up automatically by a dispatcher. You do not manually drag cards into "running" — the dispatcher does that for you.

A task is created with a command like the one below, documented in the Hermes Kanban tutorial:

hermes kanban init
hermes kanban create "Summarize this week's research" \
    --assignee analyst --tenant research-project \
    --priority 2 --body "Pull top 5 papers and write a brief"
hermes dashboard   # opens the board at http://127.0.0.1:9119

From there, a cron-driven dispatcher runs every 60 seconds by default. It promotes ready tasks, atomically claims one, and spawns the assigned profile as its own OS process with HERMES_KANBAN_TASK set in its environment. The spawned worker then drives the card through a dedicated toolset — kanban_show, kanban_list, kanban_complete, kanban_block, kanban_heartbeat, kanban_comment, kanban_create, kanban_link, and kanban_unblock.

Reliability is built in. The docs describe a circuit breaker that auto-blocks a task after a configured number of consecutive spawn failures (default 2) so the board does not thrash, plus crash detection that reclaims a task when its worker PID disappears or its claim time-to-live expires. Long-running workers are expected to call kanban_heartbeat to signal liveness. If you have already stood up Hermes, see our Hermes Agent setup guide for where these commands fit in the install flow.

Why a board helps with long-running agent work

A Kanban board helps because long-running, multi-step agent work otherwise lives invisibly inside a single chat thread where you cannot see progress, blockers, or handoffs. Turning each step into a card makes the state of the work observable and recoverable instead of locked in the agent's context.

Three properties make the difference. First, durability: because state is in SQLite, a card survives a crash, a restart, or a closed terminal, and the dispatcher can resume it. Second, parallelism: you can fan out independent cards to different profiles and watch them run side by side, with the dashboard supporting per-profile lanes inside the Running column. Third, dependency enforcement: parent → child links mean a task waits in todo until everything it depends on is done, so order is guaranteed without you babysitting it.

This is the same reason human teams use boards — but here the "workers" are agent profiles. The board becomes the shared source of truth for what is queued, in flight, stuck, and finished. For coding-heavy pipelines specifically, the board pairs well with worktree workspaces, which our guide on long-running multi-agent dev workflows covers in depth.

A concrete multi-step workflow example

A typical workflow chains dependent tasks so they run in the correct order without manual coordination. The example below, adapted from the official tutorial, builds a feature in three stages: design, implement, then test.

SCHEMA=$(hermes kanban create "Design auth schema" \
    --assignee backend-dev --tenant auth-project --priority 2 \
    --body "Design user/session/token schema" \
    --json | jq -r .id)

API=$(hermes kanban create "Implement auth API endpoints" \
    --assignee backend-dev --tenant auth-project --priority 2 \
    --parent $SCHEMA \
    --body "POST /register, /login, /refresh, /logout" \
    --json | jq -r .id)

hermes kanban create "Write auth integration tests" \
    --assignee qa-dev --tenant auth-project --priority 2 \
    --parent $API \
    --body "Cover happy path, wrong password, expired token"

Only the schema task becomes ready immediately. The API task stays in todo until the schema task is done, and the test task waits on the API task. The docs list research triage (parallel researchers plus an analyst and writer), scheduled ops that build a journal over weeks, and persistent named "digital twin" assistants as other common board patterns.

You can also create, block, unblock, comment, and watch the board from inside a chat session using the /kanban slash command, which works across gateways like Telegram, Slack, and Discord. If you are wiring agents into external tools, our Hermes MCP integration guide and Hermes skills guide explain how those capabilities attach to the profiles running your cards.

Limitations and Tradeoffs

The Hermes Agent Kanban board is local-first and host-bound, which is both its strength and its main limitation. Because the SQLite database lives on one machine, the board coordinates profiles on that host rather than across a fleet of separate servers, and there is no managed cloud board to fall back on if the machine is off.

A board is also not free of operational overhead. You still have to design good task decomposition, pick sensible priorities, and write profiles that know how to finish their cards cleanly. A poorly scoped card can sit in blocked waiting on input, and an over-aggressive fan-out can spawn more parallel workers than your model budget or machine comfortably supports. When NOT to use it: for a single one-shot prompt with no dependencies or parallelism, a plain chat session is simpler than standing up a board. Hermes itself is also fast-moving open-source software, so verify exact flags and defaults against the current docs before relying on them. For how Hermes compares to its OpenClaw roots overall, see our OpenClaw vs Hermes Agent comparison.

Related Guides

• Hermes Agent Setup Guide
• Hermes Agent for Long-Running Multi-Agent Dev Workflows
• Hermes Agent MCP Integration
• OpenClaw vs Hermes Agent