Paper Walkthrough: PILOT in the Loop — Fixing the Run While It Is Still Running

Agent self-improvement that only starts after execution ends arrives too late. A ground-up walkthrough of PILOT, a supervisor–worker harness that redirects the live run while distilling skills from it, from intuition to equations to measured numbers and stated limits.

PILOT in the Loop: Live Self-Improvement for Long-Horizon Agents

Watching the dashcam after the crash

The paper we are reading is "PILOT in the Loop: Live Self-Improvement for Long-Horizon Agents" (arXiv:2608.26530, published 27 August 2026, AllSpark Team).

Here is what the abstract claims, restated. Long-horizon agent runs generate experience that could improve both the current run and future work. But most self-improvement methods process that experience only after execution ends, so they cannot redirect the active run, and they cannot immediately apply and validate the lessons the run just taught them. The authors argue self-improvement should instead be live. Existing architectures do not support this: single-agent self-correction packs task execution and trajectory assessment into one context, while subagent delegation separates execution but typically cannot redirect an active subagent. Their answer is PILOT, a supervisor–worker harness built from two coupled mechanisms. (1) Live steering lets a separate supervisor redirect or abort the active worker during execution. (2) Live self-evolution distils procedures and failure modes revealed during execution into reusable skills and memory. Across two frozen backbones and three benchmarks, PILOT ranks first in five of six configurations. On Terminal-Bench 2.0 it outperforms counterpart harnesses by up to 9.8 percentage points; in the self-improvement setting it gains 14.6 points with GLM-5.1 and 12.4 points with Kimi-K2.6, while mean output tokens fall by 42.9% and 47.4% and successful evaluations per million output tokens rise by 110.3% and 134.0%.

The word "harness" recurs throughout. It means everything outside the model weights: prompts, a skill library, memory files, tool definitions, the execution loop. When this paper says self-improvement, it means the evolution of the persistent harness $H$, not an update to the model parameters $\theta$ (§2). The weights stay frozen from start to finish.

A metaphor: the instructor in the passenger seat

Think about learning to drive.

Approach A (conventional self-improvement) sends the student out alone and reviews the dashcam footage together afterwards. You learn "you should have turned there," but that drive is over. Worse, you cannot tell whether the lesson is any good until the next drive. This is what reflection, judge-based evaluation, and post-hoc harness updates do (§1).

Approach B (single-agent self-correction) asks the student to grade themselves. But the student's head is full of clutch work and following distance. In the paper's phrasing, execution details occupy the same context needed for diagnosis, making it harder for the agent to recognise and correct a strategy that is not working (§1).

Approach C (PILOT) puts an instructor in the passenger seat. The instructor never takes the wheel — the student remains responsible for the drive to the end. The instructor only does two things: speak up when an outside view reveals a dead end, and write down "this parking procedure is worth keeping." The student's attention can stay on driving; the instructor's attention can stay on the destination and recent events. That separation of roles is PILOT's design thesis.

Why longer work breaks more

Why long-horizon tasks are hard falls out of a single multiplication. Let $p$ be the probability that any one step goes right and $n$ the number of steps required. With nobody correcting the course, the probability of arriving intact is:

Stated in words: the per-step success rate, multiplied by itself once for every step. Even at $p = 0.99$, an $n$ of 300 drops you to about 5%. As the step count grows, success is eroded exponentially, not linearly. That is why, on long work, whether anyone can correct the course even once changes the outcome.

The paper backs the same intuition empirically: harder tasks require longer, more fragile execution chains in which errors can compound, leaving more opportunities for the supervisor to recover the run (§4.2).

Supervisor and worker: what persists, what stays frozen

Here is the setup in symbols (§2). A long-horizon task $\tau$ is attempted in a single episode inside an environment $\mathcal{E}$ whose state changes with the worker's actions. The model parameters $\theta$ remain frozen. The persistent harness $H$ contains a skill library $\mathcal{K}$ and memory $\mathcal{M}$, and these survive across episodes.

During an episode the supervisor can spawn one or more workers:

Meaning: worker number $j$ is built from the frozen model $\theta$, the objective $\tau_j$ it was handed, and the harness $H$ as it stands right now. Workers may run concurrently or be spawned later as earlier ones settle. Each loads the current $H$, operates in an isolated context, and produces a trajectory $\xi_j$ of actions and observations in $\mathcal{E}$.

This is where the design earns its keep. The workers' exploration, dead ends, and verbose tool output stay in their isolated contexts by default (§2). The supervisor reads the relevant portion of a trajectory only when diagnosis is needed. That preserves the supervisor's context for the goal, recent events, and recurring failure patterns — a structural answer to the problem that sank single-agent self-correction, where the diagnosing brain gets buried in execution logs.

And the paper draws its boundary explicitly: throughout, self-improvement refers to the evolution of the persistent harness $H$, not an update to $\theta$ (§2).

A two-way channel made of five operations

Live steering turns out to be a remarkably small interface. During the episode, the supervisor stays connected to every active worker over a two-way live channel. Per worker session there are exactly three worker-to-supervisor events and two supervisor-to-worker actions (§2).

1. Notification. The worker decides when to report progress, an intermediate result, or a potential risk. Execution continues after it is sent.
2. Question. The worker decides that its next step needs supervisory input, and pauses until the supervisor replies.
3. Result. When a worker finishes, the runtime automatically delivers its final result and worker index $j$ to the supervisor.
4. Steer. When live evidence says the course should change, the supervisor inspects the relevant portion of $\xi_j$ and queues guidance for that worker's next turn. The current turn finishes first.
5. Abort. The supervisor interrupts an active worker $W_j$ when continuing that session is no longer useful.

Condensing the pseudocode from Appendix A.2, the supervisor loop looks like this:

repeat
  if another worker is needed: W_j ← Spawn(θ, τ_j, H)
  receive event (j, e) from any active W_j
  if e is a question            → reply to W_j
  if redirection is warranted   → inspect relevant part of ξ_j → Steer
  else if continuing is useless → Abort
  if reusable knowledge in ξ_j  → H ← Update(H, ξ_j)
  if e is a result, error, or abort → mark W_j settled
until the task is resolved or no further worker is needed

The detail that Steer is queued for the next turn rather than interrupting the current one is quiet but load-bearing. If you need to stop something immediately, the operation you want is Abort, not Steer.

The implementation is an extension to the Pi coding-agent runtime; the supervisor is an agent session and workers are spawned in-process as separate sessions. In the experiments, following a real-world usage scenario, the same frozen model fills both roles (§2) — which isolates the supervisor–worker orchestration from any capability gap between the two (§3.1).