The hill-climbing loop

The outermost loop is the one that improves the others. It reads what actually happened — the traces, the failures, the escalations — and changes the harness: the prompts, the tools, the rubrics, the guards. The outer loop reaches inside and edits the inner one.

This is where the whole platform converges. Loop four needs traces, which loop three produces. It needs a way to tell whether a change helped, which is an eval. It needs failure modes to be named and counted, which is error analysis. None of that is new; what is new is doing it continuously rather than at the end of a project.

• Sample real traces regularly, and read some by hand. Aggregate metrics will not show you a failure you have not thought to measure.
• Group failures into named modes and count them, so you work on the largest rather than the loudest.
• Change one part of the harness at a time, and check the change against a dataset rather than against your impression.
• Add each newly discovered failure to the dataset, so the harness cannot regress on a lesson it has already learnt.

It is tempting to automate this fully — an agent that reads its own traces and rewrites its own rubric. That works for narrow, well-measured changes and fails at exactly the point that matters: deciding what good means. A loop optimising a rubric it also wrote will find a comfortable local maximum and stay there.

Which is the honest place to end. Every source on loop engineering arrives at the same limit: verification of behaviour has no settled answer. Maintainability can be enforced by tools, architecture can be checked by fitness functions, and whether the thing does the right thing for the right reasons remains a human judgement encoded, imperfectly, into checks. Loops amplify that judgement. They do not supply it.