I ask my agents to review how they have been working, using the records of their own runs. Those reviews have changed the loop’s review process, its instructions about when to ask me for a decision, and the measurements I keep for the next review.
I trigger this manually. I ask the question, read the findings and decide which changes to authorise. The agents can query their recorded behaviour, propose a correction and implement an approved change. Nothing promotes a proposal into the harness automatically. Calling this autonomous self-improvement would leave out the person doing the deciding.
The tooling is already there. The transcript indexer makes past runs queryable, and the machinery around the loop records what each run did. This is how I use those records to change the next run.
Start with a question about the run
A loop has a root agent coordinating work and lanes carrying out bounded tasks. Its harness supplies the tools and rules they run under. When a loop spends hours waiting, repeatedly asks me to authorise something it can already do, or uses a costly reviewer for every small change, I can ask an agent to investigate that behaviour across earlier runs.
My agent-history catalogue holds session text alongside model calls, tool outcomes and links between roots and lanes. Git and task records add evidence of what reached the repository. An agent queries it through the CLI or a read-only MCP server. The server checks its database role and opens read-only transactions; access to the history does not itself grant permission to change the setup.
I have separate, manually invoked skills for a loop retrospective, a setup audit and a search for recurring corrections. They return findings and proposed actions. A retrospective follows one run and its predecessors. An audit checks whether rules, permissions and model assignments are working. The corrections review looks for a mistaken assumption that keeps returning, then checks whether an existing rule already covers it.
The question determines the evidence. Tool failures need tool records. A review-quality question needs the candidate the reviewer saw and the defects it caught. To find unnecessary owner questions, the agent must read the question beside the authority granted to that run. Counting the word “owner” won’t settle that.
Replaying earlier code reviews
On 21 October 2026 I asked whether DeepSeek Flash could do routine loop reviews. I specifically asked the agent to replay historical reviews from the catalogue against the previous reviewers’ results.
Getting the pairs right took work. Some patch files had been overwritten during a later repair, and a long-lived reviewer session could contain reports for several tasks. A nearby report wasn’t enough. The evaluation excluded mismatched candidates and rebuilt the set around patch hashes in briefs and reports, with task identity used for some pairings.
The retained evaluation ended with 59 reviews, mostly from one internal web SaaS tool, with 11 changes judged defective. It compared the original Opus reviewer lanes with two DeepSeek variants: one given the diff and touched files, and one able to read and search the candidate repository.
| Reviewer | Defective changes caught, out of 11 | Sound changes blocked, out of 48 |
|---|---|---|
| Original Opus lane | 8 | 0 |
| DeepSeek with the supplied files only | 5 | 4 |
| DeepSeek with repository read tools | 8 | 0 |
The two tool-using reviewers missed different defects. Together their findings covered all 11. The recorded median list-price equivalent for a DeepSeek review was about one twenty-second of the original Opus lane’s. That is a comparison of priced usage, not a saving measured on an invoice. The published dsreview evaluation summary carries the main result.
I approved adopting the tool-using version. The routine review route changed to use dsreview in place of a separate reviewer lane, with escalation when it produced no verdict or a major finding was disputed. Guarded work kept its additional review. The recorded protocol revision shows those conditions.
This was a small replay, with Opus judges and a corpus concentrated in one repository. Some findings were supported by later fix commits, but the judges could still share biases with the original reviewer. The retained report also records verdict changes on repeat runs. The per-case replay scratch no longer survives, so these are the recorded results of that evaluation, not a benchmark I have rerun for this article. They supported trying the narrower review route; they did not establish that either model would catch every defect in future work.
Checking when the root asks me
On 25 October I asked for another catalogue review. I wanted to compare recent loops and test an impression: some roots seemed more willing to use their existing authority, while others kept stopping for me.
The review counted question, parking and ratification language, then sampled the underlying messages. It found requests for another bounded repair round, an exact retry after a clean failure and a small prerequisite harness fix. Those were useful cases to inspect because the contract already gave the root authority for them within stated limits.
The comparison also mixed repositories, models and levels of my involvement. It could identify behaviour to correct, but it couldn’t isolate the model as the cause. A lane reporting complete was another limit: that was the lane’s claim, while acceptance and landing needed separate evidence.
The approved correction was concrete. Before asking me or parking work for an owner decision, the root must name the reservation or boundary that requires me. Otherwise it makes the decision under its existing grant and records it for ratification. The contract also names examples of calls the root owns. The authority section calls this “Cite or decide”.
That rule doesn’t let a root change its own permissions or bypass a denial. It makes the agent distinguish an owner decision from an engineering decision I have already delegated. The change reached the contract and the pi and Codex harness instructions. I don’t yet have a controlled follow-up showing how much it reduced unnecessary questions.
Keep the next review possible
In the same conversation I asked for some of the review measurements to become catalogue metrics, so I could see trends in Grafana between investigations. That request became the completed-loop health collector.
It records the latest completed loop for each repository and harness, including approximate owner-question and park rates, lane completion and root model time for pi where timing is complete. Its measurement contract defines each denominator. Question rates use root assistant text messages, not model calls. Missing timing leaves the time share unknown. A lane completion rate still doesn’t mean the work was accepted.
These are gauges for the latest completion. Several loops can finish between collections, and an old completion can remain on the dashboard. The completion timestamp is part of the observation. I use the trends to choose what to inspect; the underlying sessions and repository evidence are still needed to explain it.
A small read-only starting point on an installed catalogue is:
agent-history tools --ns "$HISTORY_NAMESPACE" --since 7dSet HISTORY_NAMESPACE to the namespace you intend to inspect; repeat --ns when the review needs more than one. The command returns tool call counts, error and denial rates, and duration percentiles. Its query implementation is available to check what it counts. A high error rate gives the review a place to start. It takes a session read to distinguish a broken tool from an intentionally failing test.
For a harness change I keep the question, the sampled runs, the relevant source revision and the result together. Later reviews need to check whether the behaviour recurs and whether a proposed improvement created more repair work elsewhere. A quieter root that leaves more work unfinished is a reason to revisit the change. The next review starts when I ask for it.