Minions review: a Kanban mission control for Hermes Agent sessions

The supervision gap Minions is built for

Hermes Agent can run autonomous work, but the README describes the operational cost plainly: juggling terminal sessions, losing track of which job finished, and manually checking long-running tasks. That is a supervision problem, not a capability problem. The agent already does the work; what is missing is a durable record of what is running, what finished, what is waiting on a human, and what stalled.

Minions answers that with a Kanban board. Cards move through in progress, in review and done. Successful agent runs land in a review queue automatically rather than disappearing into scrollback. The target user is named in the README: Hermes power users running several sessions across projects, indie founders delegating research, ops, writing and coding, and anyone with long-lived Hermes work who needs to know what finished and what is stuck.

It is worth being precise about what this is not. Minions does not make Hermes smarter, cheaper or faster. It is a control surface bolted onto an existing agent runtime, and its value scales with how many concurrent Hermes sessions you already run. One session does not need a board.

One Hermes root session per card, and where the state actually lives

The README's How It Works section is short but specific: each task is a persistent Hermes root session. You talk to it, it works, and the board reflects where everything stands. That means a card is not a job spec that spawns a fresh process each time; it is a long-lived conversation with its own context, which is why per-task model and reasoning effort overrides make sense.

State is split across two stores, and the split matters when you think about backup and portability. Chat transcripts live in Hermes's own session database. Minions stores task metadata, status and per-task settings in a local SQLite database, created on first run, with state under ~/.minions/ per the Quick Start. So the board is not a complete record: if you move the SQLite file without the Hermes session database, you keep the cards and lose the conversations.

Execution runs through a Python worker rather than the Node process. The .env.example exposes HERMES_PYTHON for the path to a Python with Hermes dependencies, HERMES_AGENT_DIR pointing at ~/.hermes/hermes-agent, and HERMES_AGENT_RUN_LIMIT defaulting to 10 as the maximum concurrent agent runs in that worker. HEARTBEAT_CONCURRENCY defaults to 2. Those two numbers are the real capacity dials, and the README does not document what happens to queued work when the run limit is reached.

Installing Minions and creating your first supervised task

The README lists two prerequisites: Node.js 18+ and Hermes Agent. Note the discrepancy with the repository's own package.json, which declares an engines field of node >=20. If you are on Node 18, the published package may refuse to install or run. Treat 20 as the floor.

The documented install is a single npx invocation, which fetches and runs the published minionsai package. Run it from a shell and leave it running; the server stays in the foreground.

npx minionsai

After it starts, the README says to open http://localhost:6969. That port is the default and is also the PORT value in .env.example, so if 6969 is taken you can override it there. On first run Minions creates a local SQLite database and keeps state in ~/.minions/.

To confirm which build you are actually running, the README gives two commands. The first reports the installed CLI, the second asks the npm registry what the latest published version is.

minions --version
npm view minionsai version

The Settings page in the UI also shows the version of the running Minions server, which is the one that matters if you started the server some time ago and have since upgraded the CLI.

For a first real task, the workflow the README describes is: describe what you want in chat and walk away. The agent decides how to get it done. Successful runs move their card to ready for review, and nothing reaches done without your sign-off. Before that first run, check the optional environment variables. All of them are optional and the defaults work for local development, but HERMES_AGENT_DIR is the one worth setting explicitly if your Hermes installation is not at ~/.hermes/hermes-agent.

PORT=6969
HERMES_PYTHON=
HERMES_AGENT_DIR=~/.hermes/hermes-agent
HERMES_AGENT_RUN_LIMIT=10
HEARTBEAT_CONCURRENCY=2
MINIONS_HOME=~/.minions
DB_PATH=~/.minions/data/minions.db

Hermes-only today, and what the adapter interface does not buy you

The README's FAQ answers the obvious question directly: can I use this with other agents? Not yet. The adapter interface exists, but launch is Hermes-only, and OpenClaw is described as next on the roadmap. An interface that exists without a second implementation is a design intention, not a feature. If you are not running Hermes Agent, Minions is the wrong tool right now, and no amount of configuration will change that.

The roadmap also lists scheduled task supervision, notifications via Telegram, WhatsApp or webhook, a skills library, and the OpenClaw adapter. None of those are shipped as described. The scheduled tasks feature itself is present in the current feature list, with history and output, but automatic monitoring and recovery of those jobs is explicitly a roadmap item. So the current product creates and manages recurring Hermes jobs; it does not yet watch them for you.

A second boundary is the human-in-the-loop design. Nothing moves to done without your sign-off. That is a deliberate constraint and it is the right default for delegated work, but it means Minions does not remove you from the loop. It organises the loop. If your goal is fully unattended operation, this is friction by design.

How Minions differs from running Hermes directly or building your own board

The realistic alternative is not another Kanban product. It is the terminal, or a hand-rolled wrapper around Hermes sessions.

The terminal approach means tracking sessions yourself: one shell per job, scrollback as your audit log, and no shared notion of status across projects. It costs nothing and requires no new dependency, and for two or three short tasks it is genuinely better than standing up a server.

A custom wrapper gives you exactly the fields you care about, at the price of writing the session plumbing, the streaming UI and the review flow yourself. Minions bundles all three, plus a file browser for files agents created in the workspace directory, live streaming of tool calls, reasoning and responses, and per-task model overrides. The trade is that you inherit its data model: task metadata in SQLite under ~/.minions/, transcripts in Hermes's session database, and a board whose status vocabulary is fixed to in progress, in review and done.

There is also a hosted option on Agent37, which the README mentions alongside the local-first path. The local path is the one the Quick Start documents in full, and it is the one that keeps your data on your machine.

Licence, upgrade mechanics and the cost of staying current

Minions is MIT licensed, and the LICENSE file sits at the repository root. MIT is permissive: you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and permission notice are preserved. That is a general description of the licence text, not legal advice for your situation.

Upgrade cost is low by construction. The package is published to npm as minionsai, so upgrading is a matter of re-running the npx command or installing a pinned version. The README gives the version-check pair shown above, and the Settings page shows the running server version, which is the check that catches a stale server process.

The maintenance picture from the repository facts: the last push to main was on 2026-08-15, and the most recent tagged release is v0.1.24 from 2026-07-24. The repository is not archived. The published package.json carries version 0.1.27, which is ahead of the latest tag, so the tag list in the repository does not reflect every published build. If you pin versions, verify against npm rather than the release list.

Runtime cost is the part the README does not quantify. Minions runs an Express server, a Vite-built client and a Python worker alongside Hermes itself, with HERMES_AGENT_RUN_LIMIT defaulting to 10 concurrent agent runs. Ten concurrent autonomous agent runs is a real resource commitment, and the documentation is silent on the memory or token implications of that default.

Editorial conclusion

Adopt Minions if you already run Hermes Agent and lose track of long-running sessions; the Kanban board, review queue and per-task model overrides address that directly, and the MIT licence plus SQLite storage keep the exit cost low. Skip it if your agents are not Hermes, because the README states launch is Hermes-only and OpenClaw support is still on the roadmap. Before installing, confirm your Node version satisfies the package.json engine field of >=20 rather than the README's Node.js 18+, and check that HERMES_AGENT_DIR in .env.example matches where your Hermes install actually lives.

Frequently asked questions

Official sources

1. agent37-platform/minions on GitHub
2. Issues
3. License: MIT
4. README
5. Releases