Hermes kanban: a task board your agents work through
Nous Research's multi-agent feature: named profiles claim tasks from a shared SQLite board, a dispatcher caps concurrency and spend, and /kanban runs it all from Telegram. How it actually works.
Hermes kanban is Nous Research’s multi-agent work system: in the docs’ words, “a durable task board, shared across all your Hermes profiles, that lets multiple named agents collaborate on work”, without fragile in-process swarms. Tasks live in a SQLite database on your machine and flow through triage → todo → ready → running → blocked → done; a dispatcher ticks every 60 seconds by default, hands ready tasks to the profiles assigned to them, and caps how many run at once. Humans drive it from the hermes kanban CLI or as /kanban commands from any connected chat platform, Telegram included. It’s the feature that turns one Hermes install into a small staffed team, and it assumes a computer that’s on when the work runs.
The board is the coordination layer
The design bet is that a persistent queue beats a clever swarm. Instead of agents spawning agents in one process, every piece of work is a card with a status, an assignee, comments, and links to parent tasks. State lives in ~/.hermes/kanban.db (WAL-mode SQLite, so concurrent readers and writers don’t corrupt it), with separate databases per named board. Because the board is durable, a run that dies halfway leaves its trail (sources, comments, the last completed step) for the next agent to pick up, and an orphan-reconciler recovers claims from workers that vanished.
Profiles are the workers
The agents doing the work are Hermes profiles: named instances with their own memory, model choice, and skills. A typical board pairs an orchestrator profile that decomposes rough ideas into child tasks with specialist profiles that execute them; each worker gets kanban lifecycle guidance injected into its system prompt automatically, so a freshly spawned profile knows how to claim, comment, complete, or block. Assignment is explicit (--assignee researcher) and profile descriptions help the orchestrator route work. Cards in triage are auto-decomposed by default, an auxiliary model call you can point at a cheap model, since every scoring and decomposition tick costs tokens.
The dispatcher, and the knobs that cap spend
The dispatcher runs inside the gateway process (dispatch_in_gateway: true) and wakes on a configurable tick, dispatch_interval_seconds: 60 by default. The settings that matter most in ~/.hermes/config.yaml under kanban: are the caps: max_in_progress (board-wide concurrency) and max_in_progress_per_profile bound how many LLM-driven workers can burn tokens simultaneously. Start at 2 and raise it after you’ve seen what a morning costs. failure_limit (default 2) auto-blocks a task after consecutive spawn failures instead of retrying forever, a stale timeout reclaims tasks after four hours of silence, and auto_decompose_per_tick caps how many triage cards get decomposed per tick. Parent-child gating is the quiet workhorse: a child created with parents stays parked until, per the docs, the dispatcher “promotes todo → ready when all parents are done”, so research tasks can gate a writing task without anyone watching.
Driving it from chat
Every CLI verb is also a slash command from any platform Hermes is connected to: /kanban list shows the board, /kanban show t_abc opens a card, /kanban comment, /kanban unblock, and bulk forms all work mid-conversation. The docs note the slash path deliberately bypasses the running-agent guard, so you can inspect and nudge the board while agents are working. In practice the blocked column becomes a human review queue: agents park finished or stuck work there, and you approve or redirect it from your phone. It pairs naturally with scheduled runs: scouts filing cards overnight, you reading the shortlist over coffee.
The boundaries to respect
Kanban is single-host by design: profiles on the same machine share the board, there’s no multi-machine sync, and the optional dashboard plugin is unauthenticated on purpose because it binds to localhost. The docs warn against --host 0.0.0.0 on shared hosts, the same never-expose rule every agent surface deserves. All profiles under one account see all tasks, so isolation between clients or projects means separate boards at minimum. And because the dispatcher only ticks while the gateway runs, the whole system inherits the category’s standing requirement: an always-on machine. A board on a laptop that sleeps is a team that stops showing up to work.