Most agent frameworks forget everything between sessions. You spend twenty minutes teaching LangChain or AutoGen how to parse your data structure, close the terminal, and start from zero the next day. Hermes Agent takes a different approach: it rewrites its own skill files after every execution, accumulating procedural knowledge over time.
A seven-day experiment running the same research-aggregation task daily produced a skill file that grew from 12 lines to 60 lines. The Day 7 version handled edge cases, optimized API calls, and structured output in ways the Day 1 version never attempted. This is not fine-tuning or RAG. This is self-modifying code with persistence.
What Hermes Actually Persists
Hermes stores skills as executable Python functions in a local directory. After each task, the agent reflects on what worked, what failed, and what could be optimized. It then rewrites the skill file and commits it to disk.
The persistence mechanism is file-based:
- Skill files live in
~/.hermes/skills/as.pymodules - Execution logs capture tool calls, errors, and latency
- Reflection prompts trigger rewrites when error thresholds are crossed or when the agent detects repeated inefficiency
No vector database. No external memory service. Just Python files that evolve.
The Seven-Day Mutation Path
The task: scan HackerNews, arXiv, and GitHub every morning for relevant AI research, then output a ranked list of three items.
Day 1: The agent wrote a 12-line skill that made sequential HTTP requests, parsed HTML with BeautifulSoup, and returned raw JSON. No error handling. No caching. No ranking logic.
Day 3: The skill file added retry logic after a GitHub rate-limit failure. It also started filtering results by keyword relevance before ranking.
Day 5: The agent introduced parallel requests using asyncio after noticing that sequential fetches took 18 seconds. It also cached arXiv responses for 6 hours to avoid redundant API calls.
Day 7: The skill file now included:
- Exponential backoff for rate limits
- A scoring function that weighted recency, GitHub stars, and HackerNews upvotes
- Structured output with source attribution
- A fallback to cached results if all APIs failed
The Day 7 file was 60 lines. The Day 1 file was 12. The agent had rewritten itself five times.
Architecture: How Skill Rewrites Happen
Hermes uses a reflection loop after every task execution:
- Execute: The agent runs the current skill file and logs all tool calls, errors, and latency.
- Reflect: A separate LLM call analyzes the execution log and generates a critique.
- Rewrite: If the critique identifies improvements, the agent generates a new version of the skill file.
- Test: The new skill runs a validation pass against cached inputs. If it fails, the agent rolls back to the previous version.
- Commit: The validated skill replaces the old file on disk.
The rollback mechanism is critical. Without it, a bad rewrite could brick the agent. Hermes keeps the last three versions of each skill in a .backup/ directory and reverts if the new version increases error rate or latency by more than 20%.
State Management and Context Carryover
The agent does not re-initialize from scratch each day. It loads:
- Skill files from
~/.hermes/skills/ - Execution history from
~/.hermes/logs/(last 50 runs) - Reflection summaries from
~/.hermes/reflections/(last 10 rewrites)
This means the Day 7 agent has access to every failure, every optimization, and every edge case it encountered over the previous six days. The reflection summaries are plain-text Markdown files that the LLM reads as context before generating a new skill version.
The token budget for reflection is capped at 8,000 tokens. If the execution log exceeds this, Hermes summarizes it using a separate compression pass before feeding it to the reflection prompt.
Observability Gaps
The experiment exposed three blind spots:
-
No diff tracking: The agent logs that it rewrote a skill, but it does not store a line-by-line diff. Debugging why a rewrite degraded performance requires manually comparing backup files.
-
No confidence scoring: The agent does not estimate how confident it is in a rewrite. A 10% performance improvement and a 200% improvement both trigger the same commit logic.
-
No human approval gate: The agent rewrites and commits automatically. If you want to review changes before they go live, you need to add a manual approval step in the orchestration layer.
Failure Modes
Three failure patterns emerged during the seven-day run:
| Failure Mode | Trigger | Impact | Mitigation |
|---|---|---|---|
| Overfitting | Agent optimizes for a specific edge case that only appeared once | Skill becomes brittle and fails on normal inputs | Rollback after validation pass detects increased error rate |
| Skill bloat | Agent adds redundant error handling for every possible failure | Skill file grows to 200+ lines, slowing execution | Token budget cap forces the agent to refactor or split skills |
| Reflection loop | Agent rewrites a skill, the rewrite fails, the reflection blames the rewrite logic, triggering another rewrite | Agent gets stuck rewriting the same skill repeatedly | Circuit breaker: if a skill is rewritten more than twice in 24 hours, lock it for manual review |
The overfitting case happened on Day 4. The agent encountered a malformed JSON response from HackerNews and added a 15-line parser for that specific structure. The next day, normal responses failed. The rollback mechanism caught it, but the agent wasted 12 minutes on the bad rewrite.
Code: Reflection Prompt Structure
Hermes uses a structured reflection prompt that separates critique from code generation:
reflection_prompt = f"""
You are reviewing the execution of skill: {skill_name}
## Execution Log
{execution_log}
## Current Skill Code
{current_skill_code}
## Task
1. Identify failures, inefficiencies, or missing edge cases.
2. Propose specific improvements (do not rewrite the entire skill).
3. Estimate the performance impact of each improvement.
Return JSON:
{{
"critique": "string",
"improvements": [
{{"description": "string", "estimated_impact": "low|medium|high"}}
],
"rewrite_recommended": bool
}}
"""If rewrite_recommended is true, a second LLM call generates the new skill code. The two-phase design prevents the agent from rewriting prematurely.
Deployment Shape
Hermes runs as a local daemon, not a cloud service. The skill files, logs, and reflections live on the same machine where the agent executes. This has implications:
- No multi-agent coordination: Each Hermes instance evolves independently. If you run two instances on different machines, their skill files will diverge.
- No centralized skill registry: You cannot share skills across agents without manually copying files.
- No version control integration: The agent does not commit skill changes to Git. You need to add a post-commit hook if you want version history.
For production deployments, you would wrap Hermes in a container and mount ~/.hermes/ as a persistent volume. If the container restarts, the agent resumes with the latest skill files.
When Skill Evolution Breaks Down
The seven-day experiment worked because the task was stable. The agent scanned the same three sources every day, and the output format never changed. If the task had shifted halfway through (e.g., “now also scan Reddit”), the agent would have rewritten the skill from scratch, losing all accumulated optimizations.
Skill evolution also assumes that the task is repeatable. If you run Hermes on one-off tasks (e.g., “analyze this CSV file”), the agent will rewrite the skill after every execution, but the rewrites will not compound. You end up with a skill file optimized for the last task, not the task category.
The sweet spot: tasks that repeat daily or weekly with minor variations. Research aggregation, data pipeline monitoring, financial report generation, or API health checks.
Technical Verdict
Use Hermes when:
- You have a recurring task that runs at least once per day
- The task involves multiple API calls or data sources that could be optimized
- You want the agent to learn from failures without manual retraining
- You can tolerate occasional rollbacks when a rewrite degrades performance
Avoid Hermes when:
- Your tasks are one-off or highly variable
- You need deterministic behavior (skill rewrites introduce non-determinism)
- You require multi-agent coordination or centralized skill management
- You cannot afford the token budget for daily reflection passes (8,000 tokens per rewrite)
The Day 7 skill file was objectively better than Day 1: faster, more robust, and better at ranking results. But the path from Day 1 to Day 7 included two rollbacks and one overfitting incident. Skill evolution is not free. It trades determinism for adaptability.