When the Loop Stalls: Evidence, Replan, and Self-Repair
LoopX is designed for a difficult moment in long-running work: the system is active, but activity no longer proves that the Goal is moving. This chapter focuses on how to diagnose that condition and choose among continuation, retry, waiting, replan, self-repair, blocking, or closure. The practical test is whether a turn adds a material evidence delta, changes the machine-visible frontier, or proves why the only honest action is to wait.
Busy is not the same as progress
A stalled agent rarely looks completely idle. It may produce a new log summary, edit another file, rerun a test, poll a provider, or announce that it has reconsidered the plan. Those events are observable activity, but they do not all change the Goal. A new diff can leave the acceptance gap exactly where it was. A successful command can prove only that a process exited. A monitor can be polled without the external state changing. A completed local Todo can leave an unresolved Gate, successor, or acceptance condition behind.
The first diagnostic question is therefore not “did the Agent do something?” It is “which authoritative fact changed, and why should that change alter the next decision?” LoopX's evidence model gives several possible answers:
- a new observation changes the domain judgment;
- evidence supports or excludes a testable explanation;
- a validated artifact satisfies an acceptance condition;
- a successor, Gate, blocker, Vision checkpoint, or no-follow-up changes the frontier;
- an external effect receives a receipt bound to its proposal, revision, and readback;
- the system proves that it can only wait, with a target, cadence, and recovery condition.
These are material deltas because they affect what a future executor is allowed or expected to do. By contrast, another copy of the same summary, another unchanged poll, or a generic “continue analysis” note may be useful for debugging but should not impersonate Goal advancement.
This distinction is especially important for two different forms of failure. Goal drift occurs when a local proxy begins to replace the original acceptance. For an issue fix, “there is a new commit” can replace “the issue is resolved and the change is reviewable.” For an experiment, “the development metric improved” can replace “the result is comparable, survives the guardrail, and answers the research question.” Local looping occurs when the Goal remains conceptually correct but the same action family repeats without new information, state change, or failure discrimination.
The symptoms overlap, but the remedies differ. Drift requires checking Vision and Acceptance. A local loop requires checking whether the next attempt can produce new information and whether the route should be changed. A provider timeout requires reconciliation. A stale dashboard requires projection repair. An external condition that has not changed but may change later needs a monitor and backoff, not a new implementation attempt.
LoopX treats repeated surface-only or no-progress work as an outcome-floor problem. The size of a change is not enough: a multi-file diff can still be surface-only, while a small state correction can restore the causal link between an accepted artifact and the correct Todo. After repeated low-value turns, the system may require a genuine outcome or a control-plane repair before ordinary delivery continues. The current material uses operational thresholds such as consecutive stalled turns, but those thresholds are policies for governing a loop, not mathematical proof that every domain has converged.
The distinction between continuation, retry, replan, and self-repair can be stated in terms of what changed.
Continuation keeps the same Goal meaning, frontier, and legal route. The current Todo remains the right Todo, the evidence is still applicable, and another bounded segment is justified.