The War Room reads Hermes' kanban database instead of keeping its own
UI layer for the native Hermes orchestration features
At a glance
- What is it?
- A Nuxt dashboard for the Hermes agent fleet that discovers profiles by walking a directory, reads the kanban SQLite file directly, and turns a chat message into a delegation by wrapping it in a preamble the orchestrator is told not to ignore.
- Who is it for?
- Adopt the War Room if you already run a Hermes fleet and the problem is visibility, because it adds no orchestration logic of its own and shows tasks, delegation and live tool calls in one place. Do not adopt it expecting to move the fleet to another host, since it shells out to the local hermes CLI and reads local SQLite files, or expecting to enforce delegation structurally, because the chat guard is a prompt preamble.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 13 days ago.
- What is it written in?
- Mainly Vue, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Same host, same process namespace, two SQLite files
The War Room is a browser dashboard over Hermes Agent's multi-profile delegation and kanban systems, and its coupling to them is deliberate and total. It needs Hermes installed on the host because it shells out to the `hermes` CLI and therefore shares a process namespace with it. It also needs Node 22 or newer.
It defines no task system of its own. A kanban task in the UI is a native `kanban_create` row, and the dashboard reads ~/.hermes/kanban.db directly rather than mirroring it. Profiles are discovered the same way: it walks ~/.hermes/profiles/<slug>/ and finds what is there.
What it does keep is its own SQLite file, data/war-room.db, holding the things Hermes has no concept of, namely assigned avatars, colours, given names, the active flag per operative and the mission conversation threads.
The consequence is architectural rather than cosmetic. This is a view onto a fleet running on one machine, not a remote control plane for a fleet running somewhere else. Moving the dashboard to a second host would mean losing both the CLI and the database, and the README does not document a remote mode.
Three pages: the floor, the roster and the archive
The interface is three routes, and each one answers a different question.
The War Room at / is the live view, split evenly between mission control on the left and the operatives floor on the right. Each active profile appears as a workstation: a disc tinted in that operative's assigned colour, an avatar standing on it, a name placard with a pulsing LED, and a status pill reading Standing by, Working on, or Blocked.
The Team at /team is the personnel file. Every profile is rendered as a paper ID badge with a lanyard hole, a coloured header strip, a square portrait, an italic callsign and a rendered barcode. It is also where you edit: rename a callsign, randomise an avatar, retrain an operative by toggling its skills and tools, hire new agents, or fire existing ones.
Missions at /missions is history. Every mission ever opened, paginated, filterable by Open, Archived or All, with the full thread readable on click. Nothing there is editable, which is the right call for an archive.
Your message gets wrapped in a preamble that forbids doing the work
The chat tab on the mission control side talks to the active orchestrator, and the interesting part is what happens to what you type.
Every message is wrapped in a hidden preamble that forces the orchestrator to delegate through the kanban rather than answer you. The stated prohibitions are specific: no doing the work itself, and no hallucinating task IDs.
This is enforcement by prompt, not by schema. Nothing in the interface prevents the orchestrator from ignoring the preamble and simply writing the code you asked for. What it does buy is consistency: a fleet that delegates behaves the same way every turn, which is the property a dashboard is trying to display in the first place. The Board tab beside it shows the payoff, a four column view of Todo, Ready, Running and Blocked, with each card carrying the assignee callsign, the title, time elapsed and the colour stripe of whoever owns it.
Worth knowing before you rely on it: the preamble is hidden from you as well, so if delegation misbehaves you are debugging the orchestrator's SOUL.md, not a visible instruction.
An operative is a profile with a callsign, and one of them routes
The mapping between Hermes concepts and War Room concepts is short enough to hold in your head.
A Profile is the raw thing, invoked as `hermes -p <slug>`, living in ~/.hermes/profiles/<slug>/. An Operative is that profile as the War Room presents it: a callsign, an avatar, a colour and an active flag. An Orchestrator is simply whichever operative you pick as the conversation partner for a mission.
The convention the project describes is one dedicated orchestrator, an example name being `lider`, whose SOUL and skills tell it to route and never execute, alongside workers such as `investigador` and `legal` that keep full tool access and are told to do the work. That division is the whole design: the leader never touches a tool, so a mission always fans out.
This also explains why the onboarding order matters. The README tells you to open The Team first and give each operative a callsign and a tailored SOUL.md before briefing an orchestrator, because a worker with a default SOUL.md has no instruction to either route or execute.
The drill-down is where the SSE stream turns into English
Clicking a workstation opens a side panel with that operative's entire current state, and this is where the dashboard earns its place.
Four things stack in it. The task currently executing, with the full title and body of the kanban row, its status badge, when it started and when it last sent a heartbeat. Who delegated it, chained back to the parent task and to the operative that created it, with their colour stripe. Every child task that operative has fanned out, each with its own status and assignee. And a recent activity timeline of tool calls and reasoning fragments, arriving live over an SSE stream while the agent thinks.
A fifth panel, the mission thread, appears only when the operative you drilled into is the active orchestrator, and it is read-only.
The heartbeat timestamp is the field to watch. Combined with the started-at time it is the difference between an agent that is working and one that has stopped without saying so, which is the failure mode a fleet of background profiles is most likely to hide.
Install is a tarball, two environment variables and a Nitro server
There is no package to install from a registry. The quickstart downloads a release tarball and starts the built server:
#Grab the latest release and run it
mkdir -p ~/hermes-war-room && cd ~/hermes-war-room
curl -L -o hermes-war-room.tar.gz \
https://github.com/Naroh091/hermes-war-room/releases/latest/download/hermes-war-room.tar.gz
tar xzf hermes-war-room.tar.gz
HERMES_HOME=$HOME/.hermes NITRO_HOST=127.0.0.1 NITRO_PORT=3000 \
node .output/server/index.mjs
# → http://localhost:3000The three environment variables are the whole configuration surface: HERMES_HOME points at the Hermes directory the dashboard will read, and NITRO_HOST and NITRO_PORT bind the server. The default binds to loopback, which is the right starting posture for a dashboard that shells out to a CLI with your permissions.
For development the project uses pnpm with a `pnpm dev` script, and the README also documents a production install that needs neither pnpm nor a source checkout, plus tmux recipes for keeping the dashboard and Hermes running together.
Nuxt 4 and Vue on top, ACP underneath, and two lockfiles
The stack is a Nuxt 4 application with Vue and TypeScript. The UI layer is @nuxt/ui with Tailwind CSS, and @nuxtjs/i18n is why the dashboard is described as multilingual, with the README itself offering a Spanish version of the page you are reading. Markdown from agent output is rendered with marked and sanitised with dompurify, which is the correct pairing given that the content comes from a model's tool output. yaml is a dependency, and so is @zed-industries/agent-client-protocol, the ACP client that carries a mission's model context across turns.
The package is marked private, so nothing is published to a registry, which matches the tarball distribution. Build, dev, preview, lint and typecheck map onto nuxt build, nuxt dev, nuxt preview, eslint and nuxt typecheck, and releases are cut by semantic-release rather than by hand.
One inconsistency is visible in the tree: a pnpm-lock.yaml and a bun.lock sit side by side while packageManager pins pnpm 10.33.2. Whichever is authoritative, the presence of both suggests a migration that was not cleaned up, and it is the sort of thing that produces a confusing dependency resolution for anyone building from source.
Licence is MIT, the default branch is master, and the last push landed on 2026-09-18, the same day as release v1.6.0. Before that, v1.5.0 shipped on 2026-05-18 and v1.4.1 on 2026-05-11, so the gap between the two most recent majors is four months of quiet development.
Editorial conclusion
Adopt the War Room if you already run a Hermes fleet and the problem is visibility, because it adds no orchestration logic of its own and shows tasks, delegation and live tool calls in one place. Do not adopt it expecting to move the fleet to another host, since it shells out to the local hermes CLI and reads local SQLite files, or expecting to enforce delegation structurally, because the chat guard is a prompt preamble. Verify your Hermes profiles already have distinct SOUL.md files before the roster page is useful to you.
Frequently asked questions
What does the Hermes War Room need to run?
Hermes installed on the same host, because the dashboard shells out to the hermes CLI and shares its process namespace, plus Node 22 or newer. You start the built server with HERMES_HOME, NITRO_HOST and NITRO_PORT set, and it listens on port 3000 by default.
Does the War Room replace the Hermes kanban?
No. A task in the interface is a native kanban_create row and the dashboard reads ~/.hermes/kanban.db directly. What it stores itself is data/war-room.db, holding avatars, colours, callsigns, active flags and mission threads.
How do I set up agents in the War Room?
Open The Team first and give each operative a callsign and a tailored SOUL.md, then brief the orchestrator from the War Room. The convention is one dedicated orchestrator profile told to route and never execute, with worker profiles that keep tool access and are told to do the work.
Can I see what an agent is executing right now?
Clicking a workstation opens a drill-down with the executing kanban row and its started-at and last-heartbeat timestamps, who delegated it, every child task it spawned, and a live timeline of tool calls and reasoning fragments arriving over an SSE stream.
What licence is hermes-war-room under, and what is it built with?
MIT. It is a private Nuxt 4 package with Vue and TypeScript, using @nuxt/ui, Tailwind CSS and @nuxtjs/i18n for the multilingual interface, and is distributed as a release tarball you run with `node .output/server/index.mjs`.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/naroh091-hermes-war-room)