outer-looplisted

# /outer-loop — improve the process, not the output An **inner loop** optimizes the work: propose → run → measure → keep or roll back. An **outer loop** optimizes *how the inner loop searches*: read its traces, find where the search itself is stuck, change the mechanism, run again. The finding worth internalizing (Qu & Lu, verified): **both levels used the same LLM.** The 5x came from architecture, not a smarter model. And crucially — *parameter-level adjustments without mechanism changes yielded no reliable gains.* Tuning the knobs does nothing. Changing **how it searches** is the whole effect. **What their outer loop actually found:** the inner loop kept falling back on the model's **priors** — retrying familiar moves even after those moves stopped working. The outer loop broke the pattern by forcing exploration in directions the model's instincts avoid. **Prior-lock is the default failure of any repeated agent process.** That is what you are hunting. ## PRECONDITION — refuse to run without these four An outer loop is expensive and easy to fool. It only earns its cost when the inner loop has: 1. **A metric.** A number that moves, in the right direction, without a human deciding. (`val_bpb`, tests passing, exit code, row-count parity, build time, cost per run.) *No metric → stop. Say so plainly and offer to build the metric first.* 2. **Traces.** Logs of what the inner loop actually tried and what happened — not just the final artifact. You cannot diagnose a s