Hermes Agent Control Room: a documentation-first template for running Hermes agents

The problem: agents accumulate faster than their documentation

One Hermes agent on a VPS is easy to hold in your head. You know the port, the env file, the SSH alias and where the backup script lives. Add a second and third agent with different roles and the knowledge splits: an SEO agent with its own credentials, a dev agent with Docker access, an ops agent that touches the firewall. Nothing is wrong with any individual agent. What breaks down is the shared context around them.

The repository targets exactly that gap. Its README describes the Agent Control Room as a sidecar repo or folder that documents and governs your Hermes agents, and states that it is not an agent itself. The audience is the operator who runs agents on a VPS and wants a registry, a runbook library and a recovery notebook rather than another bot. The stated growth path is one agent, then direct specialists, then an orchestrator, then an automated agent team, with the Control Room created first and agents plugged in afterwards.

Control plane, task bus and orchestrator: how the pieces connect

The architecture is three separate things that are easy to conflate. The Control Room is a folder of documents and rules, shown in the README as living at /root/agent-control-room. The orchestrator, named hermes-orchestrator, is an optional front-door agent that delegates and synthesizes. The task bus, shown at /srv/agent-bus, is the handoff desk between them, with inbox, working, outbox and archive directories.

The README's flow diagram makes the direction of authority explicit: the Control Room defines, documents and governs the orchestrator and every specialist, while the orchestrator routes tasks onto the bus and specialists return results to it. The operator keeps three access paths at all times. You can edit the Control Room directly, talk to a specialist such as hermes-seo or hermes-dev directly, or go through the orchestrator. That last point is the design's best decision: the orchestrator is a convenience, not a gatekeeper, and the README warns that it should not become a giant agent holding every credential.

The bus itself is directory-based rather than a message broker. Tasks and results move as files through the four folders, using the agents.yaml registry and the task and result templates under templates/task-bus/. That is a deliberate low-tech choice. It works over SSH and survives restarts, but it also means there is no queue depth metric, no retry counter and no dead-letter handling documented in the README.

Installing the template and registering your first agent

The repository has no installer and no package to publish. Setup means getting the repo onto the VPS that will host the control plane and letting an agent or yourself work through docs/starter-guide.md. The README's Option A is to point an agent at the repo with a prompt, which is the intended path for the bundled skills.

The README does not give a clone command, so use whatever way you normally get a repository onto the server. What it does tell you is where the Control Room should end up, /root/agent-control-room, and which file to read first. The README's suggested prompt to an agent is:

Read this repo and help me set up an Agent Control Room.
Start with docs/starter-guide.md and the setup-control-room skill.

The second path is the skills route. The repository ships eight skills under skills/, including setup-control-room, agent-control-room and agent-registry-manager. The README says these can be linked into Claude Code or adapted for Hermes, and that setup-control-room bootstraps an SSH-accessible VPS with Node, Claude Code, Codex, Docker, Hermes Agent and this Control Room template. If your agent can see the skills, the README's suggested prompt is to use setup-control-room directly.

Once the folder structure exists, register one agent before adding anything else. The registry lives under agents/, and the per-agent documents come from templates/agent/, which the README lists as inventory.md, docker.md, env-map.md, runbook.md and backup.md. Copy the ones you need into a folder named for the agent, following the README's own naming, for example hermes-life. What you should see afterwards is a documented agent rather than a running one. Filling in inventory.md records what the agent is and where it lives; env-map.md records which environment variables it needs without storing the values; runbook.md records how to start, stop and recover it. That is Level 1 in the README's terminology, and it explicitly says you do not need an orchestrator or task bus yet.

Where the template stops and you have to decide

The honest limitation is that this repository governs agents without managing them. There is no daemon, no supervisor, no health check and no CLI in the top-level entries, which are .gitignore, LICENSE, README.md, agents/, assets/, docs/, examples/, shared/, skills/ and templates/. Everything that actually runs an agent comes from elsewhere: Docker, from the docker-compose files under templates/docker/, and whatever process manager you already use on the VPS.

That has a practical consequence. If an agent stops responding at 3am, the Control Room tells you where to look and what the recovery steps were meant to be, but it does not restart anything. The README frames the Control Room as the recovery notebook, and a notebook is exactly what it is. Teams that expect the template to enforce that every agent has a runbook will be disappointed; nothing checks that agents/ entries are complete, and the registry is only as current as the operator keeps it.

There is also a sequencing rule that is easy to violate. The README repeats it twice: add automation only after the manual workflow works, and plan recurring multi-agent workflows only after manual workflows work. Level 4 is where recurring workflows, audits and backup checks arrive, and the agent-team-cron-planner skill exists to plan them. Automating before the manual path is stable means your scheduled jobs inherit an undocumented system.

How it differs from a general agent framework

The closest comparison is a general agent framework or orchestration library, such as a LangGraph-style graph runtime. Those give you a runtime: you define nodes, state and edges in code, and the library executes the graph. Here you get a folder convention and a set of documents, and the execution stays with Hermes and Docker. The difference matters when something fails. In a graph runtime the failure surfaces as an exception in your process; in the Control Room model it surfaces as a task file sitting in the working directory of /srv/agent-bus with no result written back.

A second comparison is a plain infrastructure-as-code repository, an Ansible or Terraform layout that provisions servers. Those encode machine state and can be applied repeatedly to converge a host. The Control Room encodes human knowledge: naming rules, secret placement, runbook steps. It is not idempotent and cannot be applied, which is both its weakness and the reason it stays readable. If what you want is a reproducible VPS build, the create-vps skill is the part of this repository that touches provisioning, and the README describes it as creating a fresh Hetzner VPS, SSH key, SSH alias and local provisioning folder.

Maintenance, licence and what the repository does not promise

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. Nothing in the README discusses support, a release cadence or backward compatibility, and there are no retrieved releases, so the template should be treated as a starting point you fork rather than a dependency you track. The last push to the default branch was on 2026-05-16.

Upgrade cost is mostly manual. There is no version pin and no migration guide, so if you have edited the files under agents/ and docs/ to match your own setup, pulling upstream changes means reconciling them by hand. The skills are the part most likely to need attention over time, since setup-control-room installs Node, Claude Code, Codex, Docker and Hermes Agent, and those are external tools with their own release cycles. The repository provides shared/commands.md as a place to record the commands you used, which is the cheapest way to make a later rebuild predictable.

Editorial conclusion

Adopt it if you already run, or plan to run, more than one Hermes agent on a VPS and you are tired of keeping ports, secrets and runbooks in your head. Skip it if you have a single agent, no SSH-accessible server, or you want a runtime that starts and supervises agents for you: this repository is documentation and templates, and the README states plainly that the Control Room is not an agent itself. Before you commit, read docs/starter-guide.md and the setup-control-room skill end to end, and confirm that the folder layout under templates/agent/ matches the way you actually store secrets and backups.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. shannhk/hermes-agent-control-room on GitHub