Hermes Agent v0.2.0 Is Out. Here's What I'd Actually Use It For

Nous Research tagged Hermes Agent v0.2.0 on March 12, and it’s a much bigger drop than the version number suggests. The release notes call it the first tagged release since the pre-public v0.1.0, and it rolls up 216 merged pull requests from 63 contributors. That’s a lot of motion for an open source agent that was mostly an internal project a few weeks ago.

Feature lists are easy to skim and hard to picture, so instead of walking through every checkbox I want to talk about the handful of jobs where this thing is genuinely useful today, and the settings you should understand before you let it loose.

A briefing that shows up on its own

The most immediately useful thing Hermes does is run work on a schedule without you sitting there. The scheduler lives inside the gateway process, which is the long running piece that also connects Hermes to chat apps. Every 60 seconds it checks ~/.hermes/cron/jobs.json for anything due and runs each job in its own isolated agent session. You can run the gateway in the foreground with hermes gateway, but for something you want running every morning the docs recommend installing it as a system service with hermes gateway install.

The project ships a daily briefing tutorial that’s a good template for this. You can literally ask for it in plain English (“every morning at 8am, find the latest news on X and send me a summary”) and Hermes creates the job, or you can be explicit with a cron expression:

/cron add "0 8 * * *" "Search the web for news about open source LLMs from the past 24 hours and summarize the top 3 stories with links."

Two details matter here. First, the web search in that tutorial runs through Firecrawl, so you need a FIRECRAWL_API_KEY set. Second, and this is the one that trips people up, a scheduled job starts in a completely fresh session. It doesn’t remember the conversation where you set it up, so the prompt has to stand on its own with every bit of context the job needs. By default, results go back to the chat where you created the job, and jobs created from the CLI save their output to ~/.hermes/cron/output/ instead.

Swap “news” for “check my staging server and tell me if anything looks off” or “summarize yesterday’s open issues on this repo” and you’ve got a pretty handy little ops assistant that costs you nothing but model tokens.

A shared assistant for a small team

The gateway in v0.2.0 speaks Telegram, Discord, Slack, WhatsApp, Signal, email and Home Assistant, and every person who messages the bot gets their own conversation context. The team Telegram tutorial walks through putting Hermes on a server so a few people can DM it for code help, research, or quick sysadmin tasks.

This is where you want to slow down, because a chat bot with terminal access is only as safe as the list of people allowed to talk to it. The simple approach is an allowlist of Telegram user IDs in TELEGRAM_ALLOWED_USERS. The nicer approach is DM pairing. When someone who isn’t on the list messages the bot, it replies with a one time pairing code, and you approve that person from the server with hermes pairing approve telegram <code>. Revoking access later is just as easy with hermes pairing revoke. I like pairing for teams because nobody has to go dig up numeric user IDs, and you still stay in control of who gets in.

Letting it touch a repo without getting nervous

Two of the v0.2.0 headliners are about making it safe to point an agent at real code, and honestly these are the features that would get me to use it on my own projects.

The first is git worktree isolation. Run hermes -w inside a repository and Hermes creates a separate worktree under .worktrees/ on its own branch (named like hermes/hermes-<id>), then does all its editing there instead of in your checkout. That means you can run a couple of sessions against the same repo in parallel without them stepping on each other or on you. When you exit, a worktree with uncommitted changes is left alone so you can look at it. A clean one gets removed, and in the v0.2.0 code its branch is force deleted too, so if the agent committed something you want to keep, merge or push that branch before you quit.

The second is filesystem checkpoints. Start with hermes --checkpoints (or set checkpoints.enabled: true in ~/.hermes/config.yaml) and Hermes takes a snapshot at the start of each conversation turn, right before the first write_file or patch call. The snapshots live in a shadow git repository under ~/.hermes/checkpoints/, completely separate from your project’s own git history. If a change goes sideways, /rollback lists the checkpoints and /rollback 1 restores the most recent one, and Hermes saves a pre-rollback snapshot first so even the undo can be undone. The checkpoints docs cover the details, including the default cap of 50 snapshots per directory.

Put those together and you get a workflow that feels a lot less like handing your laptop to a stranger. The agent works on a throwaway branch, every turn has a restore point, and you decide what actually lands.

Plugging it into the tools you already have

If you want Hermes to reach systems it doesn’t know about out of the box, v0.2.0 ships a native client for the Model Context Protocol. You add servers under mcp_servers in ~/.hermes/config.yaml, and both local stdio servers and remote HTTP servers work, so anything with an MCP server (a database, GitHub, an internal API) becomes a set of tools the agent can call.

The release also adds an ACP server, which the notes describe as editor integration for VS Code, Zed and JetBrains, so you can talk to Hermes from inside your editor instead of a separate terminal.

And if you’d rather build Hermes into your own scripts than chat with it, the Python library guide shows how small that can be. Install it with pip install git+https://github.com/NousResearch/hermes-agent.git and then:

from run_agent import AIAgent

agent = AIAgent(model="anthropic/claude-sonnet-4", quiet_mode=True)
print(agent.chat("Summarize the open TODOs in this project"))

The chat() call handles the whole tool loop and hands you back the final text. Keep quiet_mode=True when you embed it, otherwise it prints all its terminal spinners and progress output into your app’s logs.

The approval prompt is your friend

Out of the box Hermes watches for dangerous shell commands and stops to ask before running them. Recursive deletes, chmod 777, mkfs, DROP TABLE, a DELETE FROM with no WHERE, and piping curl output straight into a shell all trigger it. In the terminal you get a prompt to allow it once, allow it for the rest of the session, allow it permanently, or deny it, and deny is the default if you just hit Enter. Over chat, the bot sends you the command and waits for you to reply with something like “yes” or “approve”.

The catch worth knowing about is near the bottom of the security docs. When commands run in a Docker, Singularity, Modal or Daytona backend, those checks are skipped because the container is treated as the security boundary. That’s a reasonable call, but it means the isolation is doing all the work, so if you run the gateway for a team, a container backend plus a real allowlist is the combination I’d start with. The approval prompt is great on your own machine. It’s not a substitute for deciding who gets to send the agent commands in the first place.

Getting it running

Installation is a one liner on Linux, macOS and WSL2, and the README says the installer takes care of Python, Node.js and the other dependencies so git is the only thing you need beforehand. Native Windows isn’t supported in this release, so on Windows you’ll want WSL2.

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

As with any script you pipe into a shell, give it a quick read first. After that, hermes starts a chat, hermes model picks your provider and model, and hermes setup walks through everything in one go.

My advice for a first weekend is to skip the fancy stuff. Get one normal conversation working, then try a single scheduled job that delivers somewhere you’ll actually see it, then try hermes -w --checkpoints on a repo you don’t mind experimenting with. If those three click for you, the gateway and MCP servers are where it starts to feel like a real assistant rather than a chat window.

For a v0.2.0, Hermes is surprisingly well rounded. The scheduling and repo safety features are the parts I’d reach for first, and the security defaults are sensible as long as you understand when they switch themselves off. The full docs live on the project site and the code is on GitHub.