Every other agent forgets. This one grows.
It's 3am. Your laptop is idle. No terminal is open. No prompt is waiting.
And somewhere inside ~/.hermes/skills/, a daemon just woke up.
It's reading through every task your agent completed this week — every tool call, every failure, every correction, every workaround. It's grading them. Consolidating the ones that overlap. Pruning the ones that underperformed. Writing new procedural memory files from scratch.
You didn't ask it to. You didn't schedule it. It just happens — every seven days — like clockwork.
By morning, your agent is measurably better at your codebase than it was yesterday. And you were asleep the entire time.
This is the Hermes Agent. And it's the first open-source runtime I've encountered that doesn't just execute intelligence — it accumulates it.
The Problem Every Other Agent Has
Here's the dirty secret of most agentic frameworks: they're amnesiac by design.
You give the agent a complex task. It struggles, recovers, finds a workaround, completes it. You feel good. You close the terminal.
Next time you run the same class of task? It starts from zero. The workaround is gone. The hard-won recovery pattern — vanished. The agent will struggle through the exact same failure mode it navigated last Tuesday, because nothing in the architecture captured what it learned.
This isn't a bug in most frameworks. It's a philosophical choice: keep the agent stateless, keep it predictable, keep it simple. The problem is that "simple" compounds into "perpetually mediocre." You're not running an agent that gets better. You're running a very expensive for loop.
Hermes made a different choice. Its entire architecture is built around a single question: what if the agent remembered — and what if the act of remembering made it smarter?
The Heartbeat: Observe, Execute, Reflect, Crystallize
Most agent frameworks have a loop. Input → Plan → Tool Call → Output. Repeat.
Hermes has a heartbeat.
The four-phase OERC cycle isn't just an execution pattern — it's a learning metabolism. Each phase has a distinct biological analog, and understanding them is the key to understanding why Hermes behaves the way it does.
┌─────────────────────────────────────────────────────────┐
│ THE HERMES LEARNING HEARTBEAT │
│ │
│ OBSERVE ──► EXECUTE ──► REFLECT ──► CRYSTALLIZE │
│ │ │ │ │
│ Scan skills Run GEPA Write SKILL.md │
│ FTS5 lookup self-analysis to ~/.hermes/ │
│ ~20 tokens/skill on trace skills/ │
│ │ │ │ │
│ "What do I "Why did "Next time, │
│ already know?" that work?" I'll know." │
└─────────────────────────────────────────────────────────┘
Observe — Before executing anything, the agent scans its local SQLite database using FTS5 full-text search to find skills that match the incoming task. Critically, it only loads Level-0 summaries at this stage — roughly 20 tokens per skill — so it can survey thousands of procedures without bloating its context window. It enters the execution phase already knowing what it knows.
Execute — The agent runs its tool-calling loop, dispatching up to 8 tools in parallel via a localized thread pool. Every terminal command, every API response, every correction is captured in a detailed execution trace. The agent isn't just doing the work — it's recording a complete transcript of how it did the work.
Reflect — This is where it gets interesting. After a sufficiently complex task (typically 5+ tool calls), GEPA — a Genetic-Pareto Prompt Evolution system running alongside DSPy — analyzes the execution trace. It identifies the failure points. It models why the recovery worked. It generates optimized guidelines, documents common pitfalls, and drafts verification steps. Crucially, this reflection runs in a background thread — it doesn't make you wait.
Crystallize — The reflection output is compiled into a structured Markdown skill file and written to ~/.hermes/skills/. It's indexed at Level 1, ready to be surfaced in the Observe phase of the next session. The loop closes. The knowledge persists.
This is how muscle memory works in humans. You struggle through a new motor pattern consciously, repeatedly, until the motion becomes automatic and sub-cortical. Hermes does the same thing — except it crystallizes in one pass, not ten thousand.
The Three-Layer Brain
If the OERC cycle is the heartbeat, the memory architecture is the brain. And it's structured with a specificity that most frameworks don't come close to.
| Memory Layer | Human Analog | Location | Size Cap | Behavior |
|---|---|---|---|---|
| L1: Session Context | Working Memory | Volatile RAM | Model context window | Cleared on /reset
|
| L2: Persistent Store | Episodic Memory | ~/.hermes/memories/MEMORY.md |
~2,200 chars / ~800 tokens | Locked into system prompt prefix at session start |
| L3: User Model | Autobiographical Self | ~/.hermes/memories/USER.md |
~1,375 chars / ~500 tokens | Embedded in System Slot #1; updated in background |
| Procedural | Muscle Memory | ~/.hermes/skills/ |
15 KiB per file | Loaded dynamically via progressive disclosure |
The size caps aren't arbitrary. They're a deliberate architectural decision to prevent what the Hermes team calls "prompt degradation" — the phenomenon where too much injected context starts hurting model performance instead of helping it. Every cap is the result of empirical testing on where the signal-to-noise ratio flips.
The USER.md file is the layer that tends to surprise people the most. It's not just a config file — it's a live model of you. Your coding style. Your preferred abstractions. Your tolerance for verbose output. The Honcho dialectic system periodically rewrites it based on observed interaction patterns. Over weeks of use, the agent stops feeling like a generic assistant and starts feeling like something that's been working with you specifically.
And the retrieval is fast — SQLite FTS5 scanning thousands of historical conversations in under 10 milliseconds. There's no vector embedding server to run, no semantic search latency to absorb. It's just a very well-engineered SQLite database doing what SQLite does best.
The Immune System: Why Subagent Constraints Are the Feature
When Hermes delegates a task to a subagent, that subagent runs in a fresh, isolated workspace with its own conversational context. Importantly, it operates under four hard constraints:
- No spawning subagents — unless explicitly assigned the "orchestrator" role
- No user interaction — subagents cannot prompt you for input
-
No shared memory writes — blocked from writing to
MEMORY.mdorUSER.md - Sequential code execution — no recursive script injection Most developers see this list and think "limitations." That's the wrong read.
These constraints are a security immune system. When you're running autonomous agents against your actual codebase — at 3am, while you sleep — you want hard walls between parallel execution threads. A subagent that can spawn children can create exponential resource consumption. A subagent that can write to shared memory can corrupt the episodic store that took weeks to accumulate. A subagent that can talk to you mid-task can create race conditions between its output and your response.
The constraints are what make the delegation trustworthy at scale.
Here's what a production parallel code review delegation looks like:
from hermes_tools import delegate_task, execute_code
def run_automated_refactor():
target_files = ["src/auth/jwt.py", "src/auth/login.py"]
# Dispatch two isolated security-focused subagents in parallel
delegate_task(
tasks=[
{
"goal": f"Analyze {target_files} for JWT validation vulnerabilities and apply fixes",
"profile": "fixer",
"context": """Project is at /workspace.
Verify signature validation and check algorithm headers.
Run pytest tests/auth/ -v after implementing changes."""
},
{
"goal": f"Analyze {target_files} for SQL injection vectors and parameterize queries",
"profile": "fixer",
"context": """Project is at /workspace.
Convert string-formatted database executions to prepared statements.
Run pytest tests/auth/ -v to verify integration."""
}
]
)
# Final validation pass
return execute_code(script="""
import subprocess
result = subprocess.run(["pytest", "tests/auth/", "-v"], capture_output=True, text=True)
print(result.stdout)
print("REFACTOR_COMPLETE_AND_VERIFIED" if result.returncode == 0 else "REFACTOR_FAILED_VALIDATION")
""")
Two subagents. Two security domains. Zero shared state. One validation pass at the end. This is the architecture of a system that's designed to be trusted in production — not just demonstrated in a keynote.
The Sandbox: Paranoid by Default
Autonomous agents executing shell commands on your machine is, frankly, terrifying if done wrong. Hermes handles this through six execution backends — Local, Docker, SSH, Daytona, Singularity, and Modal — with the Docker backend being the recommended production configuration.
The key architectural difference from naive Docker wrappers: Hermes uses a single, persistent container initialized at startup. Every command, every subagent, every code execution routes through docker exec into this one container. State persists between steps. Package installations survive across tool calls. Environment variables don't reset mid-task.
And it's hardened by default:
terminal:
backend: "docker"
docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
container_persistent: true
container_cpu: 2
container_memory: 4096
Under the hood, Hermes applies:
-
--cap-drop ALLwith onlyDAC_OVERRIDE,CHOWN, andFOWNERrestored -
--security-opt no-new-privilegesto block runtime escalation -
--pids-limit 256to neutralize fork-bomb attacks -
tmpfsmounts for/tmp(512MB) and/var/tmp(256MB) to prevent disk exhaustion The paranoia is engineered in. You don't have to configure it. It's the default.
Hermes vs. OpenClaw: A Philosophy Comparison
This isn't a "which is better" comparison. It's a "which philosophy are you choosing" comparison.
| Dimension | OpenClaw | Hermes Agent |
|---|---|---|
| Center of Gravity | Gateway-First: sessions route to a stateless agent loop | Agent-First: the cognitive loop is the core; gateways wrap it |
| Skill System | Static, human-authored files edited manually | Self-generating: OERC loop writes new skills automatically |
| Memory | Flat files + standard SQLite, manual configuration | Three-layer persistent stack with FTS5, pluggable backends |
| Parallel Execution | Sequential within single thread | Native delegate_task spawning isolated parallel subagents |
| Container Model | New container per task (high init overhead, stateless) | Single persistent container (low overhead, stateful) |
| Setup Time | Under 30 minutes | 2–4 hours for full configuration |
| Annual API Cost | ~$600–$1,800 | ~$500–$1,600 (optimized via prompt caching, α≈0.90) |
The tradeoff is honest: OpenClaw is faster to set up and easier to reason about because it's simpler. Hermes requires a real configuration investment — model routing, memory setup, Docker configuration, gateway pairing. The 2–4 hour setup time is real.
But here's the question: are you building something you'll run once, or something you'll run every day?
If it's the latter — if this agent is going to touch your codebase regularly, learn your patterns, automate your recurring tasks — the investment compounds. The agent that takes 4 hours to set up on day one is measurably smarter on day 30 than the agent that took 30 minutes. Because it's been crystallizing knowledge the entire time.
The Cost Architecture: Why α≈0.90 Changes Everything
The economic model of Hermes is worth understanding before you dismiss it as "expensive self-hosted AI."
The cost formula for a single conversational turn:
C_turn = T_dynamic · R_dynamic
+ T_cached · (1-α) · R_dynamic
+ T_cached · α · R_cached
+ T_out · R_out
Where α is the prompt cache hit ratio. Hermes achieves α≈0.90 in steady-state operation — meaning 90% of input tokens hit the cache and are billed at the discounted cached rate.
This is the architectural payoff of the frozen memory layers. Because MEMORY.md and USER.md are static between updates, they sit in Anthropic's prompt cache indefinitely. The system prompt that took 1,300 tokens to construct is only billed at full price once. Every subsequent session loads it at a fraction of the cost.
For long-running, multi-hour agent operations — exactly the kind of work Hermes is designed for — this cache hit ratio is the difference between a $40 session and a $4 session.
The Curator: Cognitive Gardening
The detail about Hermes that I find most philosophically interesting is the Curator Daemon.
Every 7 days — introduced in version 0.12.0 — a background process scans your entire ~/.hermes/skills/ directory. It grades each skill against historical execution logs. It identifies skills that overlap and consolidates them. It prunes skills that underperformed or became too narrow to be useful.
No human touches this process. No one reviews the results unless they want to. The agent manages its own long-term memory hygiene.
There's a term for this in cognitive neuroscience: synaptic pruning. The human brain does something similar during sleep — eliminating weak neural connections to strengthen the ones that matter. The result is that you wake up with slightly better-consolidated memories than you had when you fell asleep.
Hermes does this to its skill library. Every week. While your machine is idle.
The practical implication: a Hermes instance you've been running for 6 months has a fundamentally different skill profile than one you deployed last week. It's been shaped by your specific tasks, your specific codebase, your specific failure patterns. It's not a generic agent anymore. It's your agent — in a way that no stateless framework can match.
Who This Is For
Hermes is not for everyone. Let me be direct about that.
If you want to run a one-shot coding task and be done — use a simpler tool. The 2–4 hour setup overhead isn't justified for occasional use.
Hermes is for the developer who:
- Has recurring workflows they're tired of re-explaining to an agent every time
- Wants their agent to get better at their specific project over time
- Is comfortable with self-hosted infrastructure and local model routing
- Trusts the Docker sandbox model and wants autonomous background execution If that's you, the architecture rewards patience. The first week, Hermes feels like any other agent. By week four, it's started to feel like something that's been paying attention.
The Quiet Provocation
I want to end on something that's been sitting with me since I went deep on this architecture.
We've spent a lot of time debating whether AI will replace developers. That's the loud conversation. It makes for good headlines.
The quieter, more interesting question is: what happens when your tools start remembering faster than you do?
You write code in a codebase for three years. You build intuitions. You know which abstractions leak, which patterns cause bugs three sprints later, which shortcuts always come back to bite you. That institutional knowledge lives in your head — and it's deeply, irreplaceably valuable.
Hermes is the first framework I've seen that's designed to accumulate that same class of knowledge. Not about code in general. About your code specifically. About your patterns, your failures, your recoveries.
The Curator Daemon pruning skill files at 3am isn't just a background process. It's the system becoming a better collaborator — specifically for you, specifically for your project, without you doing anything.
That's not a replacement. That's an apprentice that never forgets a lesson.
Getting Started
If you want to explore Hermes seriously, here's the honest path:
# Step 1: Install
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
# Step 2: Configure model routing and memory
hermes setup
# Step 3: Set up your execution backend
# Edit ~/.hermes/config.yaml — configure Docker backend, model routing
# Step 4: Run your first task and watch the skill directory afterward
hermes
# After a complex task, check: ls ~/.hermes/skills/
Budget 2–4 hours for the initial setup. It's not quick. It's worth it.
Start with a task you run regularly — code review, dependency scanning, documentation generation. After a week, look at what's been crystallized into ~/.hermes/skills/. That directory will tell you more about how the system works than any documentation.
And check back in a month. The agent you're running then won't be the same one you started with.
That's the whole point.
Written for the Hermes Agent Challenge on DEV.to.
Top comments (0)