Hour six of a long run. The agent has called the same tool with the same malformed argument four times, re-read the same three files between attempts, and is now drifting toward the end of its budget with the task unfinished. You have two obvious moves: kill it and start again with a better prompt, or let it burn. Both throw away the six hours of context already assembled, which is most of what the run is worth. There is a third move, and it is stranger than it sounds. The episode edits its own instructions while running, and carries on from exactly where it was.

A guide fixes the line between rapids

On a multi-day river trip you cannot pull over inside a rapid, and you cannot start the trip again on Thursday. What a guide does instead is read the stretch just run, adjust in the calm below it — a different line through the next drop, one person moved to the other side of the raft — and keep going. The correction happens at the eddy, not at every wave. Someone who re-plans on each splash arrives late, tired, and no drier than anyone else.

Online in-episode harness refinement is that habit written as code. At defined intervals, a refiner reads a recent window of the trajectory and looks for a short list of symptoms: navigation loops, failed tool calls, goals that have stopped moving, knowledge that has gone stale. Then it edits the harness in place. It rewrites the system prompt, creates or deletes a subagent, encodes a skill, updates memory. In the stuck run above, it adds a pre-check skill and writes the correct argument format into memory, and the episode continues from there. No reset, no retraining, no new weights.

Adaptation earns its keep on long tasks

This pays where the work is long and the ground keeps moving: the schema changed halfway through, the repository is not the one the prompt described, the strategy that looked right at hour one is a dead end by hour six. On a short, stable task it is machinery you do not need. And it cuts both ways, because whatever can rewrite the system prompt can also rewrite it badly, on a running episode, with no clean state to fall back to.

So the decisions that matter sit around the refiner rather than inside it. The window is one: edit on a window of trajectory, never on a single noisy step, or one unlucky tool response rewrites how your agent behaves for the rest of the day. Persistence is another: a correction that belongs to this run alone, a path or a session identifier, is temporary memory, while the correct shape of a tool call is knowledge worth keeping, and treating the first like the second contaminates everything downstream. The third is a capability floor you have measured rather than assumed. A refiner changes what the model is working with. It does not make it a better model.

A trip that leaves the guidebook better

The state an episode evolved into does not have to die with it. Saved, it becomes the starting point for the next run, and that is where the second idea begins. Persistent playbook distillation treats every generation as something that files a report — strategy, analysis, score and trace, written into a run directory on disk rather than held in a context about to be cleared. A separate curator reads those runs and does the sorting the run cannot do honestly about itself, lesson here, dead end there, and updates the playbook for that scenario. Later runs load it as initial context.

An agent that keeps settling billing disputes with the same sequence of checks already has a playbook inside it. Distilled, it becomes an entry with conditions of use and known failures, and the next generation applies it without rediscovering the procedure. What ruins the entry is the guidebook line that says take the left channel without saying at what water level: a strategy promoted to permanent rule with no scenario attached, no trace behind it, and no record of why it worked. Not every success deserves to become policy.

Because these are files, they can be read, diffed, replayed, even turned into training data later. The overnight search that rewrites the harness and measures it is a slower loop with a benchmark attached; this one runs inside the episode you already have. Neither touches the weights. The model you finish with is the model you started with, and everything that got better was written down somewhere outside it.