When an AI keeps rewriting its own prompts and code, can anyone tell which edits actually helped, and what they cost?

This explores what you can learn by auditing the record of a self-evolving agent (the trail of edits it made to its own prompts, tools, and code) about which evolution cycles helped and what they cost. The corpus has no paper that runs this audit end to end. It does show what an audit would need, and how much of the current evidence fails that bar.

The flagship example is Ouroboros, a harness that rewrites its own tools, prompts, and core through reviewed commits. It reports 86.97% on Terminal-Bench 2.1 and 90.69% on OSWorld-Verified, but the paper has no ablation studies, so nobody can say how much of those scores comes from evolution and how much from the underlying agent (Does self-editing through reviewed commits improve agent performance?). The commit trail is a record of what changed. It doesn't tell you which change mattered. A trajectory audit's first finding is that a trail is not attribution.

The cost side is easy to miss. Every evolution cycle spends feedback and inference compute, and that spending is the price of any gain. The corpus argues that harness evolution has to be compared against plain task-level test-time search given the same feedback and inference budget. Only gains beyond what that matched search achieves belong to the harness design (How should we measure gains from automatic harness evolution?). Without that comparison, a cycle that looks like a contribution may just be extra computation.

Several designs make cycle-level accounting possible. Autogenesis treats prompts, tools, and memory as versioned resources with lineage and rollback, so each update is measurable, attributable, and reversible (How can agent self-evolution be made safe and auditable?). Dr. Claw keeps the coding agent fixed and wraps it in persistent state, so the process trail is traceable and recoverable (Can orchestration layers make coding agents more auditable?). ModularRSI goes after contribution directly. It evolves harness modules using contrastive trajectories on data disjoint from the benchmark, then aggregates evidence across tasks before touching a component. That separates a reusable mechanism improvement from an adaptation to one task (Can harness modules improve separately from benchmark data?).

The corpus also gives reasons to distrust a clean-looking audit. Trajectory-level evaluation doesn't remove the old problems of comparability, reproducibility, and mapping evidence to judgment. It moves them into a higher-dimensional space, so it needs shared protocols, not just a trajectory format (Do interactive evaluations actually solve the benchmark comparison problem?). Self-improvement without outside signals stalls on the generation-verification gap, diversity collapse, and reward hacking. Reliable methods bring in external anchors such as past model versions, third-party judges, user corrections, or tool feedback (Can models reliably improve themselves without external feedback?). So an audit should ask what verified each cycle. BenchShield's idea of checking a benchmark run against an intended lifecycle of events could help flag a score-boosting cycle that took a shortcut (Can a finite lifecycle model detect reward hacking across benchmarks?).

So far the audit mostly reveals what is missing. Evolution's contributions are asserted, not isolated, and its costs are rarely priced against a matched-budget baseline. The pieces that would fix this (versioned lineage, disjoint-data evolution, matched baselines, external anchors) exist in the corpus, but no single paper combines them.