Hermes War Room: a browser layer over Hermes kanban delegation

The terminal blindness that Hermes leaves behind

Hermes already ships the primitives for multi-agent work. Profiles are isolated agent personas with their own SOUL.md, skills, tool permissions, model and history. delegate_task is a synchronous in-process subagent call, useful for small one-shot fan-outs inside a single turn. Kanban is a durable SQLite-backed board where any profile can drop a row and the assigned worker picks it up asynchronously, with parent and child dependencies, blocking, comments and run history. The README is blunt about the consequence: both delegation paths work, and both are invisible from the outside. You talk to one profile in hermes chat while the rest of the fleet runs in background processes you can only inspect by SSH-ing into your own machine and grepping logs. The War Room targets that gap and nothing else. It is for the operator who has already bought into Hermes profiles and kanban, has a leader profile and a few worker profiles, and now wants to see the board and the agents without a second terminal. It is not for someone evaluating Hermes itself, and it is not a task system.

What the three pages actually render

The home route is split 50/50. On the left, mission control has two tabs. Chat wraps every message you send in a hidden preamble that forces the orchestrator to delegate through the kanban rather than doing the work itself or inventing task IDs. Board is a four-column kanban (Todo, Ready, Running, Blocked) where each card carries the assignee callsign, the task title, elapsed time and a colour stripe. On the right, the operatives floor draws each active profile as a workstation: a tinted circular disc, a Notionists avatar, a name placard with a pulsing LED, and a status pill reading Standing by, Working on, or Blocked. While the orchestrator is mid-thought, a speech bubble above the head surfaces the live step, either a tool call or a reasoning fragment. Clicking a workstation opens a drill-down panel with the executing task's full title and body, its status badge, started-at and last-heartbeat timestamps, the parent task that delegated it, the child tasks this operative has spawned, a live timeline of tool calls and reasoning fragments off the SSE stream, and the read-only mission thread if this operative is the active orchestrator. The /team route renders each profile as a paper ID badge with a lanyard hole, coloured header strip, portrait with crop marks, italic-serif callsign, monospace data fields and a CSS-rendered barcode. Renaming callsigns, randomising avatars, toggling skills and tools, hiring and deactivating agents all happen there. /missions is a paginated archive filterable by Open, Archived or All.

Data flow: two SQLite files and one CLI

The architecture is deliberately thin, and the README says so: the orchestration logic stays inside Hermes. The War Room discovers profiles by walking ~/.hermes/profiles/<slug>/ and persists the avatars, colours and given names it assigns in its own database at data/war-room.db. Missions live in that same local database, one thread per conversation with an orchestrator, each backed by an ACP session that carries model context across turns. Tasks are not duplicated. The dashboard reads ~/.hermes/kanban.db directly, so a kanban_create row written by any profile shows up without a sync step. Live agent activity arrives over an SSE stream, which is what feeds the speech bubbles and the drill-down timeline. The one coupling worth naming is that the war-room shells out to the hermes CLI, so it shares a process namespace with Hermes and must run on the same host. There is no remote agent protocol here, and no queue between the two.

Getting it running from the release tarball

The documented path needs Hermes installed on the host and Node 22 or newer. It downloads the latest release tarball, extracts it, and starts the Nitro server with the Hermes home pointed at the default profile directory. HERMES_HOME=$HOME/.hermes NITRO_HOST=127.0.0.1 NITRO_PORT=3000 node .output/server/index.mjs brings the dashboard up at http://localhost:3000. The README's suggested order is to open The Team first, give each operative a callsign and a tailored SOUL.md, then move to the War Room and brief the orchestrator with a real mission. Development setup uses pnpm dev, and the README points to separate Quick start and Production install sections for tmux recipes and production tuning; those sections are referenced but not reproduced in the material I have, so treat them as unverified. One convention matters more than any config key: the orchestrator profile, typically named lider, should have a SOUL and skills that tell it to route and never execute, while workers such as investigador or legal get full tool access and SOULs that tell them to do the work. The hidden chat preamble pushes in the same direction, but it cannot compensate for an orchestrator profile that is allowed to run tools.

Where the design costs you something

The same-host requirement is the sharpest constraint. Because the server shells out to the hermes CLI, you cannot run the dashboard on a laptop and point it at a build machine, and the documented bind address is 127.0.0.1 through NITRO_HOST, so exposing it beyond localhost is your decision and your problem, not a supported mode. Reading ~/.hermes/kanban.db directly is the second cost. It is what makes the board trustworthy, since there is no sync layer to drift, but it also means the War Room inherits whatever schema Hermes writes. A kanban schema change upstream can break the board, and nothing in the material describes a version check or a migration path. The four board columns (Todo, Ready, Running, Blocked) are a fixed reading of kanban state, so if your Hermes workflow uses statuses outside that set, expect them to be misrepresented or dropped. Finally, the three pages cover live work, the roster and the archive. There is no cost view, no token accounting and no alerting described; the pulsing LED and status pill are the whole notification story in the README.

What you would otherwise use instead

The direct alternative is the one the README names: hermes kanban tail, run per session, plus the hermes chat interface for one profile at a time. That approach needs no extra process, adds no second SQLite file, and cannot fall out of step with the kanban schema because it is the same tool that writes it. What it does not give you is a single screen showing the whole fleet. With tail you reconstruct delegation chains by reading rows and matching parent IDs yourself, and you have no view of what an operative is thinking between heartbeats. The War Room trades that manual reconstruction for a browser process that must run alongside Hermes, plus a local database holding avatars, colours and mission threads. If your fleet is two profiles and a handful of tasks, tail is the smaller tool and the better one. The dashboard earns its place when the delegation graph is deep enough that you cannot hold it in your head, which is exactly the case where the drill-down panel showing the parent task and the spawned children saves the most time.

Licence, upgrades and what the repository tells you

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are kept; that is a description of the licence text, not legal advice, and if you ship the War Room inside a product you should read the terms yourself. The release cadence in the supplied material is dense: v1.5.0 on 2026-05-18, v1.4.1 on 2026-05-11, v1.4.0 on 2026-05-09, with the last push to master on 2026-08-09 and no archived flag. Three releases inside ten days suggests active iteration rather than a settled surface, and the README still points readers to sections for tmux recipes and production tuning that are not reproduced here. Practically, that means upgrading is cheap if you track the release tarball and restart the Nitro process, and risky if you have patched the Vue front end, since there is no plugin or theme boundary described. Your own state lives in data/war-room.db and your profiles live under HERMES_HOME, so both survive a tarball swap; the schema expectations against ~/.hermes/kanban.db do not, and that is the thing to re-check after every Hermes upgrade rather than after every War Room release.

Editorial conclusion

Adopt the War Room if you already run Hermes with several profiles and you are tired of reading kanban state through terminal commands; the dashboard reads ~/.hermes/kanban.db directly and does not introduce a second task system. Do not adopt it if you run a single Hermes profile, because the operative floor and the delegation chain views have nothing to show, or if you need a hosted multi-user service, since the documented install binds to 127.0.0.1 through NITRO_HOST. Before committing, verify that your Hermes version still writes the kanban schema the War Room expects, that HERMES_HOME points at the profile directory the dashboard should walk, and that the .output/server/index.mjs path exists in the release tarball you download.

Official sources

1. Issues
2. License: MIT
3. Naroh091/hermes-war-room on GitHub
4. README
5. Releases