← All Guides

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?

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 jobIn HermesWhere it lives
Agent loopThe Hermes agent core, with any supported model providermodel: in config.yaml, set with hermes model
Toolsterminal, file tools, web search, browser, execute_code, delegation, MCP serversplatform_toolsets: and mcp_servers:
Execution environmentTerminal backend: local, Docker, SSH, Singularity, Modal, Daytonaterminal.backend
SafetyDangerous-command approvals, deny rules, a hardline blocklistapprovals:
MemoryMEMORY.md and USER.md, plus session search~/.hermes/memories/
ProceduresSkills, including ones the agent writes for itself~/.hermes/skills/
ReachabilityThe messaging gateway, cron jobshermes 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 it

Keep 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
BackendCommands runGood for
localDirectly on the machine running HermesQuick trials, a dedicated VM you do not mind the agent changing
dockerIn one long-lived container shared across the sessionEveryday use on a personal machine; installs and files persist between tool calls
sshOn a remote server, while Hermes stays localKeeping the agent away from its own code and config; using bigger hardware
singularityIn an Apptainer containerHPC clusters
modal / daytonaIn a cloud sandboxGPUs, 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 restarts

Two 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 command
  • smart (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 --yolo or 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.md holds the agent’s notes about your environment and conventions; USER.md holds your preferences. Both are small, capped files the agent edits with its memory tool and loads at the start of each session. See Hermes Agent memory.
  • Skills. Folders with a SKILL.md that 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/, and skills.external_dirs can 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

  1. Install Hermes and pick a model with hermes model. The setup guide walks through it.
  2. Choose a backend before you give the agent real work: docker on a personal machine, ssh for a separate work box.
  3. Leave approvals.mode on smart or set manual. Add approvals.deny rules for anything that must never run.
  4. Forward only the environment variables the agent actually needs.
  5. Run hermes gateway setup, connect one platform, and restrict who can talk to the bot with its pairing or allowlist settings.
  6. Install the gateway as a service on a machine that stays on.
  7. 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.

Related guides

Get a managed Hermes harness

OpenClaw Launch runs Hermes Agent in its own container with the gateway always on, platforms connected from the dashboard, and your choice of model. No server to maintain.

Deploy Managed Hermes