This is a submission for the Hermes Agent Challenge
The most expensive thing most AI agents forget is not your name. It’s the work they just did.
You let an agent spend thousands of tokens learning your environment, inspecting your repository, debugging issues, figuring out project conventions, and working through a useful engineering task—sometimes even discovering a workflow that reliably works. Then you close the session, come back the next day, and much of that context is gone. The repository is still there, but the agent has forgotten what it learned about it, how it solved the problem, and which workflow actually got the job done.
For short-lived tasks, that’s not a huge issue. If all you need is a summary, a SQL query, or a quick browser automation task, stateless execution works fine. But once agents start touching repeated engineering work, automation, or operational workflows, forcing them to rediscover the same solutions over and over becomes an expensive design flaw.
That’s what makes Hermes Agent from Nous Research interesting.
Hermes is not being pitched as just another coding copilot or a chatbot wrapper with tool access bolted on. The more ambitious idea is that successful execution should create reusable operational knowledge. If an agent solves a meaningful problem once, it should not have to relearn the same workflow from scratch the next time.
If that works reliably, it changes what open-source agents can become.
The Stateless Agent Problem
Most current agent frameworks effectively behave like this:
Goal → Plan → Tool Calls → Execute → Return Result → Forget
That lifecycle works surprisingly well—until the work becomes repetitive.
Imagine asking an agent to scan a repository, identify missing license headers, generate patches, run tests, and commit validated changes. A capable system might spend significant time inspecting the filesystem, inferring project conventions, handling failures, and refining its approach before it gets the task right.
Now run that exact same task a week later. Most agents will start from zero as though the previous execution never happened.
The same thing happens with recurring operational issues. If an agent spends twenty minutes discovering that a flaky CI failure came from one dependency mismatch and a bad environment variable, you would reasonably expect that discovery to be reusable. Instead, most systems replay the entire debugging process.
That’s the inefficiency. A human engineer would either remember the pattern or document the solution. Stateless agents generally do neither.
What Hermes Is Trying to Change
Hermes attempts to change that lifecycle by inserting a learning loop. Instead of behaving like a linear sequence, the intended model looks more like this:
Observe → Plan → Execute → Evaluate → Crystallize Skill → Reuse
The important difference is what happens after execution. Rather than treating task completion as the end of the interaction, Hermes evaluates whether the workflow it just used is worth keeping.
- Did the task succeed?
- Which actions actually mattered?
- Was the solution a one-off workaround, or does it represent a reusable operational pattern?
If the answer is yes, Hermes can retain that workflow as a reusable Skill instead of forcing the model to rediscover the same process later. That’s a much more compelling idea than simply preserving chat history.
What a Skill Actually Looks Like
“Procedural memory” sounds abstract until you think about what is actually being stored. Hermes’ approach to procedural workflows is much closer to inspectable skill artifacts than opaque memory blobs, which is a much healthier model than treating memory as hidden vendor state.
Conceptually, a crystallized skill artifact looks something like this:
# repo-license-remediation
version: 1.2
tags:
- python
- repository
- compliance
inputs:
- repo_path
- license_header
required_tools:
- filesystem
- regex_match
- file_write
- terminal
- git
steps:
1. Scan Python files
2. Detect missing headers
3. Generate patch
4. Run tests
5. Commit validated changes
This is fundamentally different from remembering prior prompts or conversation snippets. This is operational knowledge.
Remembering that I prefer concise responses is personalization. Remembering how to safely repair a repository issue is actual capability. That distinction matters.
Procedural Memory Is More Interesting Than Chat Memory
A lot of AI products advertise memory, but most of the time that means conversation continuity, user preferences, or retained prompt context. That is useful, but it does not necessarily make the system better at doing work.
The more meaningful distinction is between remembering facts and remembering procedures. Humans become effective engineers because they internalize repeatable workflows. You do not memorize every exact command forever, but you do remember how to approach a recurring integration issue or how to remediate a familiar failure pattern.
Hermes is aiming much closer to that model. Its architecture can be thought of in three distinct layers:
- Working Memory: Short-lived execution state including the current task context, temporary variables, and recent tool outputs. This is standard agent behavior.
- Episodic Memory: Longer-lived contextual recall mapping project metadata, user preferences, and prior historical decisions to improve continuity.
- Procedural Memory: The interesting layer. It stores reusable workflows like debugging routines, deployment procedures, remediation pipelines, and integration playbooks.
If this layer works well, the system improves with repetition instead of simply remembering conversations.
The Scaling Problem
Persistent procedural memory sounds great until you hit the obvious question: What happens when the agent accumulates hundreds of workflows? Dumping all of them into the context window every time would be terrible for token efficiency, latency, and reasoning quality. A staged retrieval model makes much more sense:
-
Discovery Stub (~20 tokens): Start with the minimum—just the skill name and a short description to determine relevance.
Example:
Python repository license remediation workflow Signature Layer (~200 tokens): If the workflow looks useful, retrieve expected inputs, required tools, and configuration assumptions to validate applicability.
Blueprint Layer (~1,000+ tokens): Only when the workflow is actually executed do you load the full steps, command sequences, and tool invocation logic.
This is dramatically more scalable than brute-force memory stuffing. One caveat: if you are evaluating Hermes critically, it is worth checking which parts of this are implemented exactly as described today versus which represent broader architectural direction. But conceptually, this is the right shape of solution.
Trying Hermes Yourself
Setup itself looks straightforward, but the more interesting question is not whether Hermes can run—it’s whether repeated tasks actually become smarter.
The baseline setup follows a quick terminal sequence:
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
hermes setup
hermes
Hermes also supports running beyond the terminal—across messaging interfaces and isolated execution backends—which makes the architecture feel operational rather than purely conversational.
A worthwhile test is giving it something that actually requires multi-step reasoning, like scanning a test repository, identifying missing headers, and generating a local patch. The real validation is whether the second execution feels noticeably cleaner, faster, and less wasteful.
Where Hermes Fits Compared to Other Frameworks
- LangChain: Gives developers raw building blocks and enormous flexibility. That is great if you want full architectural control, but it also means assembling everything yourself. Hermes feels more opinionated out of the box.
- AutoGen: AutoGen shines in multi-agent conversational workflows, but conversation-heavy systems can become noisy and expensive fast. Hermes feels less focused on agent dialogue and more focused on raw execution workflows.
- OpenDevin: Clearly aligned with software engineering automation and workspace environments. Hermes feels slightly broader, aiming at general operational agent behavior.
- OpenClaw: Adjacent rather than directly competitive. OpenClaw is strong around orchestration and communication routing, while Hermes is more interesting around procedural learning and self-improving execution.
Infrastructure Design Matters
A powerful agent without execution isolation is a liability. Giving unrestricted shell access to an LLM is not a serious production strategy.
Hermes supports multiple execution backends, including restricted local execution, Docker containers, SSH environments, Singularity, and remote sandbox environments like Modal. This matters because practical automation requires isolation.
A realistic workflow might involve a Slack alert triggering an isolated environment, Hermes validating deployment state, detecting a known failure pattern, applying a learned remediation workflow, and reporting back. That starts looking much less like a toy demo and much more like something operations teams could actually use.
Where This Can Go Wrong
The risks here are real:
- Skill Drift: A workflow that worked six weeks ago may be wrong today because dependencies changed, APIs evolved, or CLI flags broke. Without revalidation, procedural memory becomes stale automation debt.
- Faulty Generalization: An agent might incorrectly promote a brittle edge-case fix into a reusable standard workflow. That becomes dangerous quickly because repeated incorrect automation is often worse than forcing fresh reasoning every time.
- Security Risk: Persistent procedural memory can preserve unsafe commands, environment assumptions, or patterns that risk credential leakage. Any self-improving execution system needs strict governance.
Practical Safeguards
If anyone plans to use something like this in production, the minimum checklist probably includes:
- Human approval before newly created skills are allowed into active reuse.
- Verification across multiple successful runs before allowing autonomous reuse.
- Automated smoke testing, version control, and strict least-privilege execution boundaries.
Without those controls, procedural memory becomes accumulated operational risk instead of useful automation.
Why This Matters for Open Source
The bigger issue here is ownership.
A lot of proprietary AI systems assume persistent memory belongs inside vendor infrastructure. That creates lock-in, opaque automation logic, poor auditability, and painful migration stories.
If an open agent can retain reusable operational knowledge in inspectable, version-controlled artifacts, teams can audit agent behavior, share playbooks, migrate freely, and actually own the workflows the system learns. If your agent discovers something useful, that knowledge should live in infrastructure you control—not disappear into a hosted memory layer.
That may be the more important shift.
Discussion
- Would you trust a self-improving agent for non-critical automation today? Why or why not?
- What specific safeguards would you require before letting one touch production infrastructure?
Top comments (0)