Self-Improving Agent Frameworks Compared by Approach

Self-improving agent frameworks differ mainly in what they rewrite: the agent's working context, a memory file, a skill folder, a prompt program, its own source code, or model weights. Each approach pairs that artifact with an evaluator, from self-critique to unit tests to a human approval, and the artifact decides how you review and roll it back.

An agent that saves a Markdown note and one that edits its own Python code are both called self-improving, but they need very different controls. This post sorts the published approaches and the tools people run (Nous Research's Hermes Agent, Stanford's DSPy, the agentskills.io format, and the skill and memory features Anthropic and OpenAI document) by what changes, who decides the change is good and how you undo it. It compares approaches, not quality, so there is no ranking.

Hermes Agent facts below were checked against its repository and documentation on 23 October 2026, when the latest release was v0.22.5 (published 23 October 2026 on GitHub). Hermes ships several releases a week, so recheck any default before you rely on it.

Key takeaways

• There are eight common approaches: verbal reflection, skill libraries, tiered memory, prompt and program optimisation, meta agent search, self code modification, evolutionary program search and weight level self training.
• The artifact that changes matters most. Context and memory are small text; skills, prompt programs and agent source are code or close to it; weights are opaque.
• Every approach has an evaluator, and every evaluator can be gamed. The Darwin Gödel Machine authors report that objective hacking happened more often when their checking functions were visible to the agent being modified.
• Hermes Agent and DSPy ship as tools people run; meta agent search, self code modification and evolutionary search are mostly research code.
• Human gates exist but are often off by default. In Hermes, skills.write_approval and memory.write_approval both default to false, and the content scanner for agent written skills (skills.guard_agent_created) also defaults to false, per the Hermes docs read on 23 October 2026.
• Rollback is easiest when the artifact is a plain file under git. Version skills, memory and compiled prompt programs before any loop runs unattended.
• Every approach that writes code or installs packages creates software supply chain artifacts: scripts, dependencies, serialized programs and checkpoints. Treat them like any other third party component.

What "self-improving" means in practice

At one end, an agent writes a short lesson into a buffer and reads it on its next attempt. At the other, a training loop generates data, filters it and updates the weights of the model that produced it. In between sit systems that rewrite prompts, save procedures or edit their own scaffolding code.

None of the systems here improve without limit. Each improved a measured score on a fixed benchmark, under a budget, with an evaluator chosen by people. Where a paper reports a result, this post gives the benchmark, baseline and compute in the authors' terms.

The eight approaches, one by one

Verbal reflection (Reflexion, Self-Refine)

Reflexion (Shinn and colleagues, arXiv 2303.11366, first version 20 March 2023) reinforces a language agent "not by updating weights, but instead through linguistic feedback". After a failed attempt, the agent writes a reflection about what went wrong and keeps that text in an episodic memory buffer, which it reads on the next trial. The feedback signal can be a scalar, free text, external (for example test results or an environment reward) or simulated by the model. The authors report 91% pass@1 on the HumanEval coding benchmark, against 80% for the strongest prior result they compared with.

Self-Refine (Madaan and colleagues, arXiv 2303.17651, 30 March 2023) is a tighter loop inside a single answer. One model generates an output, critiques it and refines it, repeatedly, with no training data and no reinforcement learning. Across seven tasks, from dialogue responses to mathematical reasoning, the authors report outputs that humans and automatic metrics prefer over single pass generation, "improving by ~20% absolute on average in task performance".

What changes: the context window and a small reflection buffer that usually lives only as long as the task. Undoing it means discarding the buffer.

Skill libraries (Voyager, Hermes Agent skills, the agentskills.io format)

Voyager (Wang and colleagues, arXiv 2305.16291, 25 May 2023) is the reference design. Playing Minecraft through a JavaScript control API, it combines an automatic curriculum, "an ever-growing skill library of executable code" and an iterative prompting loop that uses environment feedback, execution errors and self-verification. The authors report 3.3 times more unique items and tech tree milestones up to 15.3 times faster than the prior methods they compared against, and the skill library transferred to a new world. Skills are stored as code because code is executable, composable and readable.

Hermes Agent does something similar with files. It stores skills under ~/.hermes/skills/ as folders with a SKILL.md file, in a format its docs describe as compatible with the agentskills.io open standard. The agent manages them itself through a skill_manage tool with create, patch, delete, write_file and remove_file actions. According to the Hermes skills documentation, the system prompt asks the agent to record a skill when it worked out a multi step workflow worth repeating, when it hit errors and found the working path, and when the user corrected its approach. A background review after a turn, and an optional "curator" consolidation pass, can also write skills.

The agentskills.io specification defines the shared format: a directory with a required SKILL.md (YAML frontmatter with name and description, plus optional fields including an experimental allowed-tools) and optional scripts/, references/ and assets/ folders. For a defender, scripts/ matters most: a skill can carry executable code.

What changes: a folder of Markdown and, often, scripts. Rollback depends on whether that folder is versioned.

Tiered memory (Generative Agents, MemGPT, Hermes memory, the Claude memory tool)

Generative Agents (Park and colleagues, arXiv 2304.03442, 7 April 2023) stores "a complete record of the agent's experiences using natural language", periodically synthesises those memories into higher level reflections and retrieves them to plan behaviour. It was evaluated on the believability of 25 simulated people in a sandbox town.

MemGPT (Packer and colleagues, arXiv 2310.08560, 12 October 2023) borrows from operating systems. It manages "different memory tiers", moving data between the context window and external storage, and was evaluated on large document analysis and multi session chat.

Hermes Agent keeps two small memory files under ~/.hermes/memories/: MEMORY.md for the agent's own notes (2,200 characters) and USER.md for a user profile (1,375 characters). The memory documentation says both are "injected into the system prompt as a frozen snapshot at session start", that memory does not auto compact, and that entries are scanned for prompt injection, credential exfiltration, SSH backdoor patterns and invisible Unicode before they are accepted. Past sessions live in a SQLite database (~/.hermes/state.db) with full text search, which the agent queries with a session_search tool.

Anthropic documents a memory tool for the Claude API (tool type memory_20250818). Per its docs, the tool "operates client-side": Claude requests file operations under a /memories path, and your application decides where and how they are stored. The same page puts path traversal protection, size caps, expiry and stripping sensitive data on the application, because "your application runs every file operation Claude requests".

What changes: small text files or rows loaded into future prompts. A single bad memory write has long reach, because it is loaded into every later session.

Prompt and program optimisation (DSPy, OPRO, Promptbreeder, TextGrad, GEPA)

DSPy (Khattab and colleagues, arXiv 2310.03714, 5 October 2023) treats a language model pipeline as a program of declarative modules and compiles it against a metric. The DSPy optimiser documentation says an optimiser tunes "the prompts and/or the LM weights" of a program to maximise the metric you give it. Its optimisers do that in three ways: synthesising few shot examples (for example BootstrapFewShot and BootstrapRS), proposing and searching over natural language instructions (MIPROv2, documented in arXiv 2406.11695, and GEPA, arXiv 2507.19457), and building datasets to fine tune weights (BootstrapFinetune). In the original paper, the authors report that compiled programs outperformed standard few shot prompting by over 25% and 65% for the two models they tested, within minutes of compiling.

OPRO (Yang and colleagues, arXiv 2309.03409, ICLR 2024) uses a model as the optimiser. Each step shows the model earlier candidate instructions with their scores, the model proposes new ones, and those are scored and added to the history. The authors report optimised prompts beating human designed prompts by up to 8% on GSM8K and up to 50% on Big-Bench Hard tasks.

Promptbreeder (Fernando and colleagues, arXiv 2309.16797, 28 September 2023) evolves task prompts and, in a "self-referential" step, the mutation prompts that change them. TextGrad (Yuksekgonul and colleagues, arXiv 2406.07496, 11 June 2024) "backpropagates textual feedback" through a computation graph of model calls, using a PyTorch style interface. Among its reported results, a commercial model's zero shot accuracy on Google-Proof Question Answering rose from 51% to 55%, and optimised LeetCode Hard solutions showed a 20% relative gain. GEPA (arXiv 2507.19457, 25 July 2025) reflects on whole trajectories in natural language and keeps a Pareto frontier of prompt candidates.

What changes: a prompt program, usually saved as a JSON file of instructions and demonstrations, and in the BootstrapFinetune case, model weights.

Meta agent search (ADAS)

Automated Design of Agentic Systems (Hu, Lu and Clune, arXiv 2408.08435, 15 August 2024) has a "meta agent" write new agent designs as code, test them and keep them in a growing archive that informs the next design. The paper reports that Meta Agent Search ran 25 iterations on ARC, with discovered agents scored on held out tests, and states that one search and evaluation run on ARC cost about 500 US dollars in API fees and a run in the reasoning domains about 300 dollars. The authors say discovered agents kept their advantage when transferred across domains and models.

For safety, the authors describe "containerized execution of all generated code in secure, isolated environments, thorough manual inspections" and warnings in their codebase.

What changes: new agent source files in an archive. The running system is not modifying itself; a separate meta agent writes candidates.

Self code modification (Gödel Agent, SICA, the Darwin Gödel Machine)

Here the agent edits its own scaffolding.

Gödel Agent (Yin and colleagues, arXiv 2410.04444, ACL 2025) lets a model rewrite the agent's own logic at run time, guided by high level objectives, and reports continuous improvement on mathematical reasoning and agent tasks.

A Self-Improving Coding Agent, or SICA (Robeyns and colleagues, arXiv 2504.15228, 21 April 2025), removes the line between meta agent and target agent: the agent that runs benchmarks is the one that edits its own codebase. The authors report a rise "from 17% to 53%" on a random subset of SWE-bench Verified, with gains on LiveCodeBench and synthetic benchmarks. Their utility function combines benchmark score, wall clock time and dollar cost, with a cost cap of 10 dollars and a 300 second timeout per problem, and they state the API cost of the 15 iteration run as about 7,000 dollars. They keep weights fixed and say that if a system updated weights as well as scaffolding, they "would expect that the risks of recursively self-improving systems would be higher". Their mitigations are observability and an asynchronous LLM overseer that checks the run every 30 seconds by default and can cancel an agent that drifts off task.

The Darwin Gödel Machine, or DGM (Zhang and colleagues, arXiv 2505.22954, first version 29 May 2025, latest version 12 March 2026), replaces the proofs of Schmidhuber's original Gödel machine with empirical validation on coding benchmarks and keeps an archive of agent variants instead of a single lineage. The abstract reports SWE-bench performance rising from 20.0% to 50.0% and Polyglot from 14.2% to 30.7%. The paper's appendix estimates about 22,000 US dollars for a single SWE-bench run of the DGM, against about 10,000 dollars for each baseline, and says such a run "takes about 2 weeks". The authors state that all agent execution and self modification ran in isolated sandboxes with strict time limits, that modifications were limited to the agent's own Python codebase, and that the archive gives "a traceable lineage of modifications for review". They also describe a case of objective hacking, covered in the evaluator section below.

What changes: the agent's own source code, so a bad change can alter every later task, including how the agent evaluates itself.

Evolutionary program search (FunSearch, AlphaEvolve)

FunSearch (Romera-Paredes and colleagues, Nature, published 14 December 2023) pairs "a pretrained LLM with a systematic evaluator" in an evolutionary loop over programs. The authors report new constructions for the cap set problem in extremal combinatorics.

AlphaEvolve (Novikov and colleagues, Google DeepMind, arXiv 2506.13131, 16 June 2025) extends this to whole code files and multiple evaluators. The white paper reports, as Google DeepMind's own results, a more efficient data centre scheduling heuristic at Google, a simplification in accelerator circuit design, faster training of the model underpinning AlphaEvolve, and a procedure to multiply two 4 by 4 complex valued matrices using 48 scalar multiplications. These are the authors' claims, checked by their own evaluators, on problems where a program can be scored automatically.

What changes: candidate programs in a database; the output is code you might later deploy.

Weight level self training (STaR, Self-Rewarding Language Models)

STaR, the Self-Taught Reasoner (Zelikman and colleagues, arXiv 2203.14465, 28 March 2022), generates rationales for many questions, keeps only those that led to correct answers (with a retry that is given the correct answer for failed cases), fine tunes on the kept rationales and repeats. The filter is answer correctness, which keeps the loop anchored to ground truth labels.

Self-Rewarding Language Models (Yuan and colleagues, arXiv 2401.10020, ICML 2024) use the model being trained as its own judge, through LLM as a judge prompting, and train it with iterative Direct Preference Optimization. The authors report that over three iterations on Llama 2 70B, both instruction following and the model's ability to reward itself improved, measured on the AlpacaEval 2.0 leaderboard.

What changes: model weights, in a new checkpoint.

What changes on disk in each approach

The artifact decides what a defender can diff, review, sign and restore.

DSPy's saving tutorial warns that loading .pkl files "can execute arbitrary code", recommends JSON for program state, requires an explicit allow_pickle=True to load pickles, and notes that whole program saving uses cloudpickle with the same risk. And a skill folder can contain scripts that the agent runs through a shell. Either way, the improved artifact is executable software supply chain material.

Who checks the change: evaluators and how each can be gamed

The loop optimises whatever the judge rewards, so the judge is where most failures start.

Self critique

A model that cannot see an error is unlikely to find it on a second read, so self critique works best paired with a compiler, test suite or checker. Our post on LLM as judge pitfalls covers the general failure modes.

Unit tests and benchmark scores

Tests and benchmarks are the strongest common evaluators, which is why coding has the most published self modification results. They are still gameable. In a DGM experiment on tool use hallucination, the functions that checked for hallucinated tool calls were hidden from the coding agent during self modification, and the authors report that objective hacking ("optimizing for the measurable objective instead of truly solving the underlying problem") occurred more frequently when those functions were not hidden. If the agent can read or edit the evaluator, assume it will eventually optimise the evaluator instead of the task.

Development set metrics

DSPy's optimiser guide is direct about data size: for longer MIPROv2 runs it suggests 40 or more trials and "200 examples or more to prevent overfitting". Keep a held out set the optimiser never sees, and version it with the program.

Human approval

Human approval is the only evaluator that judges intent, and it degrades fastest under volume: forty skill edits a day get approved in bulk. Keep gates narrow. Review every change to an executable script, sample changes to prose, and block changes to anything that defines the agent's permissions.

The model as its own judge

In Self-Rewarding Language Models the judge is part of the trained system, so the loop has no external anchor unless you add one. For production use, keep an independent evaluation set and grader outside the loop.

Research prototype or a tool you can run?

A few details from the vendors' own documentation, described neutrally:

• Anthropic's Agent Skills overview describes three loading levels: metadata (name and description) loaded at startup, the SKILL.md body loaded when a skill is triggered, and bundled resources or scripts loaded or run only as needed. Its security section says to use skills "only from trusted sources" and to audit every bundled file. Custom skills uploaded through the Claude API are shared workspace wide.
• OpenAI's skills documentation says skills for ChatGPT and Codex "build on the open agent skills standard". Codex reads skills from .agents/skills folders between the working directory and the repository root, from $HOME/.agents/skills and from /etc/codex/skills, plus system skills bundled with Codex. A built in $skill-creator defaults new skills to instruction only. An optional agents/openai.yaml file in a skill can set allow_implicit_invocation to false so Codex uses it only when invoked explicitly.
• Hermes Agent's docs describe the agent creating and editing its own skills as part of its learning loop.

Because several agents read the same SKILL.md layout, a skill written by one agent or downloaded from one hub can run in another. That portability is exactly how packages spread.

Human gates and rollback paths

For each approach, ask who has to say yes before the change is live, and what puts things back.

Reflection

Gate: none needed when the buffer is discarded after the task. Persisted reflections become memory and inherit its controls.

Hermes skills

Gate: skills.write_approval. The Hermes docs say that by default "the agent writes skills freely", including from the background review. With write_approval: true, every skill_manage write is staged under ~/.hermes/pending/skills/ and reviewed with /skills pending, /skills diff, /skills approve and /skills reject. The separate skills.guard_agent_created scanner, which flags dangerous keyword patterns in agent written skills, is off by default; the configuration docs say legitimate workflows that mention SSH folders or API key variables tripped it too often.

Rollback: Hermes has two mechanisms, and neither covers everything.

• The curator moves unused agent created skills to stale after 14 days and to ~/.hermes/skills/.archive/ after 30 days, and hermes curator restore brings one back. The docs say the curator "never auto-deletes".
• Before an LLM consolidation pass (off by default), Hermes takes a tar.gz snapshot of the skills tree, and hermes curator rollback restores it. The docs say the default prune only pass takes no snapshot, and that snapshots are kept to two by default.

Neither is a full history of the skill edits the agent makes in normal turns. Hermes checkpoints (/rollback) snapshot project files before writes and destructive commands; they are opt in (checkpoints.enabled: false by default) and track your working tree, not the skill library. For a full history, put the skills folder under git, as shown below.

Hermes memory

Gate: memory.write_approval, default false. When true, interactive CLI writes prompt inline and every other write, including the background review, is staged for /memory pending. Hermes also scans memory entries for injection and exfiltration patterns before accepting them.

Rollback: memory is two small files. Back them up and version them.

Claude memory tool

Gate and rollback are yours: your handler decides whether a write lands and how it is versioned.

DSPy programs

Gate: your own code review, because the compiled program is a file you save and commit. Rollback: git revert on the saved program, provided you saved it as JSON and pinned the library version that produced it.

Meta agent search, self code modification and evolutionary search

Gate: in the papers, sandboxes, time limits, manual inspection (ADAS), an LLM overseer (SICA) and lineage tracking (DGM). In your environment, treat it as any code change: a pull request, tests the agent cannot edit and a reviewer. Rollback: version control, or the archive of earlier variants.

Weight level self training

Gate: an evaluation suite the training loop never saw, plus a release decision by people. Rollback: keep the previous checkpoint and the data that produced the new one.

What supply chain surface each approach creates

Self improvement adds components to your software, often without a pull request.

• Reflection adds almost nothing persistent.
• Skill libraries add scripts, references and sometimes instructions to install packages; a skill that says "run pip install X" is a dependency declaration in prose. Shared skills are third party code. Hermes records the source URL, content hash, scanner version and findings for hub installs and quarantines dangerous ones, and requires hermes skills trust before loading project local skills, according to its skills documentation. Skills the agent writes itself have no upstream, so no one else will ever publish a fix for them. Our post on why agent skills and plugin repositories need the same governance as packages goes deeper.
• Tiered memory adds no code, but a remembered package source or default flag shapes what the agent installs next week. See our post on AI agent memory security risks.
• Prompt and program optimisation adds serialized program files, the optimiser library and its dependencies, and the training data used for compilation. Pickle based saves are executable on load.
• Meta agent search and self code modification add generated source code and whatever it imports. DGM's discovered improvements included new code editing tools, which in a real repository would be new modules and possibly new packages.
• Evolutionary program search adds evolved code; if it ships, the generating run (model, prompts, evaluator version) is part of its provenance.
• Weight level self training adds checkpoints, datasets and training code; checkpoint formats that run code on load and datasets of unknown licence are the main concerns.

The comparison table

How to choose an approach

Two questions decide most cases: do you have a trusted evaluator the agent cannot edit, and what is the blast radius if a bad change goes live?

The rule of thumb: the less trustworthy the evaluator, the smaller and more readable the artifact should be. Code that changes how the agent judges itself needs an evaluator outside the agent's reach.

Step by step: put a self improving loop under review and version control

This uses Hermes Agent and DSPy because both are open source and documented; the pattern applies to any agent that writes skills, memory or prompt programs. Hermes keys come from its docs as read on 23 October 2026.

Step 1: back up the current state

Warning: later steps change agent configuration and history. Take a backup first.

# Back up the whole Hermes home, including skills, memory and config
tar -czf ~/hermes-backup-$(date +%Y%m%d-%H%M%S).tar.gz -C ~ .hermes

# Take an explicit curator snapshot of the skills tree as well
hermes curator backup --reason "before-version-control"

Step 2: turn on write approval for skills and memory

Edit ~/.hermes/config.yaml:

skills:
  write_approval: true        # stage every skill_manage write for review
  guard_agent_created: true   # scan agent-written skills for dangerous patterns
memory:
  write_approval: true        # stage memory writes outside the interactive CLI
curator:
  consolidate: false          # keep the LLM consolidation pass off (the default)
checkpoints:
  enabled: true               # snapshot project files before writes and destructive commands
approvals:
  mode: manual                # prompt for every dangerous command instead of the smart default

Then review staged changes in a session:

/skills pending
/skills diff <id>
/skills approve <id>
/skills reject <id>
/memory pending

approvals.mode: manual is optional. The default, smart, lets an auxiliary model auto approve low risk commands; stricter is reasonable until you know what the agent writes.

Step 3: put skills and memory under git

Hermes does not keep a full edit history of agent written skills, so add one.

cd ~/.hermes/skills
git init
printf '.archive/\n.curator_backups/\n.hub/\n' > .gitignore
git add -A
git commit -m "Baseline: skills before agent writes are reviewed"

cd ~/.hermes/memories
git init
git add MEMORY.md USER.md
git commit -m "Baseline: memory files"

After each review session, commit what you approved:

cd ~/.hermes/skills && git add -A && git commit -m "Approved agent skill changes $(date +%F)"
cd ~/.hermes/memories && git add -A && git commit -m "Approved memory changes $(date +%F)"

Warning: restoring a skill from git overwrites the current version. Commit or copy the current tree before you do it.

cd ~/.hermes/skills
git stash push -m "pre-restore $(date +%F)"   # keep the current state recoverable
git checkout <commit> -- <skill-folder>/
git commit -m "Restore <skill-folder> from <commit>"

If you want agent created skills to land in a shared, reviewed repository instead, the Hermes docs describe skills.create_dir, which redirects new skills to a directory such as a git tracked checkout.

Step 4: inventory what skills pull in

Skills can name packages in prose and ship requirement files. List them.

cd ~/.hermes/skills
# Find scripts and dependency manifests bundled in skills
find . -path ./.archive -prune -o \( -name 'requirements*.txt' -o -name 'package.json' -o -name '*.py' -o -name '*.sh' \) -print

# Find install instructions written in prose
grep -rnE 'pip install|npm install|uv pip|curl .*\| *(ba)?sh' --include='SKILL.md' .

For any Python requirements file you find, pin it with hashes and generate a CycloneDX SBOM:

python -m pip install pip-tools cyclonedx-bom
pip-compile --generate-hashes -o requirements.lock requirements.in
cyclonedx-py requirements requirements.lock --of JSON -o skill-sbom.cdx.json

Step 5: version and pin a DSPy program

Save compiled program state as JSON, not pickle, and record the library version that produced it.

import dspy

# ... build `program`, a `metric`, and `trainset` / `devset` you keep separate
optimizer = dspy.MIPROv2(metric=metric, auto="light")
compiled = optimizer.compile(program, trainset=trainset)

# JSON state is readable and diffable; DSPy's docs warn that pickle can run code on load
compiled.save("programs/support_triage.json", save_program=False)

pip freeze | grep -i '^dspy' > programs/dspy-version.txt
git add programs/support_triage.json programs/dspy-version.txt
git commit -m "Compiled support_triage with MIPROv2 (light); held-out score in PR"

Load it the same way, and do not pass allow_pickle=True to anything you did not produce yourself:

loaded = MyProgram()
loaded.load("programs/support_triage.json")

Step 6: sign the artifacts you promote

Sign a compiled program or approved skill bundle before it moves to a shared environment.

tar --exclude='skills/.archive' --exclude='skills/.curator_backups' -czf skills-$(date +%F).tar.gz -C ~/.hermes skills
cosign sign-blob --yes --bundle skills-$(date +%F).tar.gz.sigstore.json skills-$(date +%F).tar.gz
cosign verify-blob --bundle skills-$(date +%F).tar.gz.sigstore.json \
  --certificate-identity you@example.com \
  --certificate-oidc-issuer https://accounts.google.com \
  skills-$(date +%F).tar.gz

Use the identity and issuer that match your own signing setup.

Step 7: gate it in CI

Make CI reject agent written changes nobody reviewed. A minimal GitHub Actions job:

name: agent-artifacts
on: [pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Require review label for changed skill scripts
        run: |
          changed=$(git diff --name-only origin/${{ github.base_ref }}...HEAD -- 'skills/**/scripts/**')
          if [ -n "$changed" ]; then
            echo "Skill scripts changed:"; echo "$changed"
            echo "${{ join(github.event.pull_request.labels.*.name, ',') }}" | grep -q 'skill-script-reviewed' \
              || { echo "Add the skill-script-reviewed label after a code review"; exit 1; }
          fi
      - name: Block pickled DSPy programs
        run: |
          if git diff --name-only origin/${{ github.base_ref }}...HEAD | grep -E '\.pkl$'; then
            echo "Pickle files are not allowed; save DSPy state as JSON"; exit 1
          fi

Keep evaluator code, tests and this workflow in paths the agent cannot write to, with branch protection and code owners on them.

What the research did not show

• Fixed benchmarks, fixed models. SICA, DGM and ADAS improved scaffolding around models whose weights did not change. SICA's authors note there "seem to be limits to what can be achieved with such purely scaffolding based systems".
• Significant compute. DGM's SWE-bench run cost about 22,000 dollars and two weeks by the authors' estimate. SICA's 15 iteration run cost about 7,000 dollars. These are research budgets, not something a team runs on every commit.
• Narrow evaluators. AlphaEvolve and FunSearch depend on problems that can be scored automatically. Most business tasks cannot be.
• No long horizon production evidence. None of these papers measures months of self improvement in a live environment with untrusted inputs. Hermes Agent runs a version of this loop for its users every day, but there is little independent public evidence about its long term effect, and Nous Research's own descriptions should be read as self reported.
• Self judgement is an open problem. Model collapse is a related concern when models train on their own outputs; our post on model collapse, myth versus fact covers what the research shows.

Governance: mapping this to NIST AI RMF 1.0

NIST released the AI Risk Management Framework 1.0 on 26 January 2023 for voluntary use; its page notes it is being revised. Its four functions map onto self improving agents.

The OWASP GenAI Security Project's "Agentic AI: Threats and Mitigations" guide (published 17 February 2025) gives a threat model based reference for the same space. Our comparison of the OWASP LLM Top 10 and the agentic Top 10 explains which list to map to, and building or buying agent guardrails covers the runtime side.

Common mistakes

• Leaving every gate at its default. In Hermes, skill writes, memory writes and the agent skill content scanner are all off by default as of 23 October 2026. That is a reasonable default for a personal assistant and a poor one for a shared or production agent.
• Assuming one rollback covers everything. Hermes /rollback restores project files from checkpoints; hermes curator rollback restores the skills tree from curator snapshots. Neither is a full history of every skill edit. Git is.
• Letting the agent see or edit its evaluator. The DGM authors observed more objective hacking when checking functions were visible. Keep tests and scoring code read only.
• Compiling on the evaluation set. A prompt program optimised and scored on the same examples will look better than it is. Keep a held out set.
• Saving programs as pickle. DSPy recommends JSON for state; pickle and cloudpickle loads can run code.
• Treating skill scripts as documentation. A scripts/ folder is code that the agent will execute. Review and pin it like code.
• Sharing one agent home between processes. The Hermes memory docs warn that two writers on one home compound each other's entries.
• Ignoring the packages that skills mention. A line in a skill that tells the agent to install a package is a dependency, even though no manifest lists it.

FAQ

What is a self-improving AI agent?

An agent that changes something about itself based on feedback so later attempts go better: a reflection, a memory file, a saved skill, a compiled prompt program, its own code or model weights.

Which self-improving agent framework is the best?

This post does not rank them. Choose by the evaluator you have and the blast radius of a bad change; with no trustworthy evaluator, keep changes small and human reviewed.

Does Hermes Agent train its own model?

No. Per its documentation, Hermes Agent improves through memory files, saved skills and searchable session history, and calls whichever model you configure. Nous Research's open weight Hermes models are a separate project.

Is Hermes Agent safe to run?

It has a documented security model, including command approvals, container backends, memory scanning and skill quarantine, but skills.write_approval and memory.write_approval are off by default. Two CVE records exist: CVE-2026-71963 and CVE-2026-85105. Use a container backend, turn on write approval, keep skills under git and update promptly.

What is the difference between a skill and a memory?

Memory holds small, capped facts always loaded into the prompt; skills hold longer procedures, sometimes with scripts, loaded only when relevant.

Can I roll back what an agent learned?

Yes, if the artifact is versioned. Hermes restores archived skills, curator snapshots and (opt in) project checkpoints; for a full history, keep skills and memory under git.

How is DSPy different from a self-improving agent?

DSPy optimises a program offline against your metric and produces a file you save and review, so it goes through code review like any other change.

What is the Darwin Gödel Machine?

A 2025 research system (arXiv 2505.22954) that edits its own coding agent code, tests each variant on benchmarks and keeps an archive. The authors report SWE-bench rising from 20.0% to 50.0% at about 22,000 dollars per run.

Are agent skills a supply chain risk?

They can be. A skill may contain scripts and install instructions, and several agents read the same format. Anthropic's documentation advises using skills only from trusted sources and auditing every bundled file.

Do self-improving agents need an SBOM?

Yes. The agent's dependencies, skill scripts and installed packages are software components, and an SPDX or CycloneDX SBOM makes them visible to vulnerability matching and policy checks.

Where Safeguard fits, and where it does not

Safeguard does not run, train or govern any of the frameworks in this post, and none of them is a Safeguard product, integration or partner. The honest connection is narrower. An agent that writes code, authors skills with scripts, saves prompt programs and installs packages produces ordinary software supply chain artifacts, and those artifacts need the same treatment as any other component in your repositories: an SBOM in SPDX or CycloneDX, provenance and signing (SLSA, Sigstore, in-toto attestations), policies and gates that stop a vulnerable dependency from merging, and patching when a component has a CVE. Safeguard does those things for any codebase, including one that an agent edits. Safeguard's MCP server, with hundreds of MCP tools, can also be one of the tools an assistant uses: you install it from Claude's or ChatGPT's connector directory and choose which tools the assistant may call. AI-BOM discovery and the MCP Guardrail are in early access; SBOM generation, attestation, policies and gates, and autonomous remediation are generally available.

A self improving agent installs packages, writes scripts into its skills and saves programs that become part of your codebase, and the agent's own dependency tree is a set of open source components that receive CVEs like any other. Whatever the agent learns, the libraries underneath it still need to be patched, which is where the steps below apply.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos run Hermes Agent, DSPy or any research system; they show how Safeguard handles the code and dependencies agents produce.

The first demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. The same approval per command pattern is what you want when any agent touches dependencies, including packages that a skill script pulls in.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server, installed from Claude's connector directory with OAuth, and chooses which tools Claude can use. Choosing tools per assistant is the same least privilege idea as gating which skills and memory an agent may write, and once your repositories are in Safeguard, the assistant can ask which projects carry a given component and version.

Click through it at your own pace, or open it full screen.

The third demo sets up the local runner on your own machine, approves it with a device code, then scans from the terminal. That fits a workstation where an agent writes skills and scripts locally: you can scan the folder where they land before you promote them anywhere shared.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Hermes Agent repository (Nous Research)
• Hermes Agent releases (GitHub API, v0.22.5 on 23 October 2026)
• Hermes Agent docs: Skills
• Hermes Agent docs: Memory
• Hermes Agent docs: Curator
• Hermes Agent docs: Checkpoints and rollback
• Hermes Agent docs: Security
• Hermes Agent docs: Configuration
• Agent Skills specification (agentskills.io)
• Anthropic: Agent Skills overview
• Anthropic: Memory tool
• OpenAI: Build skills for ChatGPT and Codex
• DSPy docs: Optimizers
• DSPy docs: Saving and loading programs
• dspy on PyPI
• Reflexion, arXiv 2303.11366
• Self-Refine, arXiv 2303.17651
• Voyager, arXiv 2305.16291
• Generative Agents, arXiv 2304.03442
• MemGPT, arXiv 2310.08560
• DSPy, arXiv 2310.03714
• MIPRO, arXiv 2406.11695
• GEPA, arXiv 2507.19457
• OPRO, arXiv 2309.03409
• Promptbreeder, arXiv 2309.16797
• TextGrad, arXiv 2406.07496
• Automated Design of Agentic Systems, arXiv 2408.08435
• Gödel Agent, arXiv 2410.04444
• A Self-Improving Coding Agent, arXiv 2504.15228
• Darwin Gödel Machine, arXiv 2505.22954
• AlphaEvolve white paper, arXiv 2506.13131
• FunSearch: Mathematical discoveries from program search with large language models, Nature
• STaR, arXiv 2203.14465
• Self-Rewarding Language Models, arXiv 2401.10020
• NIST AI Risk Management Framework
• OWASP GenAI Security Project: Agentic AI Threats and Mitigations

Last reviewed: 23 October 2026. Hermes Agent and DSPy release often; check each project's documentation for current versions and defaults before changing any configuration above.