Stop Following Outdated Tutorials: The Most Stable 10-Step Guide to Hermes AI Agent (v0.13.0)

Core question of this section: Why do so many Hermes tutorials fail to work? And what should a proper beginner’s guide for v0.13.0 look like?

Writing yet another “from scratch” tutorial for a tool that’s been around for a while feels like chasing old hype. But after reviewing several older guides and walking through the latest v0.13.0 release myself, I realised this article is necessary.

The biggest enemy of tools like Hermes isn’t complexity—it’s expired tutorials. An outdated guide is worse than no guide at all, because most of it still appears correct. The installation commands might work, providers can be configured, and the CLI might even chat with you. So you’re likely to blame yourself. But the new version has pushed many features toward production readiness: durable multi-agent Kanban, /goal, checkpoints v2, Gateway auto-resume sessions, no_agent cron, Google Chat, providers plugin, Curator for skill maintenance, and stricter security defaults.

The problem is subtle. Old tutorials focus on “getting it running”, while Hermes today needs to be nurtured. The former means installing, picking a model, and sending your first message. The latter means managing memory, skills, messaging channels, task scheduling, profile boundaries, and automation. Get the order wrong, and you’ll experience the classic beginner nightmare: the tool looks powerful, but you’re staring at a screen checking tokens, allowlists, base URLs, and profile statuses.

Especially dangerous are articles that promise a “24/7 agent army” on day one. They sound exciting—auto-reply, auto-write, auto-post, multi-platform orchestration, internal dashboard, task board, long-term memory—all laid out as if you could stuff an entire company into your computer tomorrow.

I strongly advise against doing this on your first day. One wrong bot token, one incorrect profile switch, one mistyped local model endpoint, and half your day is gone.

So this is still a beginner’s guide, but not the “copy-paste this command” kind. I want to present a slower, safer order: starting from zero, nurturing a single Hermes instance until it can talk reliably, use tools, resume sessions, and understand what to remember and what not to. Once that foundation is solid, then add Gateway, Memory, Skills, Profiles, Cron, and Kanban.

First, make one Hermes work steadily.

What Exactly Is Hermes? – More Than a Model, It’s an Agent Runtime

Core question of this section: How is Hermes different from ordinary chat AI or the “Hermes model”? What can it actually do for you?

First, don’t confuse Hermes Agent with the Hermes model. They share a name, but they are not the same thing.

In my view, Hermes is an Agent runtime. The model is just the brain; Hermes manages everything around that brain: tools, conversations, memory, Skills, automation, chat integrations, multi‑agent profiles, and task boards.

A typical chat tool is like calling a temporary assistant—once the conversation ends, everything resets. Hermes is more like giving that assistant a permanent desk, complete with a notebook, SOPs, message portals, and a task board. You don’t need such a heavyweight setup for a quick explanation. But for tasks like curating daily news, tracking project updates, preserving preferences, running scheduled low‑risk jobs—that’s where Hermes shines.

Reflection: I used to think that installing Hermes and getting an API key meant I “knew how to use it”. After three days, I hit problems: sessions wouldn’t resume, tool calls failed arbitrarily, and the same question gave different answers across profiles. I later realised I lacked a proper SOP for moving from “it runs” to “it’s cultivated”.

Hermes concept illustration

Three Things NOT to Do on Day One – Avoid the Most Common Beginner Traps

Core question of this section: Which “advanced features” should beginners absolutely avoid touching at first, to save hours of debugging?

Beginners are easily tempted by “advanced” features. I’m no exception—multi‑platform Gateway, multiple profiles, Kanban scheduling—they all look exciting. But enabling everything on day one inflates your troubleshooting surface enormously.

  1. Do not connect multiple chat platforms at once
    Telegram, Discord, Slack, WhatsApp, Feishu – all are supported, but if any bot token, allowlist, home channel, or platform permission is misconfigured, Hermes will appear broken. Pick one (e.g., Telegram) and make it work first.

  2. Do not create multiple Profiles (multi‑agent) immediately
    Profiles are powerful, but each profile has its own config, secrets, memory, sessions, skills, cron jobs, gateway state, and database. Creating commander, coder, reviewer, and researcher all at once will multiply your debugging surface.

  3. Do not attempt local models on day one
    Local models are fun, but when you’re starting, base URLs, model names, OpenAI‑compatible endpoints, context length, and tool call stability will all hit you at once. First, use a stable cloud provider to establish a baseline, then connect Ollama or vLLM later. You’ll save yourself many wrong turns.

I follow this order:

Install Hermes
→ Choose a model provider
→ Get CLI / TUI conversations working
→ Verify session resume works
→ Configure SOUL / Memory
→ Use Skills
→ Connect Gateway
→ Create Profiles
→ Add Cron / Kanban / Docker
Order diagram

Step 1: Get the Version Up and Running – Installation & Basic Verification

Core question of this section: How do you correctly install Hermes on Windows, macOS, or Linux and confirm that the environment is ready?

Installation itself is straightforward. The official script works for macOS, Linux, and WSL2:

curl -fsSL https://get.hermes.org | bash

If you’re on Windows, you no longer need to go through WSL2 first. The official Windows Native Beta lets you install directly from PowerShell:

powershell -NoProfile -ExecutionPolicy Bypass -Command "iwr -useb https://get.hermes.org | iex"

To be clear: Windows native support is real, but it’s still beta. CLI, TUI, Gateway, Profiles, and Skills work natively on Windows. However, the Dashboard’s embedded terminal still leans toward WSL2 scenarios. If you just want to run Hermes on Windows, native installation is fine. For heavy development, long‑running automation, or complex local toolchains, WSL2 remains the more stable fallback.

After installation, reload your shell (or open a new PowerShell window):

source ~/.bashrc
# or
source ~/.zshrc

Immediately check the version:

hermes --version

Latest output looks like:

Hermes Agent v0.13.0 (2026.5.7)
Up to date

Don’t skip this. Hermes changes quickly; many “broken tutorials” aren’t wrong when they were written—they just aged.

If you plan to use it seriously, run doctor early:

hermes doctor

It’s not magic; it simply scans your environment, config, and dependencies. Way better than guessing from error messages.

I also run:

hermes --help

Not to memorise commands, but to get an overview. model, gateway, cron, kanban, skills, curator, memory, profile, dashboard, logs are all there. That list also tells you where Hermes’ focus lies today.

Help screenshot

Step 2: Connect a Model – Choose a Stable Provider

Core question of this section: Since Hermes is not a model itself, how do you configure a model provider that works reliably?

Hermes needs a provider. The most stable entry point is:

hermes model

Officially supported providers include Nous Portal, OpenRouter, OpenAI Codex, Anthropic, Kimi, Qwen, DeepSeek, Hugging Face, AWS Bedrock, GitHub Copilot, Vercel AI Gateway, and custom OpenAI‑compatible endpoints.

For your first time, don’t aim for the fanciest setup. Just get something working. My priority order:

  • If you have a stable API key → use it.
  • If you don’t know what to choose → OpenRouter or Nous Portal.
  • If you prefer domestic (China) models → Kimi / Qwen for simple tasks.
  • If you want local models → wait until CLI is working, then add Ollama / vLLM.

One hard requirement often overlooked: Hermes needs at least 64K context. Agents carry tools, history, memory, and task state. Small‑context models will lose track halfway.

After configuring the model, don’t jump to Telegram. First, confirm it can answer in the terminal:

hermes --tui

Or classic CLI:

hermes

For your first test, avoid philosophy or “write a big project.” Ask something that validates tool use:

Check the current directory and tell me the 5 files that look like the main project entry points, along with your reasoning.

Success criteria:

  • It knows its current provider and model.
  • It replies properly.
  • It can call file or terminal tools when needed.
  • A second round of conversation does not break.

Once this works, Hermes has a pulse.

Step 3: Verify Session Resume – The Dividing Line Between Agent and Chat

Core question of this section: How does Hermes remember previous conversations? How do you test that session recovery works correctly?

One of the biggest differences between an agent workbench and ordinary chat is the ability to continue where you left off. After a short conversation, exit and try:

hermes --continue

Or:

hermes -c

If it returns to the previous context, session basics are healthy. This will be used by long‑running tasks, multi‑agent scenarios, Gateway, and Cron.

If resume fails, check:

hermes sessions list

Many people think “memory is broken” when actually they switched profiles or the session wasn’t saved.

Reflection: I’ve seen many confuse “session resume” with “long‑term memory”. Session resume simply lets you pick up a previous conversation without losing history. Memory (in Hermes) is about learning your preferences and environment. Together, they create real continuity.

Step 4: Understand Hermes’ Configuration Files – Don’t Misplace Things

Core question of this section: Hermes has several configuration files; what is each responsible for? How do you avoid chaos?

Hermes configuration isn’t hard, but it’s easy to put things in the wrong place.

File path Purpose Example
~/.hermes/.env Secrets API keys, bot tokens, platform tokens
~/.hermes/config.yaml General config Default model, terminal backend, gateway, tool switches
~/.hermes/SOUL.md Stable personality & hard rules Verify before answering, warn about dangerous commands
~/.hermes/memories/MEMORY.md Agent’s working notes Environment facts, project habits, past pitfalls
~/.hermes/memories/USER.md User preferences Default language, conclusion‑first, avoid long rambling
Project root AGENTS.md Project‑level rules How to test, which directories not to touch, pre‑publish steps

The most common mistake is putting everything into MEMORY.md. I did that myself, and things got messy fast. Fixed rules belong in SOUL.md, project norms in AGENTS.md, changing environmental facts and working notes in MEMORY.md, and user preferences in USER.md.

A first‑version SOUL.md doesn’t need to be a corporate handbook. A few lines are enough:

# Hermes behavior rules

For uncertain commands, paths, or configs, check before answering.
For tasks requiring more than three steps, first list a plan.
For high‑risk actions, state the risks clearly; do not execute directly.
After completing a task, tell me how to verify.
Do not write temporary guesses into long‑term memory.

Don’t write a 2000‑word persona at the start. If you over‑specify, you won’t know which rule is actually affecting behaviour, and neither will Hermes.

Step 5: Memory and Skill Are Not the Same – Facts vs. Workflows

Core question of this section: How do you distinguish between “make the agent remember my preference” and “teach the agent a repeatable workflow”?

What makes Hermes interesting isn’t that it can “remember me” – it’s that it separates memory from process.

  • Memory records facts and preferences.
    Example: “In future AI tool roundups, keep product names, original links, and Markdown formatting.” This goes into Memory.

  • Skill records a repeatable SOP (Standard Operating Procedure).
    Example: “Each time you generate an AI tool daily brief: first fetch AI hot news, then scan X top tweets, then categorise into agent/coding/video/image/infra, and finally suggest 5 write‑worthy topics.” This becomes a Skill.

My rule of thumb: Memory = what it should know; Skill = how a class of tasks should be done.

Memory vs Skill

When training Hermes, shouting “remember this” endlessly is limited. Once a task runs smoothly, ask it to save a Skill directly:

We will reuse this workflow in the future. Please save it as a Skill, including trigger conditions, steps, caveats, and validation methods.

Then inspect:

hermes skills list

You can also search external skills:

hermes skills search github
hermes skills inspect <skill-name>
hermes skills install <skill-name>

The latest version also includes Curator. I like this: it manages agent‑created skills – merging duplicates, archiving outdated ones, pruning low‑quality ones.

hermes curator status
hermes curator run

It’s not a skill executioner. Bundled and hub‑installed skills are not automatically touched, and archived skills can be restored. Treat it as a skill‑library housekeeper, not a grim reaper.

Step 6: Connect Gateway – Bring Hermes into Your Chat App

Core question of this section: How do you connect Hermes to Telegram, Feishu, or other chat platforms and turn it into a “ready‑when‑you‑need” assistant?

After CLI is working, connect Gateway.

hermes gateway setup
hermes gateway run

For long‑running operation:

hermes gateway install
hermes gateway start
hermes gateway status

If you’re just testing locally, gateway run is more transparent – it runs in the foreground and shows errors directly. Once stable, install it as a background service.

When connecting a platform, pick just one. For personal use, Telegram or Discord is usually fastest. For team collaboration, Feishu is smoother. Exact platform list depends on the current hermes gateway setup menu – don’t blindly follow old tutorials.

Gateway success is not measured by whether the service started. It’s measured by whether you can send a message to Hermes from your chat app and get a reply.

First message can be simple:

Reply with one sentence confirming you are now connected via this chat platform.

Then a second message:

Remember that from now on, when I ask you to compile materials through this chat channel, default to Markdown output and keep original links.

Next day, ask a similar task in a different wording and see if it respects the preference. That’s how you test Gateway + Memory together.

Gateway illustration

Step 7: Profiles Are the Right Starting Point for Multi‑Agent

Core question of this section: How do you create multiple agents with different roles (e.g., one for coding, one for review)? What’s the difference between a Profile and a sandbox?

When people say “multi‑agent”, they usually mean multiple profiles. A Profile is an independent Hermes home. Each profile has its own config.yaml, .env, SOUL.md, memories, sessions, skills, cron jobs, and state database.

Create a coding assistant:

hermes profile create coder --clone
coder setup
coder chat

Create a reviewer assistant:

hermes profile create reviewer --clone
reviewer setup
reviewer chat

--clone copies current configuration, secrets, and SOUL, but gives the new profile fresh sessions and memory. It’s perfect for creating similar agents with distinct responsibilities.

If you want a full copy (including memory, sessions, skills, cron):

hermes profile create backup --clone-all

Important pitfall: A Profile is NOT a sandbox. A Profile isolates state – config, memory, sessions, skills, cron. It does not isolate file system permissions. With the default local terminal backend, it still accesses the file system as your current user.

If you want it to work only inside a specific project directory, set terminal.cwd. To restrict command execution environments, use Docker, SSH, Modal, Singularity, or other backends.

Remember: Profile manages identity and state; Sandbox manages permissions and boundaries. Don’t confuse the two.

Step 8: What Problem Does Docker Solve? – Don’t Mix the Two Integration Modes

Core question of this section: What are the two ways Docker integrates with Hermes, and which scenario does each address?

Docker relates to Hermes in two ways:

  1. Run Hermes itself inside Docker
    Suitable for deploying a long‑lived service and for keeping host environment cleaner.

  2. Hermes runs on the host, but executes terminal commands inside a Docker sandbox
    Suitable when you don’t want the agent to directly touch the host system.

These are not the same.

Running Hermes inside Docker, minimal form:

mkdir -p ~/.hermes

docker run -it --rm \
  -v ~/.hermes:/opt/data \
  nousresearch/hermes-agent setup

Background gateway:

docker run -d \
  --name hermes \
  --restart unless-stopped \
  -v ~/.hermes:/opt/data \
  -p 8642:8642 \
  nousresearch/hermes-agent gateway run

The key is the mount: ~/.hermes:/opt/data. Because /opt/data is the container’s Hermes state directory – .env, config, sessions, memories, skills, cron, logs all live there. Without the mount, everything disappears after container recreation.

If you only want safer command execution, try:

hermes config set terminal.backend docker

Now Hermes itself still runs on the host; only the terminal tool enters Docker.

Step 9: Kanban – The Most Noteworthy New Capability in the Latest Release

Core question of this section: How can you use Kanban to make multiple Hermes Profiles collaborate like a small team?

If you only do personal chat, Kanban is not a day‑one feature. But if you want multiple Hermes profiles to work together like a small team, Kanban becomes essential.

In the latest version, check it directly:

hermes kanban --help

The description: a durable SQLite‑backed task board. Tasks can be atomically claimed, can set dependencies, and can be executed by named profiles in isolated workspaces.

The latest release pushes this further: heartbeat, reclaim, zombie detection, retry budget, incomplete exit auto‑block. Translated: previously, multi‑agent felt like “send them out and hope for the best”. Now it’s more like a task board with heartbeats, failure recovery, and handover logs.

For starters, just know these commands:

hermes kanban init
hermes kanban boards list
hermes kanban create --help
hermes kanban list
hermes kanban show <task-id>
hermes kanban dispatch --help

Don’t let it auto‑manage big projects on day one. A better training exercise:

Create a small task board: AI daily brief production.
Task A: Collect 10 AI hot items.
Task B: Filter to 5 write‑worthy topics.
Task C: For each topic, write a headline and reader pain point.
Let the researcher profile do A, and the editor profile do B and C.

These tasks have low failure cost, clear structure, and are great for testing Kanban.

Kanban interface

Step 10: Cron Is for Scheduled Tasks, Not for Wishing

Core question of this section: How do you set up scheduled tasks for Hermes? Which tasks are suitable for automation and which are not?

Hermes has cron:

hermes cron list
hermes cron add
hermes cron status
hermes cron run <job>

The latest version also introduces no_agent cron – certain watchdog‑style tasks can run scripts without launching a full agent each time.

My first cron tasks are very conservative:

  • Morning AI tool brief
  • Evening backup of a directory
  • Weekly audit of Skills
  • Daily check if a webpage has updated

If something goes wrong, it’s easy to handle. Auto‑publishing articles, auto‑deleting files, auto‑operating accounts – I don’t recommend handing those over on day one. Automation is not about being aggressive. Only when you can review, roll back, and explain it, can it run unattended for the long term.

Troubleshooting Sequence – Don’t Randomly Edit Configs

Core question of this section: When Hermes misbehaves, what is the logical order to debug?

When Hermes has problems, the worst reaction is randomly editing .env and config.yaml. I usually run this sequence first:

hermes doctor
hermes model
hermes setup
hermes sessions list
hermes --continue
hermes gateway status
hermes logs errors

Quick reference:

  • hermes: command not found → shell not reloaded; do source ~/.bashrc or source ~/.zshrc (or restart terminal).
  • Model not responding → check provider, API key, model name, base URL.
  • Local model acting weird → check endpoint is OpenAI‑compatible, context length is sufficient, model name matches loaded model.
  • Gateway started but no response in chat → don’t immediately reinstall; check token, allowlist, pairing, home channel, platform permissions step by step.
  • Memory not working → verify same profile, session resumed, MEMORY.md / USER.md written.
  • Profile accesses external files → normal; Profile isolates state, not file permissions. Use sandbox for boundaries.
  • Docker loses config after restart → likely ~/.hermes not mounted to /opt/data.
  • Skills messed up → run hermes skills list and hermes skills audit before manually deleting.

A First‑Week Exercise: AI Daily Brief Assistant

Core question of this section: How do you use a realistic, low‑cost task to progressively train Hermes from “able to talk” to “able to work”?

I think the AI daily brief is the best first‑week exercise. It’s realistic but low‑risk – the worst outcome is an ugly report, not a deleted project.

Day 1: Give this task in CLI:

Please generate today’s AI tool update brief.
Requirements:

  1. For each item, keep product name, original link, and update time
  2. Categorise as agent / coding / video / image / infra
  3. Output Markdown
  4. At the end, note which preferences are worth keeping for next time

After it finishes, don’t just look at the content – correct the format. For example:

In future briefs, do not write vague praise. Keep only facts, links, and one sentence on “why it’s worth looking at”.
Save this preference into your memory.

Day 2: Change the requirement:

Continue yesterday’s AI tool update brief.
This time, keep only the 5 items most suitable for a full article.
For each, provide: headline angle, reader pain point, practical deliverable.

Three consecutive days of this, and you can probably save it as a Skill:

We have done the AI tool update brief three times in a row.
Save the stable workflow as a Skill named ai-daily-brief.
Include trigger conditions, information sources, filtering rules, output format, and validation methods.

This is far more practical than shouting “build me an AI empire” on day one. Small tasks are safe, low‑cost, and reviewable. Hermes will gradually remember preferences, solidify workflows, and then you can safely add chat integrations, cron, Profiles, and Kanban.

Wrapping Up – Continuity Is Hermes’ True Value

What I value most about Hermes is continuity. Many AI tools aren’t stupid – they’re just too easy to interrupt. You teach a format today, and tomorrow a new window forgets it. You fix a bug today, and the day after it makes the same mistake again.

Hermes puts memory, skills, sessions, gateway, profiles, and Kanban together to fight that fragmentation. But it’s not a maintenance‑free machine. You have to choose models, manage secrets, configure tools, check logs, audit permissions, clean Skills, and design task boundaries. It will grow, but how it grows depends largely on how you feed it tasks, give feedback, and allow it to retain processes.

My advice remains simple: first get one conversation working, then establish a workflow, then organise a team.

On day one, achieve just three things:

hermes model
hermes --tui
hermes doctor

It can talk, use tools, resume sessions, and self‑diagnose.

With that foundation, Hermes can become a long‑term AI workbench.

Practical Summary / Actionable Checklist (Can Be Done in One Week)

Day 1

  • [ ] Run curl -fsSL https://get.hermes.org | bash to install
  • [ ] Run hermes doctor to check environment
  • [ ] Configure one cloud model provider (e.g., OpenRouter)
  • [ ] Test conversation and tool use with hermes --tui
  • [ ] Test session resume with hermes --continue

Day 2

  • [ ] Write ~/.hermes/SOUL.md (5–10 lines of rules)
  • [ ] Make Hermes remember a preference (write to USER.md) via conversation
  • [ ] Learn hermes skills list and hermes skills search

Day 3

  • [ ] Set up Gateway (choose one chat platform, e.g., Telegram)
  • [ ] Send the first message from the chat app and receive a reply
  • [ ] Test Gateway + Memory: have Hermes remember a platform‑specific preference

Days 4–5

  • [ ] Create a second profile (e.g., coder)
  • [ ] Understand the difference between Profile and sandbox
  • [ ] Optional: try Docker sandbox execution

Days 6–7

  • [ ] Use the AI daily brief task to save a Skill
  • [ ] Try cron for a low‑risk scheduled task
  • [ ] Optional: use Kanban to create a small multi‑task board

One‑Page Summary

Module Core idea Key commands
Installation Use official script; Windows has native Beta curl ... | bash
Model Start with a cloud 64K+ model hermes model
Sessions Session resume = continuity hermes --continue
Config Separate .env, config.yaml, SOUL.md, MEMORY.md hermes doctor
Memory vs Skill Memory = facts; Skill = workflows hermes skills save
Gateway Bring Hermes into chat apps hermes gateway setup
Profile Right start for multi‑agent, but not a sandbox hermes profile create
Docker Two modes: run Hermis inside, or sandbox terminal terminal.backend docker
Kanban Enable profiles to collaborate like a team hermes kanban init
Cron Scheduled tasks, start low‑risk hermes cron add

FAQ

Q1: What’s the difference between Hermes and ChatGPT?
Hermes is an Agent runtime, not just a model. It comes with session management, long‑term memory, reusable Skills, multi‑chat‑platform Gateway, multi‑identity Profiles, a task board (Kanban), and scheduled tasks (Cron). Think of it as giving an AI assistant a permanent desk and a full toolbelt.

Q2: Do I have to use cloud models? Can I run everything locally?
Yes – Hermes supports local OpenAI‑compatible endpoints like Ollama and vLLM. But beginners should start with a cloud provider to get the entire flow working first, then switch to local models to avoid extra variables when debugging.

Q3: Windows users – WSL2 or native Beta?
If you only need CLI, TUI, Gateway, Profiles, and Skills, the native Beta is fine. For heavy development, long‑running automation, or any feature that relies on the Dashboard’s embedded terminal, WSL2 is still the more stable choice.

Q4: My Hermes keeps “forgetting” – I taught it a preference, but next day it’s gone.
Two things to check: (1) Are you using the same profile every time? (2) Are you resuming sessions with --continue? Preferences are written to USER.md and only take effect for the same profile and either a resumed session or a new session that reads that file. Also avoid putting fixed rules into MEMORY.md.

Q5: Do multiple Profiles interfere with each other?
By default, they are isolated: each profile has its own config, memory, sessions, skills, and cron. However, file system permissions are not isolated – all profiles access the file system as your current host user. To restrict file access, use a terminal backend like Docker.

Q6: Is Kanban useful for a single user?
Yes. Even with one profile, Kanban helps you break complex tasks into ordered steps, preventing the agent from being overwhelmed by too much context at once. Create tasks with hermes kanban create and let the agent process them one by one.

Q7: What if a cron job fails?
First run hermes cron status to see the job’s state, then hermes logs errors for error details. In the first week, only let cron perform read‑only or low‑risk tasks (e.g., generating briefs, checking updates). Avoid auto‑write or auto‑delete operations.

Q8: Gateway starts successfully, but my chat app receives no reply.
Step‑by‑step: Is the bot token correct? Is your user ID in the allowlist? Is the home channel set? Have you triggered required platform permissions (e.g., /start on Telegram)? hermes gateway status and hermes logs errors will show most issues.