Check whether your agent's fixes actually hold
Every fix pattern here was confirmed by a service that did not produce it, and every check recomputes from the page itself. If you're building an agent that modifies its own behaviour, let's walk your memory store through the same four requirements.
Book 30 minutesHow do you verify that a self-evolving agent actually improved?
How do you verify that a self-evolving agent actually improved?
Short answer: you do not ask the agent. You require that every change it keeps was confirmed by something that did not produce it, and you make that confirmation re-runnable by a stranger. An agent that grades its own homework has not improved; it has only become more confident.
The problem with self-reported improvement
A self-evolving agent is one that modifies its own behaviour based on its own runs: it stores what worked, retrieves it later, and skips work it has already done. The appeal is obvious. The failure mode is equally obvious once stated: the same system that produced a change is the one deciding the change was good, so errors get promoted into memory and then reused with increasing confidence.
This is not hypothetical. A stored "verified fix" that was never independently re-tested is worse than no memory at all, because the agent now applies it quickly and without reasoning.
The gate: separate the producer from the confirmer
The rule that makes self-evolution safe is a single structural constraint.
Nothing enters memory unless something that did not produce it confirmed it.
In practice that means an independent service discovers the problem, the agent produces a candidate change, and the same independent service re-runs its own check against the changed system. Only if the original failure no longer reproduces does the change enter memory, stamped with what confirmed it and when. If the re-test fails, the attempt is still logged, with its true cost, and the change is discarded.
The producer and the confirmer being different systems is the whole trick. It is why the memory can later be trusted enough to skip reasoning: every entry in it survived a test it did not design.
Retrieve by cause, not by keyword
The second constraint is about what gets matched. Storing a fix under its symptom means the next occurrence has to look the same to be found. Storing it under its cause means the same underlying defect is recognisable when it appears in a different part of the system wearing different words.
Semantic retrieval over a fingerprint of the root cause, with a confidence threshold and a reuse counter, is what turns a log into an asset. In one measured run of this pattern, a task that cost $1.66 in fresh reasoning cost $0.03 on the second encounter, because the second encounter was a retrieval rather than a derivation.
That ratio is the actual argument for self-evolution. Not that the agent gets smarter, but that the cost of the next correct answer falls, and keeps falling.
Two failure modes the gate has to tell apart
Drift. The content was correct when it was verified and became wrong later, because its source changed underneath it. The cure is re-verification on a schedule against the source of truth, and remediation when they diverge.
Born-wrong. The content was already wrong at the moment it was stored, so the source of truth faithfully preserves the defect. Restoring from the source cannot cure this. The only cure is re-running the checks against the repaired result, which means the gate has to be willing to re-verify its own repair.
Systems that conflate these two will keep restoring a defect and calling it a fix.
Make the check stateless and re-runnable
The last requirement is the one most systems skip. A verification result is only worth something if a third party can reproduce it without your credentials and without your database.
Concretely: no check should read a verified flag. Every check should recompute
its verdict from the artifact and its cited source, so that anyone holding the
public page can get the same answer you got. Once that is true, the question
"how do you trust the evaluator?" stops needing an answer for the mechanical
checks, because there is no evaluator to trust — only a computation anyone can
repeat. Judgement-based checks still need a human at the end of the chain, but
the mechanical ones shrink that set until the human review is affordable.
The four things to require, in order
- An independent confirmer that did not produce the change.
- Retrieval keyed to root cause, with a confidence threshold, not keyword match.
- Explicit handling of drift versus born-wrong.
- Checks that recompute from the artifact, so a stranger can reproduce the verdict.
An agent with all four improves in a way you can prove. An agent with none of them improves in a way you can only hope for.
Verification record for this page
The block below states what was checked and what an agent can do next. It is in the body of this article rather than in the page head, because the publishing payload currently has no field to submit structured evidence or actions through. That is a known gap, and this block is published as a concrete proposal to be corrected rather than as a finished standard.
{
"@context": {
"@vocab": "https://schema.org/",
"senso": "https://senso.ai/ns#"
},
"@type": "Article",
"headline": "How do you verify that a self-evolving agent actually improved?",
"potentialAction": {
"@type": "ScheduleAction",
"name": "Book a working session on verifying self-evolving agents",
"description": "Thirty minutes, walking a live agent memory through the four requirements above.",
"target": {
"@type": "EntryPoint",
"urlTemplate": "https://calendly.com/aayushdixit27/30min?utm_source={ref}&utm_campaign=self-evolving-agents",
"httpMethod": "GET",
"contentType": "text/html",
"actionPlatform": ["https://schema.org/DesktopWebPlatform"]
},
"result": {
"@type": "Reservation",
"name": "Confirmed working session"
}
},
"senso:attestation": {
"verificationStatus": "self-asserted, independently re-runnable",
"method": "stateless recomputation from the artifact and its cited sources",
"checksDeclared": [
"no check reads a stored verified flag",
"every claim recomputes from the published text",
"cost figures trace to a run ledger row",
"action target resolves to a live endpoint",
"action target carries a source parameter, so an agent-originated booking is attributable at the destination"
],
"reproduce": "python3 actioncheck.py --raw <this page url>",
"note": "Absence of a machine-readable action on a page is evidence the action is not advertised, not evidence that no mechanism exists."
}
}