We read the code behind a dozen self-improving AI agents

A new category of AI product has shown up in the last few months: agents that run continuously, remember what they tried, and rewrite their own capabilities as they go. Some live in a terminal. Some run a research loop against a benchmark. Some walk around inside Minecraft.

They share a shape: persistent state, a loop that keeps turning, and a claim that the system gets better at its job over time without a human rebuilding it.

We wanted to know whether that claim holds up, so we stopped reading marketing pages and started reading source.

Over one research pass we cloned, installed, and in several cases live-tested twelve of these systems: OpenClaw, Hermes Agent, OpenHands, ASI-Evolve, OpenEvolve, SWE-agent, Goose, Aider, Voyager, Paperclip, A-Evolve, and a fully-packaged competitor product we won't name here that wraps several of the same ideas into one commercial pitch. Full findings, file by file, are in our engineering notes.

This post is the pattern that came out the other side.

What these teams got right

This is not a takedown. Several of the mechanisms we found are genuinely good engineering, and worth naming specifically because they solve real problems.

OpenClaw's memory consolidation ("Dreaming") is the best-designed piece of the batch: a cron-scheduled process that scores recent signals on six weighted axes and promotes durable facts into long-term memory, with a dry-run command that shows you exactly what would be promoted before it happens. That is auditable-by-design, not bolted on afterward.

Hermes Agent lets a running session write itself a new skill mid-conversation, gated by a real security scanner with path-traversal test coverage, not an LLM's opinion of whether the code looks safe. A-Evolve's self-modification loop is backed by real git: mutations are tagged commits and a bad one is a genuine git checkout away from gone, not a soft undo.

Aider commits after every successful edit, with the AI and the human tagged as distinct authors in the same repository. SWE-agent's edit tool runs a linter before and after every change and refuses to let a broken edit through silently.

Voyager, still one of the most cited reference designs in this space, builds a persistent library of literal, re-executable skill code, retrieved by embedding similarity against whatever the agent is trying to do next. Paperclip's heartbeat scheduler persists a full context snapshot across wake cycles, so a dormant agent picks up exactly where it left off, not from scratch.

None of that is a small achievement. Building a loop that runs unattended for hours or days without falling over is hard, and every one of these teams has working code proving they solved it.

The gap

We asked one question of each system: if the artefact it learns from, the memory file, the skill store, the experiment log, was quietly edited by someone with disk access, would anything notice?

Nine out of ten, the answer was no. Memory files, SQLite databases, and JSON logs, all mutable, all editable by anyone with filesystem access, with nothing to detect it after the fact. One system's own code comments describe its execution trace as built "for RL training," explicitly not as an audit record.

Aider was the one exception: because it commits every edit to git, it gets a real, append-only history for free, as a side effect of how it works rather than a feature someone added.

This is not a story about any one team cutting a corner. It is a category-wide gap. The systems above are optimising for capability, and capability is what gets measured first. Proof that the capability's own history hasn't been tampered with comes later, if it comes at all.

It matters more here than in most software, because the whole pitch of a self-improving agent is that it keeps a record of what worked and reuses it. If that record can be silently edited, the system's own memory of its past becomes exactly as trustworthy as the person with access to the disk it's stored on.

What we built to test it

Rather than argue the point, we built the smallest thing that would prove it either way: a governed skill store that combines the parts of the above we rated highest, promotion only after independent verification, embedding retrieval, a real security gate, plus the one thing none of the twelve systems had, a hash-chained, append-only ledger for every promotion, reuse, and demotion event.

We ran it live. A hand-written malicious skill was rejected before it ever executed, caught by a static scan, not a model's judgement call. A real skill passed verification and was promoted. Confidence decayed automatically when reuse failed in a new context, and the skill was auto-demoted, something none of the systems studied do; every one of them only ever grows its library.

Then we tampered with the ledger file directly on disk, the exact attack every other system studied is silently exposed to, and the verifier caught it in one call, naming the exact entry that had been altered.

We also red-teamed our own first version. The initial security scanner was a denylist, and it broke on the first real attempt: a well-known code pattern reached a dangerous function with zero imports and none of the banned names it was checking for. We rebuilt the check to block a whole class of access pattern instead of one more named exception, re-ran the attack, and it held.

Where this leaves things

Quox's own audit protocols, AEE for structured event history and WARD for hash-chained witnessing, already give production workflows this property today. What this research pass confirmed is that almost nobody else building persistent, self-learning agents has it at all, and that closing the gap does not require exotic infrastructure. It requires treating a self-learning system's own history as something worth protecting, not just something worth generating.

The prototype above is a research build, not a shipped product. What is currently live in Quox is structured audit trails on governed workflow execution. Applying the same discipline to a persistent skill or memory store, the way the prototype demonstrates, is on our roadmap, not yet in production.

We are being specific about that distinction on purpose: a lot of this category blurs the line between what a demo proves and what a system guarantees, and we would rather be the team that draws that line clearly than the team that hopes nobody checks.

A companion piece from the same research pass asks the two questions that sit underneath all of this: will the agent do the wrong thing, and will anything notice.