What Counts as Progress? The Inner Loop
In Magentic-One, the task ledger gives the Orchestrator a strategic model, but it does not answer the immediate operational question: is the current conversation actually moving the task forward? This chapter examines the progress ledger, the inner-loop mechanism that turns that question into five recurring decisions. By the end, the reader should be able to distinguish activity from progress, understand why the next speaker and the wording of an instruction affect control, and see why a successful-looking reply is not the same as a completed request.
Five questions behind every next turn
After the Orchestrator has formed a task ledger and a tentative plan, the specialized agents begin to act. The Orchestrator does not simply let the agents take turns until someone says something that sounds finished. At each inner-loop iteration, it considers the task ledger together with the current conversation and answers five questions: Is the request fully satisfied? Is the team looping or repeating itself? Is forward progress being made? Which agent should speak next? What instruction or question should that agent receive?
These questions are tightly related, but they are not interchangeable. A team can be making forward progress without being finished. It can produce a new observation while still following a bad strategy. It can choose the right specialist but give them an instruction too vague to produce a useful observation. Treating the questions separately gives the Orchestrator a way to locate the problem instead of reacting to the latest message as if it were a complete diagnosis.
1. Is the request fully satisfied?
Completion is a judgment about the user’s request, not about the most recent subtask. A browser agent may find a promising page, a file agent may extract a passage, or a programmer may produce code that runs. None of those events proves that the requested result has been delivered. The Orchestrator must compare the current state with the desired output or environment state and ask whether the remaining gaps matter.
This distinction is especially important for tasks with several dependent steps. If a user asks for a final calculation based on information found on a website, finding the page is only an intermediate success. If the page contains several candidates, the system still has to select the right one, perform the calculation, and express the result in the requested form. A local report can be accurate and still leave the overall request unsatisfied.
The completion question also protects against premature closure. A fluent agent may summarize its own work in language that sounds conclusive, even when a required criterion has not been checked. The Orchestrator’s responsibility is to treat completion as a relation between evidence and the original goal. It should not infer that the task is finished merely because the conversation has reached a natural pause.
2. Is the team looping?
A loop is more than repetition of words. It is a repeated pattern of action that does not change the relevant state. An agent may issue the same search with no change in query, return to the same page, retry the same form, or ask another agent to perform essentially the same unsuccessful operation. The transcript continues to grow, but the task does not acquire a new fact or a better route.
Loop detection therefore requires attention to actions and outcomes, not just message similarity. Two replies can use different wording while pursuing the same ineffective path. Conversely, two similar-looking requests may be justified if the first attempt changed a parameter or produced new evidence. The Orchestrator has to interpret repetition in relation to the task ledger and the observations returned by the environment.
The paper describes loop detection as one of the progress ledger’s explicit responsibilities, but it does not present the five questions as independently calibrated numerical metrics. Their quality remains dependent on the model’s ability to read the conversation and on the quality of the observations. The architecture makes the judgment visible; it does not make the judgment automatically correct.
3. Is forward progress being made?
Forward progress means more than taking another action. A useful action should reduce uncertainty, establish a needed fact, produce a valid derivation, change the environment toward the target state, or make a better next action possible. An action that consumes time while preserving the same uncertainty is activity without progress.
The distinction can be applied to a simple research task. Suppose the Orchestrator needs to determine which papers belong in a survey. A search that returns a relevant abstract may establish a fact to use in the plan. A search that returns the same irrelevant results may still be a legitimate first attempt, but repeating it without changing the query or strategy is evidence against forward progress. Likewise, downloading a paper may be progress if it supplies new content, but not if the system never opens the file or checks whether it answers the research question.
Progress is also relative to the current plan. A worker may perform a technically correct action that is unrelated to the missing dependency. If the team needs a verified source but spends several turns polishing a draft summary, the work may look productive while leaving the central gap untouched. The Orchestrator’s task-level view is what allows it to ask whether the action contributes to the requested outcome rather than rewarding effort for its own sake.
4. Which agent should speak next?
The next speaker is a routing decision. The Orchestrator uses the task ledger and current conversation to decide which capability can produce the most useful next observation or action. If a missing fact requires browsing, WebSurfer may be appropriate. If the relevant information is in a local document, FileSurfer may be better. If the next step requires a computation, the Coder and ComputerTerminal may provide complementary capabilities.
Routing at this level is deliberately broader than selecting a low-level tool action. The Orchestrator does not need to decide whether to scroll, click, or type inside a browser; the WebSurfer handles those actions within its narrower space. This hierarchy reduces the number of choices at the control layer, but it also makes the handoff important. The Orchestrator must convey what the specialist is trying to establish and how the result will affect the larger task.
A wrong speaker can create a plausible but unhelpful trajectory. Asking a coding agent to reason about a document it cannot inspect, or asking a browser agent to perform a calculation that requires reliable execution, may produce additional messages without resolving the dependency. The problem is not necessarily that the selected agent is weak. The instruction may have crossed a capability boundary that the routing decision failed to respect.
5. What should the instruction ask for?
Instruction quality determines what kind of observation returns to the control loop. “Look into this” is weaker than a request that names the missing fact, the relevant scope, and the form of evidence needed. A focused instruction can also prevent a specialist from solving a neighboring problem that sounds related but does not advance the task.
The instruction need not dictate every low-level action. The point is to specify the purpose of the next action: find whether a source contains a particular fact, inspect a file for a relevant section, write a calculation from established inputs, or execute a program and report the resulting error or output. This leaves the specialist room to use its own action space while making the expected observation legible to the Orchestrator.
The five questions work as a set. Completion defines the destination. Loop detection protects against repeating a failed route. Progress asks whether the current action changes the task state. Speaker selection chooses the capability that can create the next useful change. Instruction design shapes the observation that comes back. Removing any one of these judgments makes the others less reliable: a well-routed agent can still be asked the wrong question, and a good instruction can still be sent down a path that the team should have abandoned.
The sequence makes the ownership boundary visible. The task ledger supplies strategic context, but the specialist produces the next observation. The tool or environment supplies a consequence, but the Orchestrator decides how that consequence relates to the task. The worker does not, by itself, determine that the user’s request is complete; the Orchestrator must interpret the returned result.
When activity looks like progress
The most important failure in this inner loop is not silence. It is convincing activity that does not change the problem. Magentic-One’s error analysis describes persistent inefficient actions in which agents continue unproductive behavior despite failure. Examples include repeating the same unsuccessful web search, clicking the same page sections, accessing an incorrect data set, or following a flawed path because no one changes the strategy.
A second failure is insufficient verification. A task may be marked complete before the data, computation, or final criteria have been checked. This is a direct challenge to the completion question: the Orchestrator may answer “yes” because the transcript contains a confident result, while the evidence needed to justify that result remains missing. The progress ledger creates a place to ask whether verification happened, but it cannot guarantee that the answer will be honest or correct.
Navigation failures show a related problem. An agent can keep moving through tabs and menus while becoming less likely to reach the target. In a stateful interface, every click may produce a new screenshot or page description, so the conversation has fresh observations. Yet if the agent has misunderstood the layout, those observations may not improve the plan. The appearance of motion can conceal a deteriorating route.
The error analysis also identifies underused resources, ignored error notifications, weak team communication, delayed feedback, flawed technical implementations, and access or security barriers. These categories point to different control failures. Underused resources suggest that the current speaker or instruction does not exploit an available capability. Ignored warnings suggest that the observation returned by the environment is not being incorporated into the task state. Weak communication suggests that a useful finding does not cross the agent boundary clearly. An access barrier may require a changed plan or human intervention, not another identical request.
The source’s categories come from an LLM-assisted analysis of sampled logs. They are evidence of observed patterns, not a perfectly unbiased measurement of all failures or a proof that each label has one root cause. That qualification matters because progress control is itself an interpretive activity. A ledger can record that an error occurred, but the system still has to decide whether the error is a temporary obstacle, a signal to change agents, evidence that the plan is wrong, or a boundary that should stop the run.
This is why the inner loop should not be understood as a faster form of turn-taking. It is a test applied to every turn: did the team learn something useful, move the environment toward the goal, and preserve enough evidence to justify the next decision? When the answer is unclear, another action may be reasonable. When the same uncertainty survives repeated attempts, continuing locally becomes a strategic choice with a cost. The next question is when Magentic-One stops granting another turn and escalates from progress control to recovery and replanning.