Launching a Self-Modification Review Queue Without Losing Operator Control

This article presents a launch pattern for turning low-reward signals into bounded change proposals: preserve the current skill, write a complete candidate to scratch, route it for review, and verify the proposal without editing protected paths.

This article shows how to design a review-queue lane for agent self-improvement, using file boundaries and completion evidence to keep adaptation useful without making it ambient authority.

Start with a proposal, not a privileged edit

The first design choice is deceptively important: the self-modification worker should not edit the live skill directly. It should read the current target, derive an improvement, and write the full proposed body to a scratch location associated with one run.

That separation creates a clean distinction between “the system has an idea” and “the system has changed.” A proposal can be inspected, compared, rejected, or applied through a separate approval path. If the proposal is poor, the live behavior remains unchanged. If the worker crashes midway, it does not leave a half-written instruction file masquerading as a successful update.

A useful proposal record names four things:

• the target skill path;
• the scratch path containing the complete proposed file;
• the signal that motivated the change;
• the expected improvement and its limits.

The proposal should be self-contained. A reviewer should not have to reconstruct the intended file from a patch fragment or infer which missing lines were meant to remain unchanged.

Treat paths as part of the contract

Self-modification is safer when path rules are explicit enough to reject mistakes mechanically. The target should identify the permitted lane—for example, a particular skill under my-skills/—while protected paths such as the server, public application code, package definitions, or the reference skill tree remain out of bounds.

The scratch artifact belongs in a run-specific directory, such as:

``text COO-FILESYSTEM/scratch/idle_self_mod/<run-id>/proposed.dal ``

The run identifier makes the proposal traceable and prevents two attempts from silently overwriting one another. It also gives the operator a durable place to inspect the exact candidate that was submitted.

Path discipline is not bureaucracy around the feature. It is the feature’s containment boundary. A model can produce a sensible rationale while still naming the wrong destination. Validation must therefore check the path independently of the prose.

Turn a low-reward signal into a falsifiable change

A reward or failure signal is evidence of a problem, not proof of a solution. “This pattern received a low score” is too vague to justify an edit. The proposal should state what repeated behavior was observed, what instruction is being changed, and how a later run could show improvement.

For an artifact workflow, a good hypothesis might be: the skill should read recent drafts before choosing a topic, enforce the required article structure, and verify the exact output path before claiming completion. Those are observable behaviors. A weak hypothesis would be: make the agent more careful.

The proposed instructions should also preserve uncertainty. If the evidence is thin, the change can say that the next evaluation is exploratory or insufficient for a verdict. That is better than encoding a confident rule based on one unusual run. Self-modification should improve the quality of future evidence, not manufacture certainty from the signal that triggered it.

Make review the normal boundary for broader change

A review queue is most effective when it has a narrow, predictable role. Local instruction improvements may be proposed automatically; changes that broaden authority, touch external systems, delete data, publish content, or alter protected code should remain review-gated.

The review item should answer practical questions:

1. What behavior prompted the proposal?
2. Which exact target is affected?
3. What does the candidate change do differently?
4. What evidence would count as improvement?
5. What would make the proposal unsafe or require rejection?

This keeps approval from becoming a ceremonial click. The reviewer is deciding whether a bounded experiment is worth running, not merely endorsing a vague promise of learning.

A proposal can also be rejected without being treated as a system failure. “Changes required” is a useful outcome when the direction is reasonable but the scope, evidence, or acceptance test is incomplete. “Blocked” is appropriate when the target is outside the lane or the change would create a prohibited side effect.

Verify the artifact before claiming progress

Completion should be proven in two stages. First, verify that the scratch proposal exists at the exact expected path and contains a complete body. Second, verify that the response identifies the intended live target and explains the rationale in a machine-readable form.

That final record matters because a successful file write alone does not prove that the proposal is reviewable. The proposal may be empty, aimed at the wrong skill, or missing the reason it exists. A compact result can carry the essential linkage:

``json {"path":"my-skills/example.skill.dal","proposed_path":"COO-FILESYSTEM/scratch/idle_self_mod/run-123/proposed.dal","rationale":"Adds explicit source checks and artifact verification after repeated incomplete runs."} ``

The system should not claim that the live skill improved until a separate approval-and-apply step occurs and a subsequent evaluation supplies enough evidence. Proposal creation, application, and verified improvement are three different states.

Keep the lane subordinate to committed work

Self-modification should not outrank work that an operator has already committed to. If a queue contains an unfinished delivery, a missing verification, or a required review, the improvement pass should wait or restrict itself to preparing a proposal with no external effect.

This ordering prevents a subtle failure mode: the agent becomes very good at improving its own workflow while neglecting the work that justified the workflow. It also reduces review noise. A bounded proposal created only from a concrete signal is easier to evaluate than a stream of speculative optimizations generated whenever the system is idle.

The calm operating posture is straightforward: drain known commitments, preserve approval gates, and use idle capacity for reversible preparation or verification. Self-modification is another work type inside that queue—not an exemption from it.

Conclusion: make adaptation inspectable before making it automatic

A review-queue lane gives self-modification a useful middle ground between frozen instructions and unrestricted rewriting. The system can learn from a concrete failure signal, prepare a complete candidate, and make its reasoning available for approval while the live behavior remains stable.

Builders can implement the pattern with five concrete steps:

1. Define the allowed target paths and protected paths.
2. Require a run-specific scratch artifact containing the full proposed file.
3. Demand a falsifiable signal, expected improvement, and rejection condition.
4. Route external, destructive, or authority-broadening changes to review.
5. Verify the proposal path and result record before claiming completion; verify improvement only after later evidence.

The goal is not to prevent agents from changing. It is to ensure that every change begins as something a human can locate, understand, and decline.