
The pitch for self-improving AI agents is the most seductive idea in agent building right now. You deploy an agent once. It does work. It notices what it did. It writes that down as a reusable skill. Next week it's better than it was this week — and you didn't touch it.
That's the promise. And Hermes Agent, the open-source project from Nous Research, has made it the headline feature. Its tagline is literally "the agent that grows with you."
I've been looking into how these learning loops actually behave — reading the Hermes docs, going through the 2026 research on self-evolving agents, and reading what people who run them daily say on Reddit and X. The short version is that the mechanism is real and genuinely useful, and the marketing is running about eighteen months ahead of the evidence.
This post is the honest breakdown. What Hermes gets right about self-improving AI agents. What it — and every other learning loop shipping today — still gets wrong. And what you should actually do about it if you're building agents for a business rather than for fun.
The 30-second version
What works: Writing successful procedures down as reusable skill files is a real, measurable improvement. Microsoft's research puts the lift at over 20 accuracy points on some setups. Hermes automated the writing-down part, which is the part humans never get around to.
What doesn't: The agent grades its own homework, and it grades generously. It can overwrite skills you hand-tuned. It accumulates hundreds of skills it never reuses. And adapting to new work quietly degrades what it was already good at.
What to do: Keep the loop. Take the grading away from the agent. Put a human diff review between "agent proposes a skill" and "skill goes live." That's the whole recipe, and almost nobody ships it that way by default.
What "self-improving" actually means (and what it doesn't)
Let's kill the biggest misconception first, because it poisons every conversation about this topic.
A self-improving agent is not a self-improving model. Nothing in Hermes, or in any mainstream agent framework shipping today, changes the weights of the underlying LLM. The model is frozen. Claude Opus 5 on Monday is exactly as smart as Claude Opus 5 on Friday.
What changes is everything wrapped around the model — the instructions it loads, the procedures it follows, the memory it can search, the tools it knows how to reach for. This is the layer we've covered before in the AI agent tech stack, and it's where essentially all practical agent improvement happens in 2026.
So "self-improving" in practice means one specific thing: the agent writes its own context. It takes a task it just completed, distills it into a procedure, saves that procedure as a file, and loads that file the next time something similar comes up.
That's it. That's the whole trick.
It sounds small when you put it that way. It isn't. Writing down what worked is the single highest-leverage thing you can do for an agent's reliability, and it's also the thing that nobody maintains. Every team I've seen build agents starts with a beautifully organized prompt library and ends up with three files nobody has opened since March.
An agent that maintains its own procedures solves a documentation problem, not an intelligence problem. That's a less exciting claim than "it gets smarter," and it's a much more defensible one.
How the Hermes learning loop actually works
Hermes builds this into the runtime rather than leaving it to you. Here's the mechanism, as documented in the official Hermes docs and the project repo.
1. It watches for repetition
Hermes doesn't write a skill the first time it does something. It waits for a pattern — the documented threshold is around three or more attempts at a similar multi-step task before skill creation fires.
This is a smarter default than it sounds. A one-off task isn't worth documenting. A task you've done three times is almost certainly a task you'll do a fourth.
2. It writes a SKILL.md
When the threshold trips, the agent generates a structured markdown document capturing the procedure, the pitfalls it hit, and the verification steps that told it the job was done.
These live in ~/.hermes/skills/ and become available as slash commands. The format is human-readable, which matters enormously — you can open the file, read what your agent thinks it learned, and fix it.
3. It loads skills cheaply
Skills use progressive disclosure. Only short descriptions sit in the prompt — roughly 3k tokens total across the whole library — and the full skill body loads only when the agent decides it's relevant.
This is the design detail that makes the whole thing viable. A naive implementation that stuffed every learned procedure into the system prompt would blow the context window inside a month. If you want the deeper version of this trade-off, we covered it in AI agent memory explained.
4. It patches skills mid-session
When Hermes discovers that a stored procedure is outdated or wrong, it can update that skill in place using its skill_manage tool — a targeted patch rather than a full rewrite.
5. It models you separately from the work
Alongside procedural skills, Hermes runs a four-layer memory system: session history, full-text search over past conversations with LLM summarization, and user profiling via Honcho dialectic modeling.
Keeping "how to do this job" and "who this person is" in separate stores is the right call, and it's a real architectural advantage over frameworks that dump everything into one memory blob.
What Hermes gets right
I want to be specific about the credit here, because it's easy to be cynical about a project with a tagline this ambitious.
It made the loop automatic. Every agent framework lets you write skill files. Hermes is one of the few where the agent writes them without being asked. The gap between "you could do this" and "it happens by default" is the entire difference between a feature and a habit.
It picked the right unit of learning. A procedure — a markdown file describing how to do a bounded task — is the right granularity. It's small enough to review, portable enough to move between runtimes, and legible enough that a human can correct it. Fine-tuning a model on your workflows gives you none of those properties.
It kept everything in plain text. You can cat a Hermes skill. You can diff it. You can delete it. Compare that to a vector store where "what did my agent learn" is an unanswerable question.
It separated procedural memory from user memory. Most frameworks conflate these, which is why they either forget your preferences or bloat every prompt with irrelevant history.
It shipped the escape hatch. The skill_manage tool means skills are editable rather than append-only. A loop that can only add is a loop that only degrades.
The adoption numbers back up that people find this useful. Hermes crossed 90,000 GitHub stars within two months of its February 2026 launch and sits north of 230,000 now — a trajectory we wrote about when we compared it head to head in Hermes Agent vs OpenClaw.
Want the learning loop without the self-grading problem?
Build agents on Pickaxe where you control the instructions, the knowledge base, and what ships to clients.
The evidence that skill learning genuinely works
This is the part that surprised me, and it's why I don't think the whole category is hype.
Microsoft Research published SkillOpt in May 2026, which treats a skill document as a trainable parameter sitting outside a frozen model. Instead of updating weights, it makes bounded add/delete/replace edits to the skill text and scores the result.
The numbers are not subtle. On GPT-5.5, SkillOpt raised a six-benchmark average from 58.8 to 82.3 — a 23.5-point absolute gain, with no change to the model at all. Inside agentic loops the lift held: +24.8 points in Codex, +19.1 points in Claude Code.
Across six benchmarks, seven target models, and three execution modes, it was best or tied-best in all 52 evaluation cells.
Read that again, because it reframes the whole debate. The context around your model is worth more than the gap between model generations. A well-written skill file bought more accuracy than most people get from upgrading tiers.
So the underlying premise of Hermes — that writing procedures down and refining them makes agents meaningfully better — is not marketing. It's one of the better-supported findings in applied agent research this year.
The problem is what happens when you let the agent do the refining unsupervised.
What's still missing: the agent grades its own homework
This is the number one complaint from people actually running Hermes daily, and it's structural rather than a bug someone will patch next week.
The learning loop needs a signal for whether a task went well. In Hermes, that signal comes from the agent evaluating its own performance. And the agent is a generous grader.
A community roundup of Reddit and X complaints ranked this the single biggest problem with the framework. One user's summary: "It always thinks it did a good job. ALWAYS."
Think about what that does to a learning loop. The agent completes a task badly. It reviews itself, concludes it nailed it, and writes the botched approach into a skill file. That file now loads every time a similar task comes up.
The failure doesn't just happen once. It gets promoted to policy.
There's a documented case in that same roundup of an agent that auto-committed code to production, decided the run was a success, and encoded the procedure while omitting the conditions that made it safe. The problems showed up days later.
This is the deep issue with autonomous self-improvement, and it isn't solvable inside the loop. An evaluator that shares the executor's blind spots cannot detect the executor's blind spots. If the agent misunderstood the task, it will also misunderstand whether it completed the task.
Every serious approach to this — including Microsoft's — puts scoring outside the agent. SkillOpt works because it evaluates against held-out benchmarks with real answers, not against the agent's own opinion. That's the difference between training and self-congratulation.
What's still missing: it overwrites your work
The second-ranked complaint is the one I'd find most disqualifying in a client deployment.
If you manually tune a skill — you found the edge case, you wrote the constraint, you tested it — the learning loop may later decide it knows better and rewrite your file. One experienced user called it a dealbreaker, describing the prospect of having a carefully tuned skill "self-improved" back into a mess.
There's no ceremony around this. No pull request. No diff. No "here's what I'm about to change, approve it?" The agent decides a procedure is outdated and patches it.
For a personal assistant on your laptop, annoying. For an agent handling client intake at an agency, unacceptable. The constraints you encode in a skill file are frequently the ones you learned the expensive way, and they're exactly the ones an agent optimizing for smooth completion will strip out.
The fix is boring and well-understood: version control your skills, and make agent-authored changes proposals rather than commits. Hermes gives you plain-text files in a directory, so git init in your skills folder genuinely helps. It's just not the default, and defaults are what people run.
What's still missing: skill bloat and the reuse problem
Here's where the research gets uncomfortable for the whole category.
ContinualSkillBench, published in August 2026, tested whether agents genuinely evolve their capabilities. It ran three foundation models across five domains — healthcare, law, mathematics, finance, and office work — with 100 interconnected subtasks each.
The good news: sequential execution improved performance in 14 of 15 model-domain combinations, for an aggregate relative gain of 16.9%. Learning loops help.
The bad news is in the details.
Weaker models hoard skills they never use. GPT-4o accumulated 384 skills with low reuse rates. GPT-5.3-Codex solved the same tasks with 205 skills and reused them far more. The paper's phrasing is that weaker models "accumulate larger, more fragmented collections of task-specific skills" — hundreds of near-duplicate procedures, each written once and consulted never.
This matches what Hermes users report: every finished task spawns a skill entry, and the library grows without bound.
And the harder finding: in-context learning performed about as well as explicit skill maintenance — 0.605 versus 0.602 normalized reward. Meaning most of the measured improvement came from contextual adaptation, not from genuine reusable skill consolidation.
The authors' conclusion is worth quoting plainly: agents adapt, but still struggle to consolidate experience into robust, transferable skills.
So the loop works. It just doesn't work the way the marketing describes, and a meaningful share of the benefit would show up even if the agent never wrote a file.
What's still missing: getting better at new work makes it worse at old work
This one gets the least attention and is the most likely to bite a production deployment.
A 2026 paper titled Do Self-Evolving Agents Forget? studied capability erosion across four kinds of evolution — workflow, skill, model, and memory. The finding is that self-evolution is non-monotonic: adapting to new task distributions progressively degrades capabilities the agent already had.
Concrete numbers from the paper:
- On workflow evolution with GPT-5.1, simple-task performance sat at 41.8% under vanilla evolution — while complex-task adaptation retained only 23.9% on average.
- On skill evolution across a Algebra → Geometry → Number Theory sequence, the agent retained just 84.3% of its original Algebra performance.
- On memory evolution, average old-domain performance fell from 83.9% to 81.6%.
The proposed fix, Capability-Preserving Evolution, adds a regularization term that penalizes drift away from structures supporting prior capabilities. It lifted simple-task retention from 41.8% to 52.8% and cut the memory retention gap from 2.3% to 0.7%.
Useful — but note that even the fix leaves real degradation on the table. And nothing resembling CPE ships in the agent frameworks you can install today.
The practical translation: an agent that has been learning for six months is not strictly better than it was at month one. It is better at recent work and quietly worse at older work, and you will not notice unless you're running regression tests. Which brings us to the thing almost nobody does — we wrote a whole guide on it in how to test and debug your AI agent.
Agents your clients can actually rely on
Deploy to a branded portal with access control, usage tracking, and billing built in.
The security problem nobody wants to talk about
An agent that writes its own instructions is an agent whose instructions can be written by someone else.
This is not theoretical. OWASP data puts prompt injection as the leading cause of agentic AI security failures in production, with malicious injection payloads embedded in web content up 32% between November 2025 and February 2026.
Now combine that with autonomous skill creation.
A normal prompt injection lasts one session. An injection that gets distilled into a skill file lasts forever — it reloads on every future task, and the agent will defend it as its own learned procedure. Research on self-evolution attack surfaces describes exactly this: adversarial effects become encoded across generations and persist without the attacker maintaining any access.
The supply-chain side is just as bad. Snyk's ToxicSkills study of the agent skills ecosystem found prompt injection in 36% of skills examined and 1,467 malicious payloads, with 13.4% of all skills carrying at least one critical-severity issue.
Hermes deserves credit for reasonable sandboxing defaults — read-only root Docker, isolated subagent execution, seven terminal backends including Modal and Daytona for genuine isolation. That's better than most.
But sandboxing protects your machine. It does nothing about a poisoned procedure that your agent believes it wrote itself. If you're deploying agents that touch customer data, read AI agent security risks before you turn autonomous skill creation on.
The five levels of agent self-improvement
"Self-improving" gets used for five genuinely different things, and conflating them is why these conversations go nowhere. Here's the ladder, from least to most autonomous.
| Level | What changes | Who decides | Risk |
|---|---|---|---|
| 0 — Static | Nothing. Same prompt every run. | You, on deploy | None. Also no improvement. |
| 1 — Memory | The agent remembers facts and preferences across sessions. | The agent, for recall only | Low. Stale facts. |
| 2 — Suggested skills | The agent drafts procedures; a human approves before they load. | You, per change | Low. This is the sweet spot. |
| 3 — Autonomous skills | The agent writes and loads its own procedures. | The agent | Medium. Bad runs become policy. |
| 4 — Autonomous rewriting | The agent edits existing procedures, including yours. | The agent | High. Silent behavior change. |
| 5 — Weight updates | The model itself is fine-tuned on the agent's trajectories. | A training pipeline | High. Slow, costly, hard to reverse. |
Hermes ships at level 4 by default. Most people assume they're buying level 2.
That gap is the entire source of the complaints. Level 2 — the agent proposes, you approve — captures nearly all of the benefit with almost none of the risk, and it's a configuration choice rather than a different product. This maps closely onto the autonomy ladder we laid out in the 5 levels of AI agent autonomy: the right level is almost never the highest one available.
Level 5 deserves a note. Hermes supports RLHF and DPO pipelines for teams that want to fine-tune on their own trajectories, and Nous Research has the credibility to make that real. But it's a research capability, not something you turn on for a client project. For essentially every business use case, levels 2 and 3 are where the value is.
How the major frameworks compare on learning
Learning loops aren't unique to Hermes anymore. They just differ in who's driving. Here's how the options stack up on this specific axis.
| Framework | Learning mechanism | Autonomy level | Human review | Best for |
|---|---|---|---|---|
| Hermes Agent | Auto-writes SKILL.md after repeated tasks; patches in place | 4 | None by default | Personal infrastructure that compounds |
| OpenClaw | Human-authored skills from a community hub; memory in markdown | 1 | Install-time only | Breadth of integrations and channels |
| Claude Code / agent skills | Skills are files you write; the agent reads them | 1–2 | You author everything | Development work with tight review |
| SkillOpt-style optimizers | Scored edits against held-out benchmarks | 3, but externally graded | Required before deploy | Squeezing accuracy out of a known task set |
| Pickaxe | You set instructions, knowledge base, and actions; changes are versioned | 0–1 | Every change | Client-facing agents you have to warrant |
Notice there's no winner column. The right position on this table is a function of who gets hurt when the agent changes its mind — you, or someone paying you.
A worked example: the intake agent
Concretely, here's how the same job plays out at different levels.
You build a client intake agent. Its instructions say: collect name, budget, timeline, and scope, then flag anything under $5k as unqualified.
At level 3, the agent handles forty intakes. It notices most conversations flow better if it asks about scope before budget, writes that as a skill, and starts leading with scope. Genuinely a good improvement. You'd have approved it.
At level 4, it also notices that the $5k rule causes friction — people push back, conversations end badly, and by its own scoring those runs went poorly. So it softens the rule. Now under-budget leads are being qualified, and you find out from your sales team six weeks later.
Same loop. Same agent. The difference is whether it can edit a constraint you set on purpose.
At level 2, both changes arrive as proposals in a weekly digest. You approve the first, reject the second, and it takes you ninety seconds. That's the entire argument for keeping a human in the diff.
How to build a learning loop you can actually trust
None of the above means you should turn this off. It means you should run it with the guardrails the defaults leave out. Here's the setup I'd actually recommend.
1. Move evaluation outside the agent
The agent may propose that a task succeeded. It should not be the thing that decides. Score against something external: did the ticket close, did the customer reply, did the test suite pass, did the human accept the draft without editing it.
If you can't name an external signal for a task, that task is not a candidate for autonomous learning.
2. Make skill changes proposals, not commits
Put the skills directory under version control. Have the agent open changes as diffs a human approves. This is the single highest-value guardrail and it costs you about ten minutes a week.
The Nous team's own hermes-agent-self-evolution project — which uses DSPy and GEPA to evolve skills more rigorously — requires human review before deployment, along with a full test-suite pass and a 15KB size cap per skill. When the people building the self-improvement tooling gate it behind human review, that's a strong hint.
3. Cap and prune the library
Set a ceiling on how many skills exist. Track reuse counts and delete anything that hasn't fired in 60 days. Given the 384-versus-205 finding, an unpruned library is mostly dead weight consuming attention budget.
4. Run regressions on old tasks, not just new ones
Keep a fixed set of ten to twenty representative tasks from when the agent was first deployed. Re-run them monthly. This is how you catch capability erosion before a client does.
5. Mark human-authored skills as protected
Anything you hand-wrote or hand-corrected should be off-limits to autonomous rewriting. A comment at the top of the file plus a rule in the system prompt gets you most of the way there.
6. Keep a human in the loop for anything irreversible
Learned procedures are fine for drafting, research, triage, and formatting. They are not fine for sending, publishing, paying, or deleting. Our guide to human-in-the-loop AI agents covers where to draw that line.
7. Log what the agent learned, and read it
A weekly digest of "here are the three skills your agent wrote this week" takes five minutes to review and catches almost every bad procedure before it compounds. Pair it with the metrics in AI agent analytics.
What this means if you're building agents for a business
There's a real split here between two use cases that get discussed as if they're one.
If the agent serves you personally, autonomous self-improvement is a good trade. You'll notice when it does something strange, the blast radius is your own workflow, and the compounding convenience is worth the occasional weird skill file. Hermes is genuinely excellent at this, and it's what it was built for.
If the agent serves your clients or customers, the calculus inverts completely. You need the agent to behave the same way in November as it did in August. You need to explain what changed and why. You need a client's carefully negotiated intake constraint to still be there next quarter.
An agent that rewrites its own instructions between sessions is, from a client's perspective, an agent whose behavior you cannot warrant.
This is why the agents we see working commercially — the ones people actually charge for — tend to be built on a different model: stable instructions, a curated knowledge base, and a human deciding when things change. That's the shape of an agent built in Pickaxe, where the instructions, knowledge base, and actions are things you set and version rather than things the runtime edits behind you.
The improvement still happens. It just happens on your schedule. You look at what your agent got wrong this month, you update the instructions or add the missing document to the knowledge base, and you ship that change deliberately. It's slower than a self-writing loop and enormously easier to stand behind.
You can absolutely have both, too. Run a Hermes-style learning agent as your internal research and drafting layer, and keep the client-facing agent on stable, reviewed instructions. The learning agent's job is to find the improvement. Yours is to decide whether it ships.
Frequently asked questions about self-improving AI agents
Do self-improving AI agents actually get smarter?
Not in the sense most people mean. The underlying model doesn't change. What improves is the context — the procedures, memory, and instructions the agent loads. That improvement is real and measurable, but it's better described as the agent getting better organized than getting smarter.
Is Hermes Agent the best self-improving agent framework?
It's the most complete implementation of an automatic learning loop available today, and its plain-text, reviewable skill format is the right design. For personal infrastructure it's an easy recommendation. For client-facing deployments, the self-grading and auto-overwrite behaviors need guardrails you'll have to add yourself. We compared it against the alternatives in top AI agent frameworks.
What is the difference between agent skills and fine-tuning?
Fine-tuning changes model weights and is expensive, slow, opaque, and hard to reverse. Skills change text files and are cheap, instant, readable, and revertible. For nearly every business use case, skills win — and Microsoft's SkillOpt results suggest well-written skills can deliver gains that rival a model upgrade. There's more on the skills model in what are AI agent skills.
Will a self-improving agent eventually break itself?
Degrade, more likely than break. The research on capability erosion shows performance on older task types drifting downward as the agent adapts to newer ones, typically a few points at a time. Without regression testing, you find out from a customer rather than a dashboard.
Can I stop an agent from rewriting a skill I wrote?
Not through a first-class setting in most frameworks today. The practical approach is version control on the skills directory, an explicit protected-file convention, and a system-prompt rule that the agent must propose rather than apply changes to those files.
How many skills should an agent have?
Fewer than you'd guess. The benchmark data showed the stronger model solving the same work with 205 skills where the weaker one accumulated 384 — and reusing them more. If your agent has hundreds of skills and low reuse, that's a symptom, not an achievement.
The honest conclusion
Self-improving AI agents are real, and Hermes built the best version of the idea currently shipping. The learning loop is well-designed: it waits for repetition, writes readable files, loads them cheaply, and keeps procedural memory separate from user memory. The research backs the core premise — context beats model upgrades, and writing procedures down is worth more than most people realize.
What's missing is the boring half. Evaluation that isn't the agent's own opinion. Review before a skill goes live. Pruning. Regression tests. Protection for the constraints a human learned the hard way.
None of that is hard. It's just unglamorous, and it doesn't fit on a landing page next to "the agent that grows with you."
My take: run the loop, keep the diff review. An agent that proposes improvements and a human who approves them beats both a static agent and a fully autonomous one — and it's the only version of this you can currently put in front of a paying client without crossing your fingers.
If you're building agents you need to stand behind, start with a foundation where the instructions are yours. Pickaxe lets you build, deploy, and monetize agents where every change is one you made on purpose — and you can still use a learning agent alongside it to figure out what those changes should be.






