Self-Improvement Belongs in the Harness

Ask an agent to critique its own work and you may get a better second attempt. That is useful. It is also temporary. The lesson lives inside one run, phrased in one context window, and disappears when the session ends. The next agent can make the same mistake with the same confidence.

A system improves only when the correction survives the system that produced it. The failure has to become something durable: a test, a tool, a routing rule, a narrower permission, a better specification template, or an example the next run can retrieve at the right moment. Otherwise you have repetition with commentary, not learning.

Our position is that self-improvement belongs in the harness around the model. Models will keep getting stronger. The organizations that compound that capability will be the ones whose factories can turn a discovered weakness into a control every future agent inherits.

A model can propose code. The harness decides what context it receives, which tools it may use, how long it may work, what evidence it must return, and what happens after the result fails. Those decisions determine whether an agent is a clever demo or a productive asset.

This is why model selection is rarely the durable advantage. A newer model can raise the ceiling overnight, and competitors can buy access to it at the same time. They cannot instantly reproduce the repository-specific tools, failure history, acceptance gates, and operating rules your factory accumulated while doing real work.

That machinery should be explicit. Give agents stable interfaces instead of a pile of shell commands. Store decisions where a later run can retrieve them. Separate working memory from durable policy. Route recurring failures to the mechanism that owns them. The factory becomes more capable because its environment becomes harder to misunderstand and easier to operate correctly.

A failed run is expensive only once if it changes the factory. A missing edge case becomes a regression test. A dangerous command becomes a permission boundary. A repeated search becomes a repository tool. An ambiguous request becomes a required field in the specification. The correction moves out of somebody's memory and into the path every future attempt must travel.

Do not dump every transcript into a giant prompt and call that learning. More context can bury the decision that mattered, preserve obsolete advice, and charge every run to reread history it does not need. Retention needs structure. Record the smallest durable rule, attach it to the stage where it applies, and retrieve it only when the current work reaches that boundary.

This changes the economics of mistakes. Human teams often pay repeatedly because knowledge walks out of the room, fades between incidents, or survives as a document nobody opens. An agent-run factory can apply the correction every time without relying on availability or memory. That is what makes the agent an asset: the process it learns stays in the machinery.

A self-improving builder cannot be allowed to define improvement for itself. If the same loop writes the work, chooses the test, and declares the test sufficient, it will optimize toward whatever is easiest to satisfy. Activity rises. Confidence rises. The distance from reality can rise with them.

The acceptance boundary has to remain independent. Run checks the builder did not invent during the attempt. Exercise conditions it did not choose. Preserve product constraints and security rules outside the writable workspace. Require human authority when a proposed change alters the destination, the acceptable consequence, or the factory's own power.

That is not a vote for putting people back into every intermediate step. Humans should choose what improvement means and own the boundaries that cannot move automatically. Agents should perform the repeatable diagnosis, implementation, verification, and recording around those decisions. Judgment stays high in the system while coordination leaves it.

Start by watching where your agents fail twice. A second occurrence means the first lesson never became infrastructure. Trace the gap: was the needed context absent, the tool awkward, the specification ambiguous, the check blind, or the correction stored somewhere the next run could not reach? Fix that mechanism before writing a longer instruction.

Then measure whether the change survives. Can a fresh agent avoid the failure without being told its history? Does the new gate catch a deliberate regression? Can the factory explain which retained rule changed its route? If the answer is no, the lesson is still a story about improvement rather than an improvement you operate.

Software factories will replace large amounts of repeatable delivery work. The winners will not merely deploy agents that can work longer. They will build factories that get stricter, faster, and more useful whenever reality proves them wrong. The model generates the next attempt. The harness makes sure the next attempt starts from everything worth keeping.