To use Hermes as an orchestrator for Claude Code, run Hermes as the always-on layer that holds your memory, schedule, and channels, and hand execution-heavy work to Claude Code through short delegation briefs with explicit done-criteria and verification gates. Hermes plans, remembers, and reports. Claude Code reads the repo, writes the code, and runs the checks. The split works because each tool is kept where it is strong, and the discipline that connects them is written down, not improvised per session.
One honest note before the method. I run a consulting and build practice on this stack, plus a small production SaaS. Client deliverables, site builds, research, back-office routines: the stack does real billable work every day. Nothing below is a thought experiment, and nothing below requires a big operation to copy. It requires the discipline more than the tooling.
What is Hermes? Hermes is an open-source, MIT-licensed AI agent from Nous Research. It connects any capable model to messaging platforms like Telegram, Discord, and Slack, runs on local machines, Docker, or a VPS, schedules recurring work with cron, and keeps persistent memory across sessions, with a built-in learning loop that turns experience into reusable skills. It also ships a first-party skill for delegating coding work to the Claude Code CLI, which is the seam this whole guide is built on.
Why put an orchestrator above Claude Code at all?
The most common question in the Hermes community is some version of: what does this do that Claude Code alone cannot? Fair question, because for a single coding session the answer is nothing. The orchestrator earns its place the moment your work stops fitting inside one session:
- It is always on. On a VPS, Hermes works while your laptop is closed. Scheduled routines run at 6am, a build kicked off from your phone finishes while you are at dinner, and the completion ping arrives either way.
- It remembers. Claude Code starts each session from the repo plus whatever context files you maintain. Hermes carries durable memory across every session and channel: who your clients are, what was decided last week, which approach failed before and why.
- It reaches you where you are. A messaging gateway turns your phone into the command line. Assign work, answer the one fork question that needs you, and approve the result without opening a terminal.
- It holds the queue. One layer owns what should happen next across many projects. Individual Claude Code sessions execute one card at a time; the orchestrator sequences them.
If none of those apply, you do not need an orchestrator yet. Close this tab and keep shipping. If two or more apply, the rest of this guide is the operating manual.
What does the stack actually look like?
Four roles, each held by the simplest thing that can hold it:
| Role | Held by | What it does |
|---|---|---|
| Orchestrator | Hermes (always-on) | Plans, sequences, remembers, schedules, reports to your channel |
| Execution engine | Claude Code | Reads the repo, writes code and content, runs builds and tests |
| Work queue | A markdown kanban board in the repo | Single source of truth for what is Ready, In flight, Blocked, Done |
| Source of truth | Durable memory files | Who you are, what the business is, hard rules, decisions and their reasons |
The two unglamorous rows are the ones that compound. The board and the memory files are plain markdown in version control, readable by every agent and every human, no database, no SaaS dependency. When people show off their agent stacks they screenshot the messaging gateway. The board and the memory files are where the leverage lives.
How do you delegate work from Hermes to Claude Code?
The bundled claude-code skill gives Hermes two modes, and picking the right one per task is most of the craft:
- Print mode runs a one-shot task and exits. No terminal session to manage, output captured cleanly. This is the default for anything you can specify up front: implement this card, write this draft, run this migration against staging.
- Interactive mode keeps a live session in tmux that Hermes can send follow-ups to and read output from. Reserve it for genuinely exploratory work, because a supervised session multiplies cost and attention.
Either way, the handoff artifact is a delegation brief, and its shape matters more than its length: the objective in one sentence, why it matters, the done-criteria the work will be verified against, and the boundaries. The unit of delegated work is a board card, one coherent outcome, small enough to verify in one review. Vague cards produce vague pull requests.
The rule that keeps the whole loop honest: the worker never grades its own homework unchecked. Every brief includes done-criteria that are mechanically checkable, and the orchestrator confirms them from evidence: exit codes, test output, a diff, a live URL. An agent report that says it is done, without a green check attached, is treated as not done.
How do you route models so this does not get expensive?
An always-on orchestrator plus long-running coding sessions can burn real money if every token runs on the premium tier. The pattern that works is the one several practitioners have independently converged on: a smart controller directing cheaper workers.
- The orchestrator reads a lot and writes a little. Planning, judgment, and review are input-heavy and output-light, which is the cheap direction on every price sheet. This is where the capable model belongs.
- Workers are verbose. Code, drafts, and test output are output-heavy, which is the expensive direction. This is where the mid-tier model belongs, and where a fast cheap model handles the mechanical subtasks.
- Escalate on failure, not on anxiety. Route by task difficulty. When a cheap tier fails its own verification, bump the task up one tier automatically instead of shipping a bad result or defaulting everything to the top.
The dial that matters is the ratio: most volume on the cheap tiers, judgment on the capable one, and the top-tier model reserved for the genuinely hard calls. When we published our guide to prompting Claude Fable 5, the core of it was exactly this selection discipline.