Hermes Agent Guide
Hermes Agent Harness: The Runtime Around the Model
A model on its own only returns text. The harness is what lets it run a command, remember you next week, ask before deleting something, and answer on Telegram at 3 AM. This guide explains what that means in Hermes Agent, which parts you configure, and how to set up a harness that is safe to leave running.
What “agent harness” means
People use “harness” for the code that sits between a language model and the real world. The model decides what to do next; the harness actually does it, checks whether it is allowed, and feeds the result back. A good harness is why the same model can be a toy in one app and a dependable assistant in another.
In practice a harness has a few jobs:
- Run the loop. Send the conversation and tool definitions to the model, execute the tool calls it returns, append the results, repeat until it answers.
- Give it hands. A terminal, file access, web search, a browser, MCP servers.
- Decide where those hands work. Your own shell, a container, a remote machine.
- Keep a human in the loop for anything destructive.
- Remember. Carry facts and procedures from one session to the next.
- Stay reachable. Keep running and accept messages from wherever you are.
Which harness page do you need?
- The whole Hermes runtime: this page.
- Browser control inside Hermes: Hermes Agent browser harness.
- The same idea for OpenClaw: OpenClaw as an agent harness.
- The npm package called DeepSeek Harness: DeepSeek Harness install. That is a separate coding tool, not part of Hermes.
How Hermes maps to each part
Hermes Agent from Nous Research does not need a separate harness. Every piece ships in the same install and is configured in ~/.hermes/config.yaml:
| Harness job | In Hermes | Where it lives |
|---|---|---|
| Agent loop | The Hermes agent core, with any supported model provider | model: in config.yaml, set with hermes model |
| Tools | terminal, file tools, web search, browser, execute_code, delegation, MCP servers | platform_toolsets: and mcp_servers: |
| Execution environment | Terminal backend: local, Docker, SSH, Singularity, Modal, Daytona | terminal.backend |
| Safety | Dangerous-command approvals, deny rules, a hardline blocklist | approvals: |
| Memory | MEMORY.md and USER.md, plus session search | ~/.hermes/memories/ |
| Procedures | Skills, including ones the agent writes for itself | ~/.hermes/skills/ |
| Reachability | The messaging gateway, cron jobs | hermes gateway |
The gateway: the part that makes it always on
Running hermes in a terminal gives you an interactive session that ends when you close the window. The gateway is the long-lived process that connects the same agent to Telegram, Discord, Slack, WhatsApp and other platforms, runs scheduled cron jobs, and routes approval prompts to your chat. It is what turns Hermes from a CLI tool into an assistant you can message from your phone.
hermes gateway setup # pick platforms, paste bot tokens
hermes gateway install # run it as a background service
hermes gateway status
hermes gateway restart # after config changes that need itKeep the gateway on a machine that stays awake. A laptop that sleeps takes the bot, its cron jobs and any pending approvals offline with it.
Terminal backends: where commands actually run
The terminal tool is the most powerful thing in the harness, so where it runs matters most. Hermes lets you swap the execution environment without changing anything else:
hermes config set terminal.backend docker
hermes config set terminal.backend ssh
hermes config set terminal.backend local # the default| Backend | Commands run | Good for |
|---|---|---|
local | Directly on the machine running Hermes | Quick trials, a dedicated VM you do not mind the agent changing |
docker | In one long-lived container shared across the session | Everyday use on a personal machine; installs and files persist between tool calls |
ssh | On a remote server, while Hermes stays local | Keeping the agent away from its own code and config; using bigger hardware |
singularity | In an Apptainer container | HPC clusters |
modal / daytona | In a cloud sandbox | GPUs, disposable environments |
A minimal Docker setup looks like this:
terminal:
backend: docker
cwd: /workspace
docker_image: nousresearch/hermes-sandbox:desktop
container_memory: 5120 # MB
container_persistent: true # keep /workspace across restartsTwo Docker details are easy to miss. Your launch directory is not mounted into the container unless you set docker_mount_cwd_to_workspace: true, and host environment variables are not passed in unless you list them under docker_forward_env. Both are off on purpose. Anything you forward is readable by every command the agent runs. For SSH, the host, user and key go in ~/.hermes/.env as TERMINAL_SSH_HOST, TERMINAL_SSH_USER and TERMINAL_SSH_KEY. More on containers in Hermes Agent + Docker.
Approvals: the human in the loop
Hermes checks shell commands against a list of dangerous patterns before running them. What happens next depends on approvals.mode:
approvals:
mode: smart # smart | manual | off
timeout: 300 # seconds to wait for your answer
cron_mode: deny # what cron jobs do on a dangerous commandsmart(default): an auxiliary model auto-approves clearly low-risk commands, auto-denies clearly dangerous ones, and asks you about the uncertain middle.manual: always asks.off: never asks, the same as starting with--yoloor typing/yolo.
Through the gateway, the prompt arrives in your chat and you reply /approve or /deny. Sessions with nobody to answer (cron jobs, one-shot hermes chat -q runs, webhook and API sessions) deny by default, so the agent has to find another way instead of hanging. Under all of this sits a hardline blocklist of unrecoverable commands that even YOLO cannot bypass, and approvals.deny lets you add your own glob patterns that are always blocked.
Approvals and backends work together. off inside a disposable container is a reasonable choice for automation; off with the local backend on your main machine is not.
Skills and memory: what makes it improve
A harness that forgets everything is only as good as the prompt you type each time. Hermes keeps two kinds of state between sessions:
- Memory.
MEMORY.mdholds the agent’s notes about your environment and conventions;USER.mdholds your preferences. Both are small, capped files the agent edits with itsmemorytool and loads at the start of each session. See Hermes Agent memory. - Skills. Folders with a
SKILL.mdthat describe how to do a specific job. Hermes loads them only when relevant, installs them from the hub, and can write new ones itself after it works something out. They live in~/.hermes/skills/, andskills.external_dirscan point at a shared folder. See Hermes Agent skills.
Do not point two Hermes processes at the same home directory. Both would write memory and skills into the same files. Use a separate profile for each agent.
A practical setup checklist
- Install Hermes and pick a model with
hermes model. The setup guide walks through it. - Choose a backend before you give the agent real work:
dockeron a personal machine,sshfor a separate work box. - Leave
approvals.modeonsmartor setmanual. Addapprovals.denyrules for anything that must never run. - Forward only the environment variables the agent actually needs.
- Run
hermes gateway setup, connect one platform, and restrict who can talk to the bot with its pairing or allowlist settings. - Install the gateway as a service on a machine that stays on.
- Add MCP servers and skills once the basics work, not before. Each one adds tools the model has to reason about.
When a managed harness makes sense
Self-hosting gives you full control, but you also have to keep it running: the gateway process, container limits, updates, backups, and a machine that never sleeps. That is the part OpenClaw Launch takes over. Each Hermes bot runs in its own isolated container on our servers, the gateway stays online, and you connect Telegram, Discord or other platforms, change models and open a web terminal or file browser from the dashboard. OpenClaw bots are hosted the same way if you would rather use that framework.
A managed bot still uses the same Hermes harness described above. You get the same tools, memory, skills and approvals, without running the server yourself. If you need the SSH backend pointed at your own hardware or a custom sandbox image, self-hosting is still the better fit.
Hermes Agent harness FAQ
What is an agent harness in Hermes Agent?
It is everything around the model that turns a chat completion into an agent: the loop that calls tools and feeds results back, the terminal and file tools with their execution backend, persistent memory in ~/.hermes/memories/, skills in ~/.hermes/skills/, the dangerous-command approval layer, and the gateway that connects the agent to Telegram, Discord, Slack and other platforms. Hermes ships all of these as one program, so Hermes itself is the harness.
Is the Hermes harness the same as the browser harness?
No. The browser harness is one tool inside it: how Hermes drives a real browser for clicking, filling forms and reading pages. That is covered in Hermes Agent browser harness. This page is about the whole runtime the browser tool plugs into.
Which terminal backend should I use for Hermes?
Upstream supports local (the default), docker, ssh, singularity, modal and daytona, set with hermes config set terminal.backend <name>. On your own laptop, docker is the safer everyday choice because commands run in a container instead of your home directory. The Hermes docs recommend ssh when you want the agent unable to modify its own code. Local is fine for quick trials on a machine you do not mind the agent touching.
How do approvals work in Hermes Agent?
Dangerous shell commands go through approvals.mode in ~/.hermes/config.yaml. The default smart uses an auxiliary model to auto-approve clearly low-risk commands, auto-deny clearly dangerous ones and ask you about the rest; manual always asks; off is the same as --yolo. On a chat platform you answer with /approve or /deny. Cron, one-shot and webhook sessions deny by default because nobody is there to answer, and a hardline blocklist applies even under YOLO.
Do I need a managed harness like OpenClaw Launch?
Not if you are happy running a server. Hermes is open source and the harness works fully self-hosted. A managed host is worth it when you want the gateway online 24/7 without keeping a machine awake, each bot isolated in its own container, and platform connections, model changes and backups handled from a dashboard. OpenClaw Launch does that for Hermes and OpenClaw.