Setting up Hermes Agent: a working guide

The official quickstart gets Hermes running in about sixty seconds. This guide covers the same ground plus the decisions the quickstart skips — where it should run, what to point it at, and how to stop it doing something expensive while you are still learning what it does.

Commands below are from the official installation docs. Check them there before running anything; installer URLs change and this page will age.

Decide where it runs first

Do this before installing, because it is annoying to change later.

Where	Good for	Catch
Your machine	Learning, experimenting	Stops when the machine does. Not for anything scheduled
Small VPS	Anything real	You now own a server. Patch it
Docker	Containment, easy reset	One more layer when debugging
Hermes Cloud	Not running infrastructure	Subscription, and your traffic goes through it

Install locally first to learn the tool. Move to a VPS or Hermes Cloud the moment you want anything to happen on a schedule. An agent that only runs when your laptop is open cannot be trusted with a Monday morning job.

Prerequisites

The installer pulls in uv, Python 3.11, Node.js v22, ripgrep and ffmpeg on its own. You need Git already present. On Linux also ensure curl and xz-utils are available; for the desktop app add build tools (g++ or build-essential).

Install

Linux, macOS, WSL2, or Android via Termux:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Windows, natively, in PowerShell:

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

On macOS or Windows you can instead download the Hermes Desktop installer, which is the easier route if you would rather not think about shells.

Both commands pipe a remote script straight into an interpreter. That is normal for this class of tool and it is still worth understanding: you are trusting that domain completely. If you would rather look first, fetch the script to a file, read it, then run it.

Then reload your shell and start it:

source ~/.bashrc
hermes

Per-user installs put the code in ~/.hermes/hermes-agent/ with the binary at ~/.local/bin/hermes. Root installs use /usr/local/lib/hermes-agent/ and /usr/local/bin/hermes. Prefer the per-user install unless you have a specific reason not to.

Point it at a model

hermes model

Hermes works with Nous Portal, OpenRouter, OpenAI, or a custom endpoint. If you are using Nous Portal, there is a single-command path that also wires up the tool gateway:

hermes setup --portal

Start on a cheap model. You are about to discover that your first instructions were ambiguous, and you will discover it several times. Doing that on an expensive model is a bad trade. Move up only once the task is stable and you have a reason.

Turn most tools off

hermes tools

Hermes ships 60+ built-in tools, plus MCP servers if you add them. The instinct is to enable everything. Resist it, for two reasons.

The first is safety: every enabled tool is something the agent can do at three in the morning without asking. The second is quality — as covered in the harness piece, a large tool list is a menu the model reads badly. Twelve well-chosen tools produce better behaviour than sixty.

Enable what the current task needs. Add more when a task actually requires it.

Load-bearing

Before connecting any messaging platform, create separate accounts for the agent with the narrowest access that works. Not your login. The agent should be a distinct identity you can audit and revoke in one action, without changing your own password.

Connect a messaging platform

hermes gateway setup

This wires Hermes into Telegram, Discord, Slack, WhatsApp and others — 20+ platforms in total. For a business this is the step that makes the agent usable by people who will never open a terminal.

Start with an internal channel nobody outside the business can post to. A customer-facing channel means strangers are writing text your agent reads, which is a prompt-injection surface, not just a support inbox. Earn that step; do not start with it.

Schedule something

Hermes has built-in cron for scheduled automations. Your first scheduled job should be the harmless one — a weekly summary posted to your own channel. Let it run for a fortnight before it is responsible for anything.

A sane first week

Day 1. Install locally. Cheap model. Talk to it in the terminal. Get a feel for it.
Day 2. Enable a small tool set — web search and file access is plenty.
Day 3. Give it one real read-only task. Correct it until the output is genuinely useful.
Day 4. Move it to a VPS or Hermes Cloud so it survives a reboot.
Day 5. Connect one internal channel. Let the team talk to it.
Week 2. Schedule the weekly summary. Read what it produces. Change nothing else.

Things worth knowing before they surprise you

It creates skills from experience. That means it is learning from how you correct it. Early sloppiness gets crystallised, so be precise while it is forming habits.
Community skills are third-party code. agentskills.io is useful and it is also someone else's instructions running in your agent. Read before installing, exactly as you would an npm package.
MCP servers extend the blast radius. Everything in the MCP piece about untrusted tool descriptions applies directly here.
Check your inference bill on day two. Not day thirty. A misconfigured loop is much cheaper to find early.

Once it is running, what to automate first covers which jobs to hand over, in order of how little damage they do when it gets them wrong.