Every chat tool resets. Hermes is a daemon that accumulates context, writes its own skills, and runs unattended while you sleep.
Every time you open a chat tool, you start from zero. You re-explain your stack. You re-explain your project history, your naming conventions, your preferences, the decision you made last week and why. The model has no memory of any of it, because session tools are designed to be stateless. That’s a product choice, not a technical constraint. And for most active-session work, it’s a reasonable one.
Hermes Agent, released by Nous Research in February 2026 under MIT, is built around the opposite premise. It runs as a persistent daemon on your own hardware. It indexes every session into a local SQLite store with full-text search. It writes reusable skill documents when it solves something hard, so the next time a similar problem comes up, it doesn’t start from scratch. The setup overhead is real. What you get in return is an agent that already knows who you are every time you open a session.
Standard chat vs. Hermes: the session inheritance model
Hermes stores all memory in a local SQLite database at ~/.hermes/state.db, indexed with FTS5 for full-text search across every session you’ve ever run. When you ask “what did we land on for the authentication schema?” it’s not searching your current context — it’s searching the actual historical record, with LLM summarisation to surface relevant cross-session context the way a good note-taking system would.
The memory is agent-curated, not a raw transcript dump. Hermes periodically reviews what it’s logged and decides what’s actually worth keeping — condensing, surfacing key decisions, archiving noise. This matters because unlimited transcript accumulation gets expensive and slow quickly; curated memory stays useful.
For teams or individuals who want deeper user modeling, there’s optional Honcho integration — “dialectic user modeling” in the project’s own framing. Instead of re-inferring your working style, your tool preferences, and your project context each session, Honcho builds and maintains a persistent model of who you are across all sessions. The result is an agent that gets progressively better at working with you specifically, not just better at generating text generally.
Zero telemetry, zero data collection. The state database, all session logs, all memories and skills — everything lives in ~/.hermes/ on your machine. Nothing leaves unless you’ve explicitly connected an external provider or messaging platform. The project is fully open-source under MIT — every line is auditable.
When Hermes solves something non-trivial, it writes a SKILL.md — a reusable, portable skill document that captures what it learned. The next time a similar problem comes up, it loads the relevant skill rather than re-solving from scratch. Skills self-improve during use, accumulate naturally as you work, and follow the open agentskills.io standard — meaning they’re portable across any Hermes instance and shareable with the community.
The skill accumulation flywheel — solved once, reused indefinitely
40+ skills ship built-in — MLOps workflows, GitHub automation, diagramming, note-taking, and more. The community skill hub at agentskills.io extends that with a one-command install. But the most useful skills are the ones the agent writes from your own work — those are calibrated to your specific stack, your naming conventions, your preferences. They’re not generic.
As a long-running instance accumulates skills, overlap and redundancy creep in. hermes curator runs background maintenance: reviewing agent-created skills, consolidating duplicates, archiving stale entries, and protecting anything you’ve pinned. Without periodic curation, a mature instance can end up with conflicting skill documents that slow retrieval and produce inconsistent behaviour. Run the curator; don’t skip it.
A single hermes gateway process serves every connected platform simultaneously — Telegram, Discord, Slack, WhatsApp, Signal, email, and roughly a dozen more. Cross-platform conversation continuity means you can start a thread on your phone via Telegram, continue it in the terminal, and pick it up in your IDE — same session memory, same context, carried across every surface.
One gateway process — eight platforms shown, twenty supported
hermes gateway setup # interactive wizard: connect Telegram, Discord, Slack, etc. hermes gateway # start the gateway process hermes gateway install # install as a systemd service (runs on reboot)
Execution environments give you control over how much isolation you want:
Direct execution on your machine. Fast, no overhead. Appropriate for trusted tasks you’d run manually.
Isolated container with read-only root filesystem, dropped capabilities, and PID limits. The right default for anything untrusted.
Execute on any remote server. Useful for scheduled tasks that touch production infrastructure without opening it to your local environment.
Cloud and HPC execution backends for compute-heavy workloads.
The scheduling system is the practical unlock. A cron job written in natural language, delivered to any connected platform, with skills attached so it doesn’t start cold. A “morning briefing to Telegram” or “nightly infrastructure health check to Slack” is a single command plus a well-scoped prompt. No script, no wrapper, no pipeline configuration.
The most important rule for cron job prompts: the prompt must contain everything the agent needs that isn’t covered by an attached skill. Vague prompts fail silently in unattended runs — there’s no one present to clarify. A well-scoped cron prompt looks like: “SSH into server 192.168.1.100 as user ‘deploy’, check if nginx is running with systemctl status nginx, and verify that https://example.com returns HTTP 200.” That’s specific enough to succeed without human input.
hermes cron listShow all scheduled jobs — status, next run, attached skills.
hermes cron createCreate a job from a natural-language prompt. Specify delivery target and attached skills.
hermes cron edit <job>Update schedule, prompt, name, delivery target, or attached skills.
hermes cron pause <job>Pause without deleting. Useful for jobs that touch live infrastructure during testing.
hermes cron run <job>Trigger immediately, outside the schedule. Test before trusting to the clock.
hermes cron remove <job>Permanently delete the job.
These tools solve different problems. The marketing language around both implies overlap that doesn’t exist in practice.
Different tools, different jobs — the honest comparison
If your need is “help me refactor this codebase right now,” Claude Code is the sharper tool. It has deeper context engineering, better real-time coding capability, and it’s purpose-built for the active-session pairing model.
Hermes is worth the setup overhead specifically for the work that currently means re-explaining your context every time you start a new session — recurring automation, multi-project context management, unattended overnight tasks. If you’re not doing that kind of work, the setup overhead doesn’t pay off. If you are, nothing else has the same architecture for it.
Recommended first run: install via the curl script, run hermes setup with whichever provider you already have credentials for, then hermes doctor to confirm a clean install. Run one plain interactive session as a smoke test before enabling the gateway or creating any cron jobs. Create exactly one low-stakes scheduled job first — a daily summary delivered to your home channel — before trusting it with anything that touches infrastructure or credentials. Let skills accumulate naturally through real use. That’s the entire point of the design.
Packer et al. · arXiv 2023
The research prototype that formalized the idea of giving LLMs a tiered memory system — main context as RAM, external storage as disk — directly influencing persistent agent design.
Anthropic · anthropic.com/research
Anthropic's published guidance on agent architecture patterns — covers memory, tool use, and orchestration with concrete implementation examples.
Brian Christian · W. W. Norton
A journalist's clear-eyed account of what it actually takes to make AI systems do what we want — grounding reading before deploying any autonomous agent.
Continue the conversation
If this changed how you think about it — or you think I'm wrong — I want to know.
Corrections, disagreements, and applications all welcome. Replies go directly to Chris.
Get in touch →THE AGENT THAT REMEMBERS
~6-8 min1× · Two speakers · tap to play