From Ledgers to a Recoverable Work Cycle

The first four mechanisms in Magentic-One become meaningful only when they operate together. This checkpoint connects the task ledger, progress ledger, nested loops, and bounded recovery around one open-ended task pattern. The practical judgment is simple but demanding: when a run falters, should the system take another action, change the plan, verify the result, or stop and escalate? Tracing the complete cycle makes clear both what ledger-based control contributes and what it cannot supply.

One task, two clocks

Consider the kind of multi-step request used to illustrate Magentic-One: inspect an attachment containing a program, run it against supplied inputs, follow the output to another source, extract a second program, execute it, and return a calculation. The details are less important than the dependency chain. Each action produces an observation that determines whether the next action is sensible. The final answer cannot be judged by looking at only the last tool call.

At the strategic level, the Orchestrator turns the request into a task ledger. It can record what the user has provided, which facts still need to be looked up, which results must be derived, and which assumptions are only educated guesses. It also forms a natural-language plan that connects the goal to assignments. The ledger does not need to predict every click or command. It needs to preserve the distinctions that will matter when the first observation arrives: what is already established, what must be checked, and what kind of capability can close each gap.

At the local level, the Orchestrator uses the progress ledger while agents act. It asks whether the request is satisfied, whether the team is repeating itself, whether the latest work is advancing the goal, which agent should speak, and what that agent should be asked to do. The task ledger gives these decisions their meaning. Without it, the Orchestrator might know that a worker returned a result but not whether the result resolves a required dependency. The progress ledger gives the strategic model a rhythm of action and observation. Without it, the plan could remain on the page while the conversation drifts.

The two levels therefore run at different clocks. Strategic state changes when the system learns something that affects the overall route: a source is unavailable, an assumption is contradicted, a required computation is still missing, or a failed path should no longer be attempted. Local progress changes on each turn as an agent acts and reports. A local turn can be successful without changing the strategic plan; it can also reveal that the plan has become untenable. Confusing these clocks creates two opposite errors: replanning after every minor uncertainty, or allowing local activity to continue long after the strategic route has failed.

A complete cycle looks like this. The Orchestrator reads the current task state and assigns a capability-oriented subtask. A specialist acts in its own action space and returns an observation or error. The Orchestrator interprets that result against the task ledger and progress questions. If the observation closes a gap or enables the next step, the inner loop continues. If it reveals a temporary uncertainty, the system may allow another bounded action. If the team repeats an unproductive pattern, the stall counter crosses its threshold, and control moves back to the outer loop.