15 Levels of Hermes Agent: From Chatbot to 24/7 Autonomous System

Source: Nitin Gavhane, 15 Levels of Hermes Agent: From Chatbot to 24/7 Autonomous System (Medium, members-only, 2026-06-25): https://nitingavhane.medium.com/15-levels-of-hermes-agent-from-chatbot-to-24-7-autonomous-system-da15c3c204f6

The 15-level framework, its three phases and its level names are Nitin Gavhane’s; read the original for his full text and examples. The table restates it in my own words, and the per-level explanations below are mine, built from the Hermes Agent documentation.

The framework

A maturity ladder for Hermes Agent, each level adding one capability. Most users plateau at levels 1–2, using the agent as a chat window. Readers can enter at whichever level matches their setup.

The levels

Levels 1–3 are the Foundation phase, 4–7 Leverage, and 8–15 Autonomy.

Where the article and the docs differ

• Level 2: the article puts your business facts in SOUL.md → the docs reserve SOUL.md for identity and tone; facts go in MEMORY.md / USER.md (agent-curated) or a project’s AGENTS.md.
• Level 3: the article’s /background → the command is /bg; /queue and /steer are as described.
• Level 4: the article routes each skill to its own model → a skill has no model setting; the levers are /model <name> --once, delegation.model for sub-agents, a per-cron-job model pin, and auxiliary.* task models.
• Level 7: the article’s /goal runs until the job is done → it is single-session, judged after each turn, and capped at 20 turns by default (goals.max_turns); long multi-part work fits Kanban (level 10).
• Level 15: the article packages everything, every profile included → a distribution packages one profile, and memory and sessions are never shipped.

The levels in detail

Each level below says what the capability is, what the previous level leaves unsolved, and what it looks like in Hermes, with a link to the documentation page it rests on. Commands and config keys are taken from the Hermes Agent docs as of October 2026; Hermes moves fast, so check the linked page before relying on a flag.

Level 1 — Task prompts

Hermes is an agent: a model in a loop with tools such as terminal, read_file, patch, web_search and web_extract, which it calls on its own until the job is done. A chat-style question uses none of that. A task prompt names an outcome and a place to put it, so the agent plans, searches, writes and verifies instead of answering from memory. The skill at this level is prompt shape, not configuration: name the deliverable, its format and where it goes. Everything above this level assumes you already prompt for outcomes, because background runs, schedules and sub-agents only pay off when the instruction they carry is complete.

Research the five most-used open-source vector databases, compare license,
replication and filtering support, and save a Markdown table to
~/reports/vector-dbs.md with a source URL per row.

Docs: Tools & Toolsets

Level 2 — Persistent context

Level 1 starts every session from zero, so you re-explain who you are and what you are working on. Hermes loads three kinds of standing context at session start, and each has a job. SOUL.md (in ~/.hermes/) is the agent’s identity: tone, directness, what to avoid. The docs say explicitly that it is not for facts, paths or project conventions. MEMORY.md (the agent’s notes, about 2,200 characters) and USER.md (your profile, about 1,375 characters) live in ~/.hermes/memories/; the agent edits them with its memory tool. Project rules go in an AGENTS.md in the repo. Memory loads as a frozen snapshot, so a fact saved mid-session appears only in the next one; on messaging platforms, /new creates that boundary.

cat ~/.hermes/SOUL.md                 # who the agent is
cat ~/.hermes/memories/MEMORY.md      # what it has learned
cat ~/.hermes/memories/USER.md        # what it knows about you

Docs: Persistent Memory, Use SOUL.md with Hermes, Context Files

Level 3 — Slash commands

With context in place, the bottleneck is that a running agent blocks you. Three commands fix that. /bg <prompt> starts a completely separate session in the background with the same model and tools but none of your conversation history, so the prompt must stand alone; the result appears as a panel when it finishes. /queue <prompt> lines up the next turn without interrupting the current one. /steer <prompt> injects a note that the agent receives after its next tool call, which changes direction without stopping the run. In effect, /bg is cmd & for an agent, /queue is cmd1; cmd2, and /steer is a message passed to a process that is still running.

/bg Summarize every ERROR line in /var/log/app/*.log from today, grouped by service
/queue Then draft a one-paragraph incident note from that summary
/steer Ignore the payments service, it is already known

Docs: Slash Commands Reference, CLI Background Sessions

Level 4 — Skills with model routing

A skill is a directory holding a SKILL.md plus optional scripts, kept in ~/.hermes/skills/. It is a procedure the agent loads on demand. Only names and descriptions sit in the prompt until a skill is needed (progressive disclosure), and every installed skill also becomes a slash command. Skills fix the problem of re-teaching the same procedure each time. Writing a Hermes skill covers how to write one. The routing half is about cost: a skill does not choose its own model, so you pick where cheap and expensive models run. /model <name> --once switches models for a single turn. delegation.model sets the model for sub-agents (level 6). A cron job can pin its own model (level 7).

/github-pr-workflow create a PR for the auth refactor
/model claude-opus-4.6 --once        # escalate one hard turn, then revert

Docs: Skills System, Configuring Models

Level 5 — MCP connectors

Up to now the agent sees only the web and your filesystem. MCP (Model Context Protocol) is a standard way to plug external tool servers into an agent, such as an issue tracker, a code host or a database, without writing a native Hermes tool. Servers are declared under mcp_servers in ~/.hermes/config.yaml, or installed from a curated catalog with hermes mcp. Each server adds tool schemas, which cost context on every turn, so limit what you expose. Each server takes an include/exclude tool filter or enabled: false. Hermes also defers MCP tool schemas behind a search bridge (Tool Search) by default, which caps the listing cost but adds a lookup step before a deferred tool is first used.

# ~/.hermes/config.yaml
mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    tools:
      include: [create_issue, list_issues]

Docs: MCP, Tool Search

Level 6 — Parallel sub-agents

A single agent working through three independent research questions does them one after another, and each one’s transcript crowds the next one’s context. The delegate_task tool spawns child agents, each with a fresh conversation and its own terminal. Only a child’s final summary returns to the parent, so the parent’s context stays small. A batch runs up to 10 children concurrently by default. The children know nothing about the parent’s conversation: everything they need goes in the goal and context fields. The parent’s main job is writing that hand-off well. Point children at a cheaper model in config while the parent plans on a frontier model, since the children are where most tokens are spent.

# ~/.hermes/config.yaml
delegation:
  model: "your-inexpensive-model"   # all delegate_task children
  provider: "openrouter"            # optional

Docs: Subagent Delegation

Level 7 — Async work

Everything so far still waits for you to type. Two features remove that. /goal <text> sets a standing objective for the current session. After each turn a judge model decides whether it is done, and if not, Hermes continues on its own, within a turn budget (goals.max_turns, default 20). Cron jobs run prompts on a schedule from the gateway, which must be running. A job can attach a pre-check script: if its last stdout line is {"wakeAgent": false}, that tick never calls the model, so polling costs nothing until something changes. The script must live in ~/.hermes/scripts/.

/cron add "daily at 7am" "If the script reports a pricing change, summarize it; otherwise reply [SILENT]" --script pricing-changed.sh --name "Pricing watch" --deliver telegram

Docs: Persistent Goals, Scheduled Tasks (Cron)

Level 8 — Specialized profiles

Once one agent runs many scheduled jobs, its memory, skills and model choice serve too many purposes at once. A profile is a separate Hermes home directory with its own config.yaml, .env, SOUL.md, memory, skills, sessions and cron jobs. Creating one also creates a command alias that works with every hermes subcommand. Profiles do not share memory, and the docs warn never to point two agents at one home, because each would load the other’s memory writes. A pipeline of single-purpose agents (a scout that watches sources, an analyst that synthesizes, a briefer that delivers) is three profiles, each on the model and schedule its job needs.

hermes profile create scout --description "Watches sources and records raw signals"
scout config set model.default your-inexpensive-model
scout cron create "every 4h" "Check the watch list and log new items"

Docs: Profiles

Level 9 — Knowledge base

Memory is deliberately small: a few thousand characters, curated by the agent. Months of research need somewhere else to live. Hermes bundles an llm-wiki skill that implements Andrej Karpathy’s LLM Wiki pattern: a plain directory of interlinked Markdown files (set by WIKI_PATH, default ~/wiki). Immutable sources go in raw/, agent-maintained entity, concept and comparison pages sit above them, and a SCHEMA.md, index.md and log.md keep it consistent. Unlike retrieval over raw documents, the wiki is compiled once and kept current, so cross-references and contradictions are already recorded when you ask a question. Because it is plain Markdown, Obsidian or any editor can open it.

wiki/
├── SCHEMA.md      # conventions and tag taxonomy
├── index.md       # catalog of pages
├── log.md         # append-only action log
├── raw/           # immutable sources
├── entities/
└── concepts/

Docs: LLM Wiki skill

Level 10 — Shared Kanban

Sub-agents (level 6) live only as long as the parent’s turn, and /goal (level 7) is one session. Work that spans days, profiles and dependencies needs durable state. Hermes Kanban is a task board in ~/.hermes/kanban.db, shared across profiles. Each card has one assignee profile. A dispatcher in the gateway starts a worker process for each ready card. A card linked to a parent stays in todo until every parent is done, and the parents’ completion summaries are passed to it. The docs draw the line plainly: one task in one chat is /goal; many tasks with dependencies or several profiles is Kanban. For a three-step pipeline, the board is overhead.

hermes kanban create "Research 20 clinic websites" --assignee researcher
hermes kanban create "Draft outreach emails" --assignee writer --parent <research-card-id>

Docs: Kanban, Goals vs Kanban

Level 11 — Voice

By this point, much of the output reaches you on your phone through a messaging gateway. Voice makes that usable when you cannot type or read. On Telegram and Discord, voice messages are transcribed, and /voice controls whether replies come back as audio. In the CLI, /voice on enables push-to-talk with Ctrl+B. Discord can also join a voice channel. On WhatsApp, incoming voice notes are transcribed and spoken replies arrive as MP3 attachments. Speech-to-text and text-to-speech providers are set with hermes tools.

/voice on       # reply with audio when you send a voice message
/voice tts      # reply with audio to every message
/voice status

Docs: Voice Mode, WhatsApp

Level 12 — Browser automation

MCP and web extraction cover services that expose an API or serve readable HTML. Some sites only work in a real browser, behind a login or JavaScript. Hermes has a browser toolset (browser_navigate, browser_snapshot, browser_click, browser_type, browser_vision and more) that presents pages to the model as accessibility trees with ref IDs for interactive elements. It runs against cloud providers or a local Chromium-family browser attached with /browser connect. Treat it as a last resort. It is slower and more brittle than an API call, and a scheduled job cannot answer a login prompt, so any session it depends on has to exist before the job runs.

Open the vendor's pricing page, record each tier's monthly price, and compare
it with last month's snapshot in ~/wiki/raw/articles/vendor-pricing.md

Docs: Browser Automation

Level 13 — Agent as an API

So far the only ways in are the CLI, the desktop app and messaging platforms. The API server exposes Hermes as an OpenAI-compatible HTTP endpoint served by the gateway, so any OpenAI-format client (Open WebUI, LobeChat, an internal dashboard, a script) can send it a request. The request runs with the agent’s full toolset, memory and skills, and the final answer comes back. Enable it in ~/.hermes/.env with a bearer key, start the gateway, and point the client at http://localhost:8642/v1. Anything that can call that endpoint can use the agent’s tools, so treat API_SERVER_KEY as a real secret.

# ~/.hermes/.env
API_SERVER_ENABLED=true
API_SERVER_KEY=change-me

hermes gateway
curl http://localhost:8642/v1/chat/completions \
  -H "Authorization: Bearer change-me" -H "Content-Type: application/json" \
  -d '{"model": "hermes-agent", "messages": [{"role": "user", "content": "Hello"}]}'

Docs: API Server

Level 14 — IDE integration

An HTTP endpoint returns text, but an editor needs diffs, tool activity and approval prompts in its own UI. ACP (Agent Client Protocol) is a protocol for that: the editor runs the agent as a subprocess and talks to it over stdio. hermes acp runs Hermes as an ACP server with a curated editor toolset (files, terminal, web, memory, skills, delegation) that leaves out messaging delivery and cron. It keeps the same identity, memory and skills as your other sessions. Zed takes it as a custom agent server. VS Code uses the ACP Client extension. JetBrains works through any ACP-compatible plugin. The ACP extra must be installed first.

{
  "agent_servers": {
    "hermes-agent": { "type": "custom", "command": "hermes", "args": ["acp"] }
  }
}

Docs: ACP Host Integration

Level 15 — Packaged setup

A tuned agent that exists on one machine cannot be reviewed, versioned or handed to a teammate. A profile distribution is a git repository holding one profile’s SOUL.md, config.yaml, skills, cron jobs and MCP connections, plus a distribution.yaml manifest that declares the environment variables it needs. Recipients install it with one command and pull new versions with hermes profile update, and their own memory, sessions and keys are left alone. Two cautions from the docs. First, Hermes applies its secret and user-data exclusions only when someone installs; git add knows nothing about them, so the author needs a .gitignore before the first commit. Second, a distribution is one profile, so a three-profile pipeline is three repositories.

hermes profile install github.com/you/my-research-agent --alias
# fill in your own keys: .env.EXAMPLE -> .env in the installed profile
my-research-agent chat
hermes profile update my-research-agent     # pull the author's next version

Docs: Profile Distributions

Takeaways

• The payoff is uneven.
  • Levels 3–7 are where time saved grows most, through background and scheduled work.
  • Levels 7–10 turn the agent from something you drive into something whose output you review.
• Grow the setup deliberately: begin with only the model and file access enabled, then add one capability at a time.
• Cost control runs through every phase: model routing, few connectors, change-gated schedules.
  • The article’s model names and prices are a mid-2026 snapshot; check current ones.

Related

• Hermes-Agent-Skill-Authoring-SKILL-md-Structure-and-Best-Practices