What Is Hermes Agent? Nous Research's Self-Improving Agent Explained

Hermes Agent is an open source, MIT-licensed AI agent built by Nous Research that runs on your own machine or server, uses tools such as a terminal, files, a browser and MCP servers, and "learns" by writing to its own memory files, saving reusable skills and searching its past sessions. It does not retrain any model.

That last point matters most. When Nous Research calls Hermes Agent "self-improving", it means the agent edits text files and a database that shape what it does next time. That is useful, and it is also the part a defender needs to understand, because the same mechanism that lets the agent remember a deploy procedure lets it remember a wrong or planted one. This guide covers what Hermes Agent is, how the learning loop works, its release history up to v0.22.5, where it runs, how it relates to the Hermes models, its security record so far, and a first-run setup that keeps every self-written change under review. Every version number and default below was checked against the project's own repository and docs on 23 October 2026.

Key takeaways

• What it is: an open source agent harness from Nous Research, MIT licence, repository NousResearch/hermes-agent, tagline "The agent that grows with you". It is a long-running agent with tools, not a chat window and not an editor plugin.
• What "self-improving" means: curated memory (MEMORY.md and USER.md), skills the agent writes and patches itself, full-text search over past sessions, optional user modelling, and a background review after turns that can save memory and skills. No weight updates happen during normal use.
• The default is permissive: skills.write_approval and memory.write_approval both default to false, so the agent writes freely unless you turn the gates on.
• Release pace is very high: 44 GitHub releases between 12 March and 23 October 2026, CalVer tags until September, SemVer tags from v0.21.6 on 8 October. Latest is v0.22.5.
• Many ways to run it: CLI and TUI, a desktop app, a messaging gateway, cron, an editor integration over ACP, an API server, and several terminal backends from "local" (no isolation) to Docker, SSH and hosted sandboxes.
• Hermes Agent is not the Hermes models. The models are Nous's open-weight fine-tunes; the agent is model-agnostic and can drive many providers. "Hermes" in a tool-calling stack often means the Hermes tool-call format instead.
• Security record: two published CVE records (CVE-2026-71963 and CVE-2026-85105), both September 2026. The docs describe an eight-layer security model, with "smart" command approval on by default.
• Run it like any other code that writes code: a container backend, both write-approval gates on, version control over ~/.hermes, and the same dependency hygiene you apply to a repository.

What is Hermes Agent?

Hermes Agent is an autonomous AI agent that you install and run yourself. The project README calls it "the self-improving AI agent built by Nous Research" and says it can run "on a $5 VPS, a GPU cluster, or serverless infrastructure". Nous Research's releases page lists it as "an autonomous agent that lives on your server, remembers what it learns, and gets more capable the longer it runs".

Who builds it

Nous Research builds and maintains it. On its homepage the company describes itself as "a pioneer in open AI training and research". Besides Hermes Agent, Nous ships the Hermes family of open-weight language models, Nous Portal (a hosted model and tool subscription that Hermes Agent can use), and the Psyche network, which its releases page describes as "open infrastructure democratizing AI development". Nous is an AI research lab. It is not a security vendor, and nothing in this article implies any relationship between Nous and Safeguard.

Licence and code

The repository is github.com/NousResearch/hermes-agent. The GitHub API lists the licence as MIT, and the LICENSE file reads "Copyright (c) 2025 Nous Research". The main language is Python. The repository was created on 22 July 2025, well before the public launch, which matters when you read dates (see the release history below).

MIT means you can run it, modify it, fork it and ship it inside other software, with the usual notice requirement. It also means there is no warranty, and that every fork you take becomes your own maintenance burden.

How it differs from a chat app or an IDE assistant

The difference is less about the model and more about where the agent lives and what it keeps.

The last row is the reason Hermes Agent gets attention. The README describes "a closed learning loop": "Agent-curated memory with periodic nudges. Autonomous skill creation after complex tasks. Skills self-improve during use." The README also says Hermes is "the only agent with a built-in learning loop". That is Nous's own claim and should be read as such.

What "self-improving" means in Hermes Agent

In Hermes Agent, self-improvement is a set of write paths. The agent, or a review process running beside it, writes to files and a database under the Hermes home directory (~/.hermes on Linux, macOS and WSL2). Those files are loaded into later sessions and change what the agent does. Here is each piece, from the project docs.

Memory: MEMORY.md and USER.md

The memory docs describe two files in ~/.hermes/memories/:

Both are injected into the system prompt "as a frozen snapshot at session start". The snapshot does not change mid-session; the docs say this preserves the provider's prompt cache. So a fact saved now shows up in the next session, not the current one.

The caps are hard. There is no automatic compaction: when a write would exceed the limit, the memory tool returns an error asking the agent to remove or shorten entries in the same batch. That design keeps memory small and forces curation, which is good for cost and also good for review, because a 2,200 character file is something a person can actually read.

Before an entry is accepted, the docs say it is scanned for "prompt injection, credential exfiltration, SSH backdoors" and invisible Unicode, because memory is injected into the system prompt. A pattern scan is a useful filter, not a guarantee; treat it as one layer.

The config block in ~/.hermes/config.yaml looks like this in the docs:

memory:
  memory_enabled: true
  user_profile_enabled: true
  memory_char_limit: 2200   # ~800 tokens
  user_char_limit: 1375     # ~500 tokens
  write_approval: false     # false = write freely (default) | true = require approval

With write_approval: true, writes outside the interactive CLI are held for review and listed with /memory pending. The docs also note that the background review stages patch and remove operations "even with the gate off", and that a staged change is refused if the entry it targets has changed since it was staged.

Skills the agent writes itself

Skills are the bigger lever. The skills docs call them "on-demand knowledge documents" and describe them as the agent's "procedural memory". They live in ~/.hermes/skills/, use the SKILL.md format, and are compatible with the agentskills.io open specification, which defines a skill as a directory containing at minimum a SKILL.md file with YAML frontmatter, plus optional scripts/, references/ and assets/ folders.

That scripts/ folder is worth pausing on. A skill can carry executable code. When an agent writes a skill, it may be writing a script that a later session runs.

Skills load by progressive disclosure: the agent first sees a list of names and descriptions (the docs estimate about 3,000 tokens), loads the full SKILL.md only when it needs it, and loads individual reference files on demand.

The agent manages its own skills through the skill_manage tool, with these actions from the docs:

According to the docs, the system prompt asks the agent to record a skill when it "worked out a multi-step workflow worth repeating", when it "hit errors or dead ends and found the working path", and when "the user corrected its approach". An advisory linter checks new skills for shapes such as a body full of issue numbers or an oversized file, but the docs say the linter rules "warn; they never block a write".

The gate is skills.write_approval, and the docs are explicit: "By default the agent writes skills freely." With the gate on, every write is staged under ~/.hermes/pending/skills/ and reviewed with /skills pending, /skills diff <id>, /skills approve <id> and /skills reject <id>. A separate setting, skills.guard_agent_created, is described as "a content scanner (dangerous-pattern heuristics), not an approval gate".

Skills from outside arrive in three ways. The Skills Hub installs skills from registries and records the source URL and content hash, with a security scan and a quarantine directory. Project-local skills in a repository are not loaded until you run hermes skills trust, and the docs say every project skill is scanned at index time, with skills judged dangerous quarantined. And /learn, added in v0.18.0, turns a document, URL, conversation or file into a skill; the docs note it goes through the same skill_manage write path, so the approval gate applies.

Session search

Every CLI and messaging session is stored in SQLite at ~/.hermes/state.db with FTS5 full-text search. The agent queries it with a session_search tool. The memory docs put this as the division of labour: memory carries the essentials into the next session, and "session_search fills the gaps once the old context is gone". Session search returns past conversation text; it is recall, not learning, but it does mean old content, including anything a past session read from an untrusted page, can come back into context later.

User modelling

The README lists "Honcho dialectic user modeling", and the v0.3.0 release notes added a Honcho memory integration with "multi-user isolation in gateway mode". Honcho is a separate project from Plastic Labs, linked from the README. The memory docs describe memory.provider as the place to plug in an external memory provider, which keeps its own tools and recall budget. If you enable one, its data store becomes part of what the agent remembers, and part of what you need to back up and review.

The background review and the curator

The piece that makes the loop feel automatic is the background review. The memory docs describe it as "the background self-improvement review": after a turn, a forked copy of the conversation runs on your main model (or a cheaper one you configure under auxiliary.background_review) and "may quietly save a memory or update a skill". By default the chat shows a short notification line; display.memory_notifications: verbose shows a preview of what changed. The review can be switched off with auxiliary.background_review.enabled: false, and its cost capped with max_input_tokens. The skills docs also mention a "curator" consolidation pass that maintains agent-created skills, and that never modifies project or external skill directories.

The v0.18.0 Judgment release added /learn and /journey, which the release notes say "turned self-improvement into something you can see and steer". The v0.21.0 Pantheon release notes say cron jobs "gained memory and continuity so scheduled agents actually learn between runs".

Summary of the learning stores

What self-improving does not mean

It does not mean the model gets smarter. Nothing in the Hermes Agent docs describes the running agent changing model weights. The model you choose with hermes model is the same model before and after a month of use. What changes is the context the model receives: a few thousand characters of memory, a list of skills, and whatever it retrieves from past sessions.

The README does mention a separate research feature, "batch trajectory generation, trajectory compression for training the next generation of tool-calling models". That is a way to export agent runs as training data. It is an offline research workflow, not something the agent does to itself while you use it.

It also does not mean the agent is guaranteed to get better. A skill saved after a correction can encode the correction or a misunderstanding of it. The docs themselves suggest the write gate for "small models that misjudge what they learned". Improvement here is a claim about convenience over time, reported by Nous, not a measured result we can cite with a benchmark, a baseline and an evaluator. Nous's v0.18.0 notes say the agent learned to "verify its own work against evidence", which is a design goal described by the project, not an independent evaluation.

Release history: from a private repository to v0.22.5

Hermes Agent ships fast. The GitHub releases API listed 44 releases on 23 October 2026, from v0.2.0 on 12 March 2026 to v0.22.5 on 23 October 2026 (UTC). Below are the milestones. "Notes date" is the release date printed in the release notes; "GitHub" is the published_at timestamp in UTC, which can be a day later.

Reading the version numbers

Two tag schemes overlap. From March to September 2026 the git tags were calendar versions (v2026.3.12 to v2026.9.24) while the release titles carried semantic versions (v0.2.0 to v0.21.5). From v0.21.6 on 8 October 2026, the tags themselves are semantic versions. If you pin by tag in automation, check which scheme the tag you want uses.

The pace matters for anyone running it. Several releases a week means the docs move, defaults move and config keys move. The v0.22.0 notes count about 6,080 merged pull requests and about 2,520 contributors in the window since v0.21.0; those are the project's own figures. A version you validated three weeks ago is not the version an unpinned install fetches today.

Where Hermes Agent runs

Interfaces and entry points

The architecture docs list six entry points into one AIAgent loop:

On top of those, v0.16.0 added a native desktop app, and the README describes a built-in cron scheduler for "daily reports, nightly backups, weekly audits", running unattended with delivery to any platform. The README also notes an Android path through a signed APT repository for Termux, and native Windows support through PowerShell.

The gateway and cron are where Hermes differs most from an assistant you sit in front of. A gateway bot answers whoever the allowlist and pairing rules let through. A cron job runs with nobody watching. The security docs set different defaults for those cases, covered below.

Terminal backends

The terminal is where commands run, and the backend decides what "the terminal" is. The docs disagree slightly on the count: the README says "six built-in terminal backends" plus plugin backends such as Singularity/Apptainer, and the architecture page says "Terminal (7 backends)". We used the security page's comparison table, read on 23 October 2026:

Two lines in that table deserve emphasis. The default kind of setup most people start with, local, has no isolation: the agent's commands run as your user, on your files. And on container backends the dangerous-command check is skipped by design, so the container configuration becomes the control.

The Docker backend applies hardening flags listed in the security docs: --cap-drop ALL with a small set of capabilities added back, --security-opt no-new-privileges, --pids-limit 256, and size-limited tmpfs mounts. Resource limits (CPU, memory, disk) and terminal.docker_forward_env are set in config.yaml; the forward list is empty by default, which "keeps secrets out of the container".

Tools and MCP

The tool surface is large, and the docs count it differently: the README's documentation table says "40+ tools", while the architecture page describes a central registry with "70+ registered tools across ~28 toolsets". Beyond built-in tools, Hermes has been a native MCP client since v0.2.0, with stdio and HTTP transports, resource and prompt discovery, and sampling. MCP, the Model Context Protocol, is an open protocol for connecting LLM applications to external tools and data. The security docs say MCP subprocesses receive a filtered set of environment variables rather than your whole environment. Every MCP server you add is another piece of third-party code and another set of permissions the agent can use.

Which models can drive it

Hermes Agent is provider-agnostic. The README names Nous Portal, OpenRouter, OpenAI, "your own endpoint, and many others", and hermes model switches between them "no code changes, no lock-in". The architecture docs say the runtime provider resolver "handles 18+ providers" and three API modes: chat completions, a Codex responses mode and Anthropic messages. Since v0.22.0, a one-click local llama.cpp runtime runs models on your own hardware. The release notes for that version list newly supported third-party models; we do not repeat those here because facts about other labs' models belong to their own documentation.

Nous Portal is Nous's own subscription. The README says it covers "300+ models" plus a "Tool Gateway" for web search, image generation, text-to-speech and a cloud browser, set up with hermes setup --portal. Using it is optional.

Hermes Agent, the Hermes models and the Hermes tool-call format

"Hermes" means three different things in AI agent stacks, and mixing them up causes real confusion in procurement and in incident triage.

The Hermes models

The Hermes models are Nous Research's open-weight fine-tunes of other base models. They predate the agent by almost three years. Dates below come from nousresearch.com/releases where listed; where the releases page does not list a model, we used the Hugging Face repository creation date, which can precede public release (Hermes 4 405B's repository, for example, was created on 6 August 2025, three weeks before the 26 August launch).

You do not need a Hermes model to run Hermes Agent, and running a Hermes model does not mean you are running the agent. The agent works with any supported provider; the models work in any inference stack.

The Hermes tool-call format

The third meaning is a format. Hermes models emit tool calls inside <tool_call> tags, which the Hermes 4.3 model card describes as added tokens that make parsing easy while streaming. The vLLM tool calling docs include a hermes parser: "All Nous Research Hermes-series models newer than Hermes 2 Pro should be supported", enabled with --tool-call-parser hermes. The same page notes that Hermes 2 Theta models "are known to have degraded tool call quality and capabilities due to the merge step in their creation".

So when someone on your team says "we use Hermes for tool calling", ask which of the three they mean. A config that sets --tool-call-parser hermes in an inference server is a serving decision, not an agent deployment.

Other projects called Hermes

Two unrelated open source projects share the name and show up in the same searches:

• Hermes, the JavaScript engine at facebook/hermes, MIT licensed, described in its README as "a JavaScript engine optimized for fast start-up of React Native apps". Our post on React Native Hermes bytecode covers that one.
• Hermes, the IBC relayer at informalsystems/hermes, a relayer for the Cosmos inter-blockchain communication protocol.

A software inventory that lists a component simply as "hermes" is ambiguous. Use the full package or repository coordinate.

Adoption: what the numbers say and how to read them

On 23 October 2026 the GitHub API reported 256,394 stars and 56,026 forks for NousResearch/hermes-agent. Those are a dated snapshot and say how many accounts clicked a button, not how many people run the agent in production. Stars measure interest, forks include abandoned experiments, and neither says which versions are deployed.

Nous's homepage says it "created Hermes Agent, the most widely used open source agent harness in the world". That is Nous's own description; we found no independent measurement to cite either way. The contributor and pull request totals in the release notes are also self-reported by the project.

For a security team, the useful adoption number is internal: how many machines in your organisation have a ~/.hermes directory, which versions they run, and which of them run the gateway. That number you can measure.

Security record so far

CVE records

Two CVE records naming Hermes Agent were published on CVE.org, both on 3 September 2026:

• CVE-2026-71963 describes command execution through a crafted git core.fsmonitor setting in an opened repository, affecting Hermes Agent 0.18.2 through 0.21.0, fixed in commit f6234d0. Our CVE-2026-71963 explainer has the detail.
• CVE-2026-85105 describes an authorisation bypass in session management in Hermes Agent 0.18.0. Our CVE-2026-85105 explainer covers it.

An earlier check of the GitHub security advisories API on 23 October 2026 found no published GitHub security advisories for the repository; a repeat check later that day hit the API's rate limit, so treat that as a dated snapshot. Release notes do carry security work: v0.13.0 reports closing 8 P0 security issues and turning credential redaction on by default, v0.16.0 reports 16 security-tagged issues closed, and v0.22.5 mentions dependency security bumps.

The built-in security model

The security docs describe eight layers:

Approval has three modes under approvals.mode: smart (the default since v0.19.0, where "an auxiliary LLM" assesses risk, auto-approves low risk commands, auto-denies dangerous ones and escalates uncertain ones), manual, and off, which the docs say is "equivalent to running with --yolo". Cron jobs default to cron_mode: deny, so a scheduled job that hits a dangerous command is blocked rather than approved. Below all modes sits a hardline blocklist that the docs say has "no override flag", and approvals.deny lets you add your own unconditional deny patterns.

There is also a built-in supply chain advisory check. The docs say Hermes ships "a built-in advisory scanner that flags Python packages in the active venv that match a curated catalog of known-compromised versions", shown in the startup banner and in hermes doctor. Optional dependencies can be installed on demand under security.allow_lazy_installs, with managed tool archives pinned by SHA-256 in a lock file; hermes config set security.allow_lazy_installs false turns on-demand installs off.

A smart approval mode is a model judging another model's command. It is better than nothing and worse than a sandbox. The docs' own table says production gateways belong on a container backend.

A first run with the learning loop under review

This walkthrough installs Hermes Agent so that every self-written change is visible and reversible. Commands and keys are from the README and docs as read on 23 October 2026; check them against your installed version with hermes --version and the docs for that version.

Step 1: read the installer before you run it

The README's one-liner pipes a script into bash. Download it first and read it:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh -o hermes-install.sh
less hermes-install.sh
bash hermes-install.sh
source ~/.bashrc   # or ~/.zshrc
hermes --version

On native Windows the README uses iex (irm https://hermes-agent.nousresearch.com/install.ps1); the same advice applies, save it and read it first. Since v0.22.0, the notes say installs follow tested SemVer stable releases by default.

Step 2: run setup and the doctor

hermes setup
hermes doctor

hermes setup offers to import settings, memories and skills from other agents it finds. Say no on the first run unless you have read what will be imported; for OpenClaw the README says API keys come across only with --migrate-secrets, so leave that flag off. hermes doctor shows any active supply chain advisories for the Python environment.

Step 3: turn on both write gates and a container backend

Edit ~/.hermes/config.yaml (keys from the memory, skills and security docs):

memory:
  write_approval: true        # stage memory writes for review

skills:
  write_approval: true        # stage every skill_manage write under ~/.hermes/pending/skills/

display:
  memory_notifications: verbose   # show what the background review changed

approvals:
  mode: manual                # ask for every flagged command while you learn its habits
  cron_mode: deny             # the default; keep it

terminal:
  backend: docker
  docker_forward_env: []      # the default; keep secrets out of the container

security:
  allow_lazy_installs: false  # no on-demand dependency installs

The same keys can be set one at a time with hermes config set, for example hermes config set skills.write_approval true. In a running session, /skills approval on turns the skill gate on and persists it.

Step 4: put the Hermes home under version control

Skills and memory are plain files, so git gives you history, diffs and rollback. Keep credentials and the session database out of the repository:

cd ~/.hermes
git init
cat > .gitignore <<'EOF'
.env
auth.json
state.db*
pending/
*.log
EOF
git add -A
git commit -m "Hermes baseline before first session"

Check git status before the first commit and add anything else that looks like a credential or a token cache to .gitignore. Do not push this repository anywhere public; USER.md describes you.

Step 5: use it, then review what it learned

After a working session:

/skills pending
/skills diff <id>
/memory pending

Approve what you understand and agree with (/skills approve <id>, /memory approve), reject the rest (/skills reject <id>). Then record the state:

cd ~/.hermes
git diff --stat
git add -A
git commit -m "Reviewed skills and memory after session"

Read any new file under a skill's scripts/ directory as you would read a pull request from a new contributor. It is code that a future session may run.

Step 6: rolling back a bad skill or memory entry

Warning: the commands below overwrite or delete the agent's learned state. Take a backup first, and stop any running Hermes sessions and the gateway so nothing writes while you restore.

# Backup before any rollback
tar czf ~/hermes-backup-$(date +%F-%H%M).tgz -C ~ .hermes

Then restore one skill directory, or the memory files, from the last reviewed commit:

cd ~/.hermes
git log --oneline -- skills/ memories/
git checkout <reviewed-commit> -- skills/<skill-name>
git checkout <reviewed-commit> -- memories/MEMORY.md
git status

Memory is loaded as a frozen snapshot at session start, so start a new session (/new) after restoring.

Step 7: decide on the gateway last

Only after a few reviewed sessions, consider hermes gateway setup. Read the security docs' sections on platform allowlists and DM pairing first, keep the Docker backend, and remember that anyone the gateway admits can steer an agent that writes to its own skills.

Who should and should not run it today

Good fits:

• Individual developers and researchers who want an agent that remembers their environment and routines, on a machine they control, with the write gates on.
• Teams evaluating agent harnesses who can run it in a container or a disposable VM and read every skill it writes.
• People who already run local models and want a harness that drives them, given the llama.cpp runtime added in v0.22.0.

Wait, or run it only in a sandbox:

• Anyone who would point the local backend at a laptop holding production credentials, SSH keys or customer data.
• Shared gateway bots in a company chat without a decision on allowlists, pairing and who reviews learned skills.
• Regulated environments that need a fixed, validated version; at several releases a week, you will need to pin and revalidate deliberately.
• Unattended cron agents with write access to anything that matters, until you have a review habit for what those runs learn.

What to read next in this series

This post is the overview for a cluster on Hermes and on self-improving agents more broadly. The rest of the series covers the Hermes Agent architecture (the loop, tools, terminal backends, gateway and MCP), how its learning loop works in detail, how to install and harden it, the history of the Hermes models, the research behind self-improving agents, and the security questions that matter most: agents that write their own tools, prompt injection that persists in memory and skills, provenance for agent-made code, and rollback and audit for self-modifying agents. Until those publish, two live posts are good next reads: why agent skills and plugin repositories need the same governance as packages, and CERT-In's advisory on AI agent attack vectors.

Common mistakes

• Assuming "self-improving" means the model improves. It means memory and skill files change. If those files are wrong or poisoned, the agent gets reliably worse at that task.
• Leaving both write gates at their defaults. skills.write_approval and memory.write_approval default to false. For anything beyond personal experimentation, turn them on and review.
• Running the local backend with a real credential set. The docs' own table says local has no isolation. Use Docker or SSH, and keep docker_forward_env empty unless a task needs one named variable.
• Treating smart approvals as a sandbox. An auxiliary model judging commands reduces noise; it does not contain a mistake. On container backends the check is skipped, so the container is the control.
• Forgetting that skills can carry scripts. A skill directory can include scripts/. Review those files as code.
• Trusting a repository's project skills by habit. hermes skills trust is a repo-level decision. Re-read project skills after a pull, even though Hermes scans them.
• Importing everything from another agent on day one. Imported memories and skills become part of the system prompt. Preview with --dry-run and leave --migrate-secrets off unless you mean it.
• Not pinning versions. With several releases a week, an unpinned install fetched next Tuesday is a different program. Record hermes --version with every reviewed state.
• Reading star counts as usage. 256,394 stars on 23 October 2026 is a popularity snapshot, not a deployment count.
• Confusing the agent, the models and the parser. An inventory entry of "hermes" needs a full coordinate.

Where Safeguard fits, honestly

Hermes Agent is not a Safeguard product, integration or partner, and Safeguard does not scan, govern, monitor or sandbox Hermes Agent specifically. Its approval modes, write gates, Docker hardening and advisory check are Nous's features, documented by Nous.

The honest connection is the software an agent like this produces and depends on. Hermes Agent is itself a Python project with a dependency tree and a lock file. Its plugins and skills are code you pull from hubs and repositories. And when you use it to write code, install packages or author scripts, the result lands in your repositories and images like any other contribution. Safeguard's CLI can scan a repository, a container image or an SBOM file (safeguard scan --dir ., --image <name>, --sbom <file>), generate SBOMs in SPDX and CycloneDX, match components against vulnerability databases, and the platform shows which projects contain a given component and version. Policies and gates can stop a known vulnerable dependency from shipping in CI, and attestation and signing (SLSA, Sigstore, in-toto) record where an artifact came from. Agent identity, which tracks which agent holds what access, is generally available; MCP Guardrail, the AI Gateway and AI-BOM discovery are early access. None of that reviews a SKILL.md for you; the write gates and git history above do that job.

FAQ

What is Hermes Agent?

Hermes Agent is an open source AI agent from Nous Research, released under the MIT licence. It runs on your machine or server, uses tools such as a terminal, files, a browser and MCP servers, and keeps memory files, self-written skills and a searchable history of past sessions that shape later work.

Is Hermes Agent free?

The software is free under the MIT licence. You pay for whatever model you connect it to, unless you run a local model. Nous Portal is an optional paid subscription that bundles models and tools; the v0.22.0 notes describe a free trial model for first-run setup in the desktop app.

Does Hermes Agent train its own model?

No. The docs describe learning as writes to MEMORY.md, USER.md, skill files and the session database. The model's weights do not change while you use it. A separate research feature exports agent trajectories that could be used to train future models offline.

What is the difference between Hermes Agent and the Hermes models?

The Hermes models are Nous Research's open-weight language models, from Nous-Hermes-13b in 2023 to Hermes 4.3 in December 2025. Hermes Agent is the agent harness launched in February 2026. The agent can run on Hermes models or on many other providers, and the models can run without the agent.

Is Hermes Agent safe to run?

It can be run safely with care. Use a container or SSH backend rather than local, turn on skills.write_approval and memory.write_approval, keep docker_forward_env empty, pin the version, and review what it writes. Two CVE records were published in September 2026, so keep it updated.

Where does Hermes Agent store memories and skills?

Under ~/.hermes on Linux, macOS and WSL2 (native Windows uses %LOCALAPPDATA%\hermes). Memory is in ~/.hermes/memories/, skills in ~/.hermes/skills/, staged skill writes in ~/.hermes/pending/skills/, and sessions in ~/.hermes/state.db.

What does --yolo do in Hermes Agent?

It disables dangerous command approval prompts for the session, the same as approvals.mode: off. The docs say the hardline blocklist and any approvals.deny patterns still apply. Use it only in disposable environments.

What models does Hermes Agent support?

It is provider-agnostic. The README names Nous Portal, OpenRouter, OpenAI and custom endpoints, the architecture docs mention 18+ providers, and v0.22.0 added a one-click local llama.cpp runtime. Switch with hermes model.

What is the latest version of Hermes Agent?

On 23 October 2026 the latest GitHub release was v0.22.5, dated 22 October in its notes. Releases ship several times a week, so check the releases page before you pin.

Is Hermes Agent related to the Hermes JavaScript engine?

No. The JavaScript engine is facebook/hermes, built for React Native. Hermes Agent is NousResearch/hermes-agent, an AI agent. They share only a name.

Fix it without waiting for upstream

A self-improving agent installs packages, writes scripts and authors skills that end up in your repositories, and its own dependency tree, plugins and skill scripts are open source components that receive CVEs like any others. Keeping those components patched is ordinary supply chain hygiene, and it applies whether the code came from a person or an agent.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos do not involve Hermes Agent. They show how Safeguard's own agent tooling handles the code and dependencies that any coding agent produces.

The first demo is a real Safeguard CLI session. Asked to "fix the lodash CVE in this repo", the assistant reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. That ask-before-each-command pattern is the same discipline this guide recommends for any agent that edits a repository.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server, installed from Claude's connector directory, with OAuth, and shows how you choose which tools Claude can use. Safeguard's MCP server offers hundreds of tools; choosing a small set per assistant is the same least-privilege habit that applies to every MCP server you give an agent.

Click through it at your own pace, or open it full screen.

The third demo sets up the Safeguard runner on your own machine, approves it with a device code and scans from the terminal. Scanning locally is a quick way to check a repository an agent has been working in before you open a pull request.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard and read the CLI docs.

Quick check

Sources

• NousResearch/hermes-agent repository (GitHub API metadata)
• Hermes Agent README
• Hermes Agent LICENSE
• Hermes Agent releases (GitHub)
• Hermes Agent docs: Persistent Memory
• Hermes Agent docs: Skills System
• Hermes Agent docs: Security
• Hermes Agent docs: Architecture
• Hermes Agent docs: MCP
• Nous Research homepage
• Nous Research releases
• Hermes 3 Technical Report, arXiv 2408.11857
• Hermes 4 Technical Report, arXiv 2508.18255
• Hermes 4.3 36B model card (Hugging Face)
• Nous-Hermes-13b (Hugging Face)
• Hermes-2-Pro-Mistral-7B (Hugging Face)
• vLLM docs: Tool Calling
• Agent Skills specification (agentskills.io)
• Model Context Protocol specification
• CVE-2026-71963 (CVE.org)
• CVE-2026-85105 (CVE.org)
• facebook/hermes README
• informalsystems/hermes README

Last reviewed: 23 October 2026. Hermes Agent ships several releases a week; check the project's releases page and docs for the current version and defaults before relying on any setting above.