A post from Vasilije (@tricalt) in mid-March 2026 laid out how Cognee handles agent skills. The framing is worth borrowing because it takes a phrase that usually invites hype or alarm, self-improving agents, and reduces it to a file management problem.
Agent skills are files. Prompt files, instruction files, the SKILL.md pattern. They are static artifacts sitting in an environment that may not hold still. Models get upgraded, codebases get refactored, task definitions shift. When that happens and the file does not change, the file becomes wrong. How fast this bites depends entirely on the skill: one that describes a stable internal convention may not rot on any observable timescale, while one that encodes an API shape or a directory layout can go stale in a sprint.
The inversion
Most commentary treats self-modification as the interesting part. The rollback is the interesting part.
Giving an agent write access to its own instruction file has never been the hard problem. What takes engineering is the surrounding apparatus: a saved prior version, an evaluation gate the new version has to pass, and a log entry explaining why the change happened.
So the capability worth naming is "the agent's changes are reversible and attributable." The same edit, wrapped in evaluate and revert, becomes a normal software change.
This reframes the risk profile. The dangerous version of a self-editing agent is the one that writes something plausible, nothing breaks loudly, and six weeks later you cannot reconstruct which of forty silent amendments introduced the regression.
How skills actually fail
The failure modes described are specific and not exotic:
- Wrong triggers. The skill fires when it should not, or stays silent when it should have engaged. The activation condition described a codebase or workflow that no longer exists.
- Stale conditions. Branching logic that referenced an API shape, a directory layout, or a model behavior that has since changed.
- Mismatched output formats. The skill produces something the downstream consumer used to accept. That contract moved.
The first two rarely announce themselves. A wrong trigger looks like an agent that is slightly unhelpful. A stale condition looks like an edge case. Format mismatches often do throw, though even then they can degrade into a partial parse rather than a clean failure.
That asymmetry suggests drift needs monitoring, not just better authoring. It does not prove it. Silent failure could equally point to under-specified contracts, in which case tighter interfaces between skill and consumer would catch more than any scan.
The loop
The proposed cycle is four steps: observe, inspect, amend, evaluate.
Read in order, it is unremarkable. Read for what it excludes, it is stricter than a workflow where the agent simply rewrites the file: there is no step called "the agent decides its new prompt is better." Evaluate is a separate stage with its own authority, and the stated constraint is direct: self-improvement must never be trusted without evaluation.
That separation is the load-bearing claim, and it is worth being precise about why. The comparison to code review is imperfect. Authors write their own unit tests all the time, and review works largely because a human with independent judgment reads the diff. An agent evaluating its own amendment has neither the independence nor the judgment. The separation only helps to the extent the evaluator is genuinely a different mechanism with different failure modes, rather than the same model asked a second time.
The concrete shape:
- Snapshot the current version of the skill file before any edit, as a stored artifact you can restore from.
- Write the amendment with a rationale attached, dated, grounded in the specific observation that prompted it. "Improved clarity" is not a rationale. "Trigger fired on three unrelated file types in the last review window" is.
- Run the evaluation. If the amended version regresses, revert to the snapshot.
- Append the whole transaction to an audit log. What changed, why, when, what the evaluation said.
The log produces nothing today, which is why it gets skipped. Along with the snapshots, it is what makes month-four debugging tractable.
The problem this depends on
Here is the difficulty the loop does not resolve. Building a meaningful eval for a prompt file is substantially harder than building the amendment loop around it. The source describes the loop and does not describe the evaluator.
That gap matters because the loop's value is proportional to the evaluator's strength. A rollback gate with a weak evaluator can pass changes it should catch, and it will report those passes with the same confidence as any other. The snapshots and the log survive that failure, since a record of bad changes still lets you reconstruct what happened. The gate does not. If you cannot articulate what your evaluator measures, you have versioning and provenance, which is worth having, but you do not have a quality control mechanism.
A weaker gate is more achievable than a strong one. It is difficult to prove a prompt got better. It is somewhat easier to detect that a case which used to produce acceptable output no longer does. Somewhat, not trivially. Regression detection for open-ended text output has the same measurement problem in a smaller form, and a fixed set of golden cases will drift out of relevance for the same reasons the skill did. But a stable regression suite is a target you can build toward, and "did not regress" is a weaker claim that fails less silently than "improved."
Where this points operationally
Two extensions follow reasonably directly, though the source does not report them as practice.
Skill health checks want a schedule rather than a complaint. If skills degrade as their environment moves, detection triggered by someone noticing odd output will always lag. The unresolved part is what the scheduled pass actually measures, which is the evaluation problem again wearing a cron job. A pass that reports how often each skill fired, against what, and whether the output parsed is at least cheap and grounded in observable events, even if it cannot judge quality.
Regression should be the gate rather than improvement, for the reasons above. Optimizing for "did not break" concedes that you cannot measure progress and builds on the thing you can measure.
The honest caveats
This is one practitioner's approach described publicly. Treat it as a coherent hypothesis about skill maintenance, not a benchmarked result.
There is also a scale question. Snapshot, evaluate, log, and revert is cheap discipline for a handful of skills. Across hundreds, with interdependencies, both the cost of the loop and the risk that an amendment breaks a neighboring skill rise. That tradeoff is not addressed, and it may change the right answer at volume.
What to take from it
The useful reframe is that this is version control applied to a file type that often still gets treated as configuration: edited in place, without diffs, without review, without a way back.
If an agent can amend its own instructions and you have the snapshot, the rationale, and the log, you have a traceable component. Add an evaluator you can actually defend and you have a maintainable one. With none of it, you have an unversioned file with write access.