When the Plan Fails: Recovery by Controlled Replanning

Magentic-One treats a stalled team as a control problem, not merely as a bad answer. This chapter follows the Orchestrator’s transition from local progress management to strategic recovery: how a stall counter allows brief uncertainty, when repeated failure triggers reflection, and how the task ledger and plan change afterward. The goal is to understand recovery as a state transition with costs and limits, rather than as an unlimited invitation to try again.

A stall is a state, not a verdict

The inner loop gives the Orchestrator several ways to recognize trouble. The team may be repeating itself, failing to make forward progress, or producing actions that do not resolve the remaining task. Once such a signal appears, Magentic-One increments a counter for how long the team has been stuck or stalled. The counter creates a small amount of memory across local turns: the system does not have to choose immediately between pretending everything is fine and discarding the current plan.

That pause is important because not every apparent stall deserves a full reset. An external page may load slowly. A tool call may fail once because of a temporary condition. An agent may need one additional observation before it can distinguish a wrong path from a difficult but viable one. If the Orchestrator replanned after every uncertain turn, it would spend its effort repeatedly reconstructing strategy instead of completing the task. A bounded local allowance absorbs brief episodes of uncertainty.

The allowance is not the same as a retry budget with no interpretation. The Orchestrator is supposed to ask whether the next action can produce new information or change the route. A second attempt that uses a different query or checks a different dependency may be useful. A second attempt that repeats the same failed action without learning anything is evidence that the local loop is not doing its job. The counter is meaningful only when paired with the progress judgments described earlier: the system must interpret why the work is stalled, not merely count messages.

In the experiments described by the paper, the threshold is at most two. While the counter remains below that threshold, the Orchestrator can initiate another team action by selecting an agent and issuing an instruction. Once the counter exceeds the threshold, the inner loop ends and the system moves to another iteration of the outer loop. The number is a reported experimental setting, not a universal optimum. The source presents the threshold as parameterized and configurable, and it does not establish that two is the right value for every task, model, tool, or environment.

This distinction protects two kinds of efficiency. A threshold that is too low can cause premature replanning. The system may abandon a workable route before it has collected enough evidence, and the repeated cost of resetting contexts may exceed the cost of one more local action. A threshold that is too high can turn persistence into waste. The team may continue searching the same wrong place, consuming time and model calls while adding no useful state.