Hermes Agent Control Room: a documentation-first template for multi-agent VPS setups
Control Room-first template for managing Hermes agents from one VPS agent to specialist teams and orchestrated workflows
At a glance
- What is it?
- This repository is a sidecar control-plane template, not an agent runtime. It supplies folder layout, runbooks, a task bus pattern and eight bundled skills so that a single Hermes agent on a VPS can grow into specialist teams without losing track of ports, secrets and ownership.
- Who is it for?
- Adopt this if you already run, or plan to run, more than one Hermes agent on a VPS and you are currently tracking ports, environment variables and credentials in your head or in scattered notes. Do not adopt it if you want an agent framework, a scheduler or a message broker: the repository is documentation, templates and skills, and the task bus is a directory convention rather than running software.
- 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 122 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is not the agents, it is the missing control plane
Running one Hermes agent on a VPS is easy to reason about. Running five is not, because the knowledge that makes them work lives in places that do not travel: which port each dashboard binds, which environment file holds which key, which container maps to which volume, what to do when one of them stops responding. The README frames the Control Room as a sidecar repo or folder that documents and governs your agents, and states plainly that it is not an agent itself. That distinction is the whole point. It is the system map, the operating manual, the registry, the runbook library and the recovery notebook. The intended audience is an operator with SSH access to a VPS who is willing to write things down before adding another bot. If you want something that spawns agents for you, this is the wrong repository, and the README says so by describing the Control Room as sitting on the side rather than in the request path.
Four levels, and the ordering rule that holds them together
The architecture is staged rather than modular. Level 1 is the Control Room plus one agent, with no orchestrator and no task bus. Level 2 adds direct specialists such as hermes-life, hermes-seo, hermes-dev, hermes-cmo and hermes-ops, and you choose which one to talk to. Level 3 introduces hermes-orchestrator as an optional front door that routes and synthesizes work. Level 4 adds recurring workflows, audits, backup checks and task routing. The sequencing is stated as a rule, not a suggestion: automate only after the manual system works. The README also warns that the orchestrator should not become a giant agent holding every credential, which is the failure mode this staging is designed to prevent. One deliberate property worth noting: the three access paths (control, direct, orchestrated) coexist. Adding an orchestrator does not remove your ability to SSH in and talk to hermes-dev directly, which keeps the orchestrator from becoming a single point of failure for routine work.
The task bus is a directory convention, not a broker
The mechanism for orchestrator-to-specialist delegation is a shared filesystem layout under /srv/agent-bus with inbox, working, outbox and archive. The diagram shows the orchestrator writing tasks to the bus, specialists reading from it, results flowing back, and the orchestrator returning a final synthesis to you. The repository ships templates/task-bus/agents.yaml, task-template.md and result-template.md, so the contract between agents is expressed as files in known directories. The README does not describe a daemon, a queue service or a delivery guarantee, and none is visible in the folder structure. That means durability, retries, ordering and concurrency are your problem, and the practical limit is roughly how many tasks a human operator can watch move between four directories. For a small team of agents on one VPS this is a reasonable trade: no extra service to run, no new port to expose, and the whole handoff history is greppable. For anything with real throughput it is the wrong tool, and you would replace it with an actual queue while keeping the Control Room docs.
What is actually in the repository
The layout is the deliverable. agents/ holds a .gitkeep for per-agent folders. docs/ carries architecture.md, levels.md, naming.md, security.md, task-bus.md, orchestrator.md and starter-guide.md. shared/ holds api-keys-sop.md, commands.md and security.md. templates/agent/ provides inventory.md, docker.md, env-map.md, runbook.md and backup.md, one set per agent. templates/docker/ provides docker-compose.agent.yml and docker-compose.orchestrator.yml as starting points rather than finished stacks. examples/ mirrors the four levels as level-1-control-room-one-agent through level-4-automated-team. Eight skills ship alongside: create-vps, setup-control-room, agent-control-room, agent-task-router, agent-registry-manager, agent-backup-manager, agent-security-auditor and agent-team-cron-planner. The README describes them as linkable into Claude Code or adaptable for Hermes. Note that the README is the specification here. There is no released artifact, no changelog and no version tag in the supplied material, so anything you build on it you are building on the current main branch.
Getting from a bare VPS to a registered agent
The README gives three entry points. Option A is to point an existing agent at the repository and ask it to read the repo and help set up an Agent Control Room, starting with docs/starter-guide.md and the setup-control-room skill. If the bundled skills are available to the agent, the README suggests invoking setup-control-room directly. The skill is described as bootstrapping an SSH-accessible VPS with Node, Claude Code, Codex, Docker, Hermes Agent and the Control Room template; a separate create-vps skill handles a fresh Hetzner VPS, SSH key, SSH alias and local provisioning folder. The Control Room itself is expected to live at /root/agent-control-room and the bus at /srv/agent-bus, per the system diagram. The supplied README is truncated inside the Option A example, so the remaining options and the exact command lines are not in the material I have. Treat the skill descriptions as the contract and read the skills themselves before running them, since the versions of Node, Docker and Hermes they install are not stated here.
Where this template will not save you
Three honest limitations. First, it is Shell and Markdown. Nothing validates that your env-map.md matches the environment your container actually receives; drift between documentation and reality is exactly the problem the Control Room is meant to catch, and the repository does not appear to include a check for it. Second, the skills are written for a specific toolchain (Claude Code, Codex, Hermes Agent) and the README only claims they can be adapted for Hermes, so a different agent runtime means rewriting the parts that matter. Third, there is no upgrade path described. The repository is a template you copy, which means upstream fixes do not reach you unless you diff your copy against main by hand. If you want something that manages agent lifecycle for you out of the box, this is the wrong tool, and the README's own framing (a sidecar, not an agent) is the clearest signal of that.
How it differs from Docker Compose plus a README
The obvious alternative is a docker-compose.yml with five services and a README at the repository root. That gets your agents running and it is less work up front. The difference is what each artifact is for. Compose describes processes; the Control Room describes agents, with per-agent inventory, docker notes, env maps, runbooks and backup plans as separate files under templates/agent/. The env-map.md and backup.md templates force you to answer questions that Compose does not ask, such as where a given key lives and what a restore looks like. The task bus adds a second difference: a shared directory contract under /srv/agent-bus that an orchestrator and specialists both read, which plain Compose does not address at all. The trade is real. You maintain more files, and those files can go stale. If your setup is one agent and one container, Compose alone is the better answer, and the README's Level 1 is essentially that with documentation attached.
Licence, maintenance and what to check before you copy it
The repository is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement, and it means you can fold the templates into a private operations repository. It is not legal advice; read the LICENSE file in your clone. On maintenance: the last push recorded is 2026-05-16 and no releases were retrieved, so there is no versioned artifact to pin. Because the repository is a template rather than a dependency, upgrades are manual diffs, and the cost of staying current is the cost of re-reading docs/ and templates/ whenever you choose to sync. The practical check before adopting is to open templates/agent/env-map.md and templates/agent/backup.md and confirm they have a field for every secret and every volume your current agents use. If they do not, you will be extending the templates on day one, which is fine, but it should be a decision rather than a surprise.
Editorial conclusion
Adopt this if you already run, or plan to run, more than one Hermes agent on a VPS and you are currently tracking ports, environment variables and credentials in your head or in scattered notes. Do not adopt it if you want an agent framework, a scheduler or a message broker: the repository is documentation, templates and skills, and the task bus is a directory convention rather than running software. Before committing, verify three things in your own clone: that docs/task-bus.md matches how you actually want to hand work between agents, that templates/agent/env-map.md has a field for every secret your agents already use, and that the setup-control-room skill provisions the Node, Docker and Hermes versions you intend to run.
Community notes