Three weeks ago your agent nailed something hard. It debugged a flaky deploy script, figured out which environment variable was stale, fixed it, and told you exactly what it did. You were genuinely impressed. Then you opened a new session the next week and it had no idea any of that had happened. Same question, same investigation, same fix, from scratch, like the first conversation never occurred.
If you've used any LLM-based agent for more than a few sessions, you already know this feeling. It's not that the model got dumber. It's that almost nothing in the stack was built to remember anything past the current context window. Hermes Agent is the first open-source project to make a serious, structurally different bet on that problem and it's the reason it went from a GitHub repo nobody had heard of to somewhere in the neighborhood of 140,000 stars in about three months, according to multiple write-ups tracking its growth this year.
This isn't a "top 10 features" post. We're going to go properly deep on how Hermes actually works under the hood, and then spend real time on the part almost nobody explains well: what it actually takes to keep one of these things running reliably, and why that question matters more with Hermes than with most other agent frameworks.
What Hermes Agent actually is
Hermes Agent is an open-source, MIT-licensed AI agent framework built by Nous Research, first released in late February 2026. Nous is the same lab behind the Hermes, Nomos, and Psyche model families, which is a little confusing at first , the agent is named after their models, but it doesn't require you to use them. It's model-agnostic by design: point it at OpenRouter, OpenAI, Nous's own portal, or any custom OpenAI-compatible endpoint, and switch between them with one command, no redeployment needed.
The thing that actually separates it from the last few years of agent frameworks isn't the tool use or the reasoning loop, most serious frameworks have decent versions of both by now. It's that Hermes treats memory as a first-class architectural concern instead of an afterthought bolted on with a vector database. Where a typical agent resets to a blank slate every session, Hermes writes durable notes about you and your environment, converts things it figured out the hard way into reusable procedures, and can search back through its own conversation history when you reference something from before. It gets measurably less repetitive to work with the longer you run it, which is a genuinely different value proposition than "smarter model."
For context, the framework people compare it to most is OpenClaw, and the comparison is fair because the two solve overlapping problems with different priorities. OpenClaw is intentionally lean: low setup overhead, broad reactive tool use, and it leaves memory and orchestration mostly up to you. Hermes is heavier by design: more moving parts, more state to manage, but you get the learning loop, the scheduler, and the tool catalogue without building any of it yourself. If you're migrating from OpenClaw, Hermes actually detects an existing ~/.openclaw install during setup and offers to import your settings, memories, and skills automatically, which tells you something about who Nous Research expects their early adopters to be.
The memory system, properly explained
This is the part worth slowing down for, because most explanations either oversimplify it into "it has memory now" or bury the useful detail under jargon. Hermes actually runs three distinct memory mechanisms, each solving a different problem, each stored differently, and each loaded at a different point in the agent's lifecycle.
Identity comes first. Before any memory loads, Hermes reads a file called SOUL.md, stored at ~/.hermes/SOUL.md. This defines who the agent is, its personality, its operating constraints, how it should behave. It occupies the very first slot in the system prompt, ahead of everything else. Skip this file and Hermes runs with a generic persona, which is fine for a five-minute test and genuinely not fine if you're deploying something client-facing.
Durable, semantic memory comes next, split across two small files: MEMORY.md and USER.md. MEMORY.md holds environmental facts, your project structure, server conventions, tool quirks, lessons the agent learned the hard way, capped at roughly 2,200 characters. USER.md holds a profile of you specifically: communication preferences, skill level, things to avoid, capped at around 1,375 characters. Both get injected into the system prompt as a frozen snapshot at the start of a session. Here's the detail that trips people up: if the agent writes a new memory entry mid-conversation, it saves to disk immediately, but it won't actually appear in the agent's active context until the next session starts. When either file approaches its cap. Hermes shows this as a percentage in the system prompt header, around 80% is when it starts flagging, the agent has to consolidate what's there rather than just keep appending.
Episodic memory is the third layer, and it's the one doing the heavy lifting for anything you'd call "recall." It's a SQLite database with full-text search (FTS5) sitting at ~/.hermes/state.db, indexing every conversation the agent has had. When you say "we already fixed this, use the approach from last time," this is what the agent is actually querying — not a fuzzy vector similarity match, a real full-text search over its own history.
Skills are the fourth piece, though people often lump them into "memory" as a category, worth separating out because they behave differently from the other three. A skill isn't a static note, it's a procedure: a markdown file describing when to apply it, which commands or tools it needs, pitfalls to avoid, and how to verify success. Creation isn't automatic for every task. It triggers on a threshold, generally after five or more tool calls, an error recovery, or a user correction, which keeps the library from filling up with a skill document for "what day is it." Skills live in ~/.hermes/skills/ as plain, readable, editable markdown, not embeddings in a vector store you can't inspect. You can open one, read exactly what the agent decided worked, and correct it yourself if it's wrong. There's also a community skill library at agentskills.io, following an open format, so skills built for one Hermes install are at least theoretically portable to another.
Put together, this is why the framework feels different to actually use. The identity is fixed. The durable facts persist quietly in the background. The episodic layer means old conversations aren't gone, just not loaded by default. And the skill library means the tenth time you ask it to do something it's done before, it's following a runbook it wrote for itself instead of reasoning from zero.
The learning loop and the guardrails around it
None of this would be safe to leave running unattended without some limits, and Nous Research clearly built with that in mind. Every task has a hard cap of 90 turns, and subagents share that same budget rather than getting their own, which stops a runaway retry loop (a failing API call, the same file read over and over) from silently burning through your provider credits. There's also a specific, slightly funny safety rule: a session started by a scheduled cron job is not allowed to create new cron jobs. It sounds narrow, but it closes off a very real failure mode where a scheduled task could, in principle, spawn more scheduled tasks indefinitely.
The toolkit itself ships with 40-plus built-in tools out of the box, web search, terminal access, browser automation, vision, image generation, code execution, and subagent delegation for splitting a task across multiple sub-agents. The browser tooling is worth a specific mention: instead of handing the model raw HTML, Hermes represents pages as accessibility trees, which is a much easier structure for a language model to reason about and click through reliably. It supports both cloud browser providers like Browserbase and a local Chrome or Chromium instance.
Where it actually runs: the six terminal backends
This is where Hermes starts looking less like a chatbot framework and more like real infrastructure tooling, and it's the part most "what is Hermes" explainers skip entirely. Hermes supports six different terminal backends, and picking the right one matters more than the setup guides usually let on.
Local
— commands run directly on the host machine. Simplest option, and the riskiest if you're running untrusted skills.
Docker
— every command executes inside an isolated, persistent container that survives across tool calls and subagents for the life of the process. This is the recommended default for anything production-facing, specifically because it isolates the agent from the rest of your system.
SSH
— routes tool calls to a remote machine over SSH. Useful if you want Hermes managing a server that isn't the one it's running on.
Singularity
— built for university and research-lab clusters that use Singularity/Apptainer instead of Docker, submitting jobs to a cluster scheduler.
The official installer is a single command from Nous Research's own domain (curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash, with a PowerShell equivalent for native Windows), and it quietly handles the dependency chain for you, Python via uv, Node.js, ripgrep, ffmpeg, and an isolated Git Bash on Windows. The messaging side connects through a single gateway process that can talk to Telegram, Discord, Slack, WhatsApp, Signal, and email simultaneously, so the agent doesn't live in only one place.
The infrastructure question nobody's install guide really answers
Here's the thing almost every Hermes tutorial gets right on the mechanics and skips on the reasoning: they all start with "get a VPS," and none of them really explain why that step isn't optional the way it might be for a simpler tool.
Go back to the memory architecture for a second. The entire value proposition: durable notes, a skill library that compounds, episodic recall, only works if the process stays alive between sessions. Run Hermes on your laptop and close the lid, and you haven't paused the agent, you've killed it. The gateway drops, scheduled cron jobs stop firing, and nothing that was supposed to happen while you were away, happens. This is architecturally different from a stateless chatbot, where closing the tab genuinely doesn't matter because there was no continuity to lose in the first place. With Hermes, closing the laptop is the one thing that breaks the entire pitch.
That's why every serious setup guide converges on the same starting point: a small VPS, usually with Docker, running as a systemd service or with a Docker restart policy, so a crash or a host reboot brings the agent straight back up instead of leaving it dead until someone notices. The resource footprint is genuinely modest if you're calling a cloud model API: something in the range of 1–2 vCPU and 1–4GB of RAM is enough for most setups, per the several independent installation guides that walk through this. It only climbs meaningfully if you're running local inference through Ollama or a similar backend, where you're looking at 8–16GB depending on model size and quantization, since now the box is doing the reasoning as well as hosting the agent.
A few failure modes come up often enough across different write-ups that they're worth calling out directly, because they're the kind of thing that looks like "Hermes is broken" when it's actually a deployment mistake:
Forgetting to mount the data directory as a persistent volume.
If you're running Hermes in Docker and the
~/.hermesdirectory isn't mounted to storage that survives outside the container, every restart wipes memory, skills, and configuration back to zero. This is, by a wide margin, the most commonly reported "why did my agent forget everything" complaint, and it's almost never actually a memory-system bug.Skipping SOUL.md.
The agent still runs, just with a flat, generic personality, fine for a quick test, not what you want live.
No backup routine for the memory and skills directories.
If an agent has been running and learning for six months and you lose the underlying disk, you've lost six months of accumulated context, not just a config file. A simple periodic git-based backup of the data directory is the recommendation that comes up again and again across different setup guides, and it's worth taking seriously before you need it rather than after.
Exposed API keys and open terminal backends.
Running the local terminal backend directly on a public-facing VPS, rather than sandboxing commands in Docker, means anything the agent executes touches your actual system. Worth locking down before the agent is reachable from Telegram or any other public channel.
None of this is a knock on Hermes specifically — it's just what "self-hosted and always-on" actually means once you get past the install script. And it's exactly why a small category of managed hosting options has started showing up around Hermes over the past few months, aimed at people who want the always-on behavior without personally owning the VPS, the restart policy, the backup cron, and the security hardening. We're one of the newer entrants there — Tower runs Hermes as a managed runtime, meaning the compute, persistent storage, restarts, and backups are handled for you, and you're not choosing between "leave my laptop on" and "learn to administer a Linux server." That's not the only way to run Hermes, and depending on what you're building, self-hosting on your own VPS might genuinely be the better call — the point of this section is to make sure you're choosing deliberately, not defaulting to whichever path you found first.
The honest takeaway
Hermes isn't magic, and it isn't a smarter model wearing a new interface. It's the same models everyone already has access to, wrapped in an unusually deliberate architecture for making them stop forgetting things. Whether that's worth the extra operational weight compared to something leaner depends entirely on what you're building. A quick internal script probably doesn't need a skill library and a 90-turn safety net. Something you're planning to have running for months, handling real conversations across Telegram or Slack, absolutely does.
The part worth internalizing before you deploy anything, though, is the one thing this whole framework is quietly built around: none of it works if the process isn't alive. Get the infrastructure decision right first, wherever you land on it. And the memory system actually gets to do the job it was designed for.