An agent finishes a hard task. When the turn ends, a background review asks whether any of that is worth keeping. If it is, the agent writes a file called SKILL.md into its own skills folder, and the next time a similar task arrives it reads that file first. Nobody approves the write. That is the default in Hermes Agent, Nous Research's MIT-licensed agent, which had over 250,000 GitHub stars on October 12, 2026.
This is what self-improvement means in practice in 2026. The weights stay the same. The agent writes files for itself: skills, memory, prompts, sub-agent specs, and now whole workflow programs. Each of those files changes how every later run behaves, which makes it a change to a production system. Self-written files need the same three things as code: revisions, review and pinning.
Three agents that write their own instructions
Hermes is a prominent public example, and its README is direct about it. It promises "autonomous skill creation after complex tasks," says "skills self-improve during use," and describes "agent-curated memory with periodic nudges" (README, October 12, 2026). Its skills are SKILL.md folders in the Agent Skills format, which Anthropic developed and released as an open standard and which Claude Code, Codex, Gemini CLI, Cursor and OpenCode now read. A file one agent writes for itself can be read by most of the agents a team runs.
Prime Intellect went further. Its Prime Agent (August 5, 2026) is built on Continual Harness, a paper from May 11, 2026 that began with an agent playing Pokémon. The harness treats "its prompts, skills, memory, and sub-agents" as state "the agent can create, read, update, and delete (CRUD) from its own trajectory." The agent can start a refinement "whenever it notices a repeated failure or a reusable tactic," mid-task, and "every change is also written to disk, so it survives across turns and across sessions." With Opus 5, Prime Intellect reports 95.5% on ARC-AGI-3 against a human expert baseline of 95.4% (Prime Intellect, August 5, 2026).
Then, four days before this post, Anthropic shipped dynamic workflows for Claude Managed Agents, in beta, on October 9, 2026. "For work with many pieces, such as reviewing hundreds of documents, the agent can write a workflow. A workflow is a program that runs many agents in phases and combines their results." The agent now writes the program that decides how many other agents run, in what order, on what inputs.
The file is the change
A skill is a set of instructions the next run follows. Editing it changes what the agent does on every later task that loads it, which is exactly what merging a pull request does to a service. The difference is that the pull request had a diff, a reviewer and a check run before anything depended on it, and each deploy names the version it runs. The skill has a file on disk that the next run reads as it is.
The Hermes docs show the default plainly. "By default the agent writes skills freely, including from the background self-improvement review that runs after a turn" (skills docs, October 12, 2026). Existing skills "are modified where they are found." The setting that controls this sits in the agent's config:
skills:
write_approval: false # false = write freely (default) | true = require approval
Three things follow from a file that changes itself in place.
Whatever the agent read can end up in the file. A skill is distilled from a task, and a task includes the web pages, issues and documents the agent read along the way. If one of them carried instructions, the lesson the agent saves can carry them too, and now they load on every future run. Hermes runs an advisory linter on new skills and ships an optional content scanner, which it describes honestly as "dangerous-pattern heuristics, not an approval gate."
A bad lesson compounds. A wrong fix in code breaks one path until someone reverts it. A wrong lesson in a skill is applied with confidence on every matching task, and the agent has no reason to doubt instructions it wrote itself.
Which version ran takes forensics. When a run goes wrong next Tuesday, the first question is what the agent knew when it started. Hermes keeps an append-only ledger of every skill write, by the agent, its background curator or a person, with before and after hashes, the session that triggered it when known, and a command that rolls back any single change (curator docs, October 12, 2026). That answers what changed and lets you undo it. Nothing in the docs ties a run to the revision it loaded, so connecting a bad run to its instructions means lining up times against the ledger, and two runs a minute apart may have read different text. The docs also say the ledger never blocks a write: if an entry fails to record, the change goes through anyway.
Most of the fix already ships
Agents should learn. The lessons are real, and an agent that forgets every correction is worse to work with. What matters is where the lesson lands.
Hermes already ships most of the answer. Turn write_approval on and every skill write, whether a create, an edit, a patch or a delete, is staged under ~/.hermes/pending/skills/ instead of landing. /skills diff shows it, and /skills approve or /skills reject decides it. That is a pull request for a skill, with the agent as author and a person as reviewer. Memory has the same switch. The curator ledger adds history: every write is recorded with what it replaced, and any one of them can be rolled back. What neither feature does is pin. An approved edit still replaces the file where it lives, and the next run loads whatever the file says at that moment.
Code relies on three practices for this, and every self-written file needs all three:
- Revisions. Every version of a skill, memory file or workflow is kept, with who or what wrote it and the run it came from.
- Review. A self-written change arrives as a diff. Something independent of the author reads it before it is shared: a person, or a second agent with a different job.
- Pinning. A run records the exact revision of every file it loaded when it started. New lessons apply to new runs, and a run in flight never has its instructions changed underneath it.
The honest limit. Pinning slows learning down. The point of Continual Harness is that the agent improves inside a single run, without a reset, and a strict pin would forbid that. The way through is to separate two copies. Inside its own run, the agent can rewrite its scratch copy as often as it likes; that is how it gets better at the task in front of it. What it wants to keep for every future run leaves the run as a proposed change, and that change goes through review like any other. Learning stays fast where the risk is one run, and slow where the risk is all of them.
I made a version of this point in After the Org Chart: everyone rents the same model, so what a team accumulates is its memory. A memory that rewrites itself with no history is an asset nobody can audit. And as Every Agent Demo Hides the Same Number argued, review is the variable demos skip and production restores. Self-improvement moves review to a new place, from the agent's output to the agent's own instructions.
What this looks like in Rush
Rush is the API for work: a caller sends a request, an agent does the work in its own cloud sandbox with a computer and a browser, and the result comes back with proof, plus the full trajectory of what the agent did. A run can name skills by URL. Rush fetches each one when the run is created, pins a GitHub source to the commit its branch points at, and keeps that pin with the run (create a session). A saved agent pins its skills when you save it, a GitHub source to its commit and any other source to its content, and every run from it loads exactly that pin (create a saved agent); if a pinned file has since changed, runs are refused with 422 SKILL_INVALID until someone saves the agent again. Saved agents are revisioned, and an edit that names a stale revision is refused with 412 STALE_ETAG (update a saved agent). A skill kept in a protected repository can go through that repository's pull-request and review rules, and Rush pins the commit that comes out. A skill an agent edits inside its own sandbox is not promoted into the saved agent: the edit stays in the run's captured trajectory, and keeping it for future runs takes an explicit save against the current revision.
The agents that learn fastest will be the ones that write the most to themselves. The teams that trust them will be the ones that can open any of those files, see who changed it and when, put it back, and say which revision each run read.
