A Goal Becomes a Working Model: The Task Ledger
In Magentic-One, the task ledger is the Orchestrator’s first defense against confusion. The important question is not how to make a longer plan, but how to represent what is known, what is missing, what can be derived, and what is only a guarded assumption. Understanding that distinction lets the reader judge why Magentic-One can revise its route without losing the user’s goal—and why the ledger is more than a checklist.
Four kinds of knowledge in one ledger
When Magentic-One receives a task, the Orchestrator does not immediately pick a worker and start clicking or coding. It first reflects on the request and pre-populates a task ledger, which the paper describes as short-term memory for the duration of the task. The ledger records several kinds of information because they carry different levels of certainty and require different ways of becoming useful.
Given or verified facts are the stable starting material. They may come directly from the user’s request or from an observation that has already been checked. If a task includes a file, the file’s presence is a fact; if an agent has confirmed the contents relevant to the request, that observation may become another. These entries define what the team can safely use without spending another action to establish it.
Facts to look up are claims that require an external observation. A request might depend on a current web page, a paper’s abstract, a map location, or information inside an attached document. The ledger does not treat the missing answer as if it were already known. It marks the gap and leaves room for an agent with the appropriate access to fill it.
Facts to derive are not necessarily found anywhere in the environment. They may require a calculation, a piece of code, or a chain of reasoning from information already collected. This distinction matters because retrieval and computation are different operations. A browser can locate source material, but a program may still be needed to compare values or produce the requested result.
Educated guesses are the most delicate category. The Orchestrator can record qualified closed-book information that might help the team when it is stuck or running out of time, while keeping the guess distinct from a verified fact. The point is not to disguise uncertainty. A guarded guess can provide a fallback or a clue about where to search, but it should not silently become evidence merely because the system has written it down.
These categories turn uncertainty into an object the system can manage. Without them, a conversation tends to flatten different statements into the same stream of text. A user’s premise, a page observation, a model’s remembered fact, and an untested inference may all look equally fluent. The ledger gives the Orchestrator a place to keep them separate. That does not make the classification infallible—the underlying model can still misclassify a claim—but it creates a structure in which the distinction can be made and revisited.
The categories also connect knowledge to action. A fact to look up suggests a web or file operation. A fact to derive suggests coding or deliberate reasoning. A given fact may constrain the plan without requiring another tool call. An educated guess may be held in reserve rather than sent to a worker as an instruction. The ledger is therefore not only a record of epistemic status; it is a bridge between the state of the task and the capabilities that may be needed next.
Consider the report’s example of producing a survey and slide presentation about recent AI-safety papers. The Orchestrator may know the requested time window and the required output format from the user. It may need to look up paper abstracts and download the relevant documents. It may need to derive a comparison across the papers, then use code or another tool to assemble the presentation. If a paper cannot be accessed, a qualified guess about its likely topic might help the team search for an alternative, but it cannot be allowed to carry the same authority as the paper itself. The value of the ledger is that all of these statements can coexist without being confused.
The task ledger is not presented as a formal database schema, and the report does not show that every update improves the result. It is a structured working-memory concept implemented through the Orchestrator’s reasoning. That makes the design flexible, but it also leaves an important dependency visible: the system must interpret its own observations and maintain the distinction between evidence and assumption.
The categories are best understood as states that can change, not permanent labels attached to a sentence. A fact to look up may become a verified fact after an agent finds and checks the relevant material. It may instead remain unresolved if a search returns only indirect evidence. A fact to derive may produce a result that is useful only together with the assumptions and inputs used to calculate it. An educated guess may guide the next search, be contradicted by an observation, or remain a last-resort possibility at termination. Each transition changes what the team is entitled to rely on.
That lifecycle gives the Orchestrator a way to preserve the difference between discovery and confirmation. Suppose the user’s request implies that a document contains a particular table. The ledger can record the expectation as part of the initial task, mark the table’s presence as something to look up, and later record either a checked observation or an unresolved gap. If an agent reports that the document “seems to contain” the table, the report may be useful for deciding where to inspect next, but it should not silently move the claim into the verified category. The system’s next action depends on whether the task needs a confirmed table or only a plausible lead.
This is also why the ledger is connected to control rather than being a passive notebook. A missing fact creates a reason to retrieve. A derived fact creates a reason to compute and possibly verify the computation. A contradiction creates a reason to revisit the plan or seek a better observation. A qualified guess may justify a bounded fallback but should not justify an irreversible action. The ledger does not solve these decisions by itself; it gives the Orchestrator a common state model in which the decisions can be made consistently.
The diagram shows classification feeding a plan, not a rigid sequence in which every task must visit every category. A small request may contain no meaningful educated guess or derivation. A larger request may return repeatedly to the ledger as new observations change what is known. The important transition is from an initial goal to an explicit, revisable representation of the work.
A plan that expects to be changed
Only after the ledger has been populated does the Orchestrator consider the makeup of the team and form a step-by-step plan. The plan is written in natural language and includes assignments to individual agents. In the paper’s description, it acts more like a guide or rubric for execution than a script that must be followed line by line. That choice reflects the environment. A script assumes that the relevant conditions are known in advance; an open-ended task reveals conditions as agents act.
The order matters. A plan made before the system has separated known facts from missing evidence can assign work for the wrong reason. It may send a browser agent to search for information that is already in an attachment, or ask a programmer to calculate a value before the required inputs have been established. By consulting the current task ledger together with descriptions of the team members, the Orchestrator can match a step to a capability and make the assignment intelligible. The plan is still expressed in ordinary language, but it is grounded in a current account of both the problem and the available ways to act.
The distinction is easiest to see in a multi-step research task. Suppose the plan begins with finding papers, opening them, extracting evidence, and creating a presentation. A search result may reveal that a paper is outside the intended scope. A downloaded document may not contain the expected text. A summary may expose a disagreement that changes how the papers should be grouped. If the plan were treated as an immutable procedure, the system would continue performing steps that no longer serve the goal. As a guide, the plan can preserve the destination while changing the route.
This flexibility does not mean that the Orchestrator abandons structure. The plan still gives workers a common direction and makes the next assignment intelligible. It also gives the system a basis for judging whether an observation is useful. A page that contains the requested data advances the plan; a page that merely looks related may not. A program that runs without errors may still fail to produce the required comparison. Planning and observation therefore constrain one another: the plan says what evidence would matter, and the evidence determines whether the plan remains credible.
The task ledger also supports a separation between strategic state and local context. A specialized agent may need a detailed view of a file or page to perform its current action. The Orchestrator needs a more durable account of the overall objective, the facts established so far, and the remaining work. When a new outer-loop plan is formed, the paper says that agents clear their contexts and reset their states. This helps prevent an obsolete route from continuing to influence the next cycle, especially after the system has learned that the previous approach was not working.
Resetting has a cost. Local context may contain useful details that do not appear in the newly revised plan, so a reset can discard work that would have been valuable. The report supports the lifecycle of plan updates but does not establish that every reset is beneficial. The design is a trade-off between stale context and lost context. A revised plan is more likely to be followed cleanly when agents are not anchored to the failed route, but it must also carry forward the observations needed to avoid repeating the same mistake.
Educated guesses create a similar trade-off. They can keep a run from ending with no answer when external information is incomplete, and they can help the Orchestrator articulate a plausible direction while the team searches. But the very usefulness of a guess creates pressure to treat it as fact. Magentic-One’s approach is safer when the qualification remains visible and the guess is used as a fallback rather than as a substitute for verification. The ledger provides a location for that distinction; it cannot enforce the distinction if the control process ignores it.
The result is a working model with three properties. It is structured, because different kinds of knowledge are kept apart. It is actionable, because missing facts and derivations point toward different kinds of work. And it is revisable, because new observations can alter the plan without erasing the task’s purpose. Those properties explain why a task ledger is more useful than a static checklist. A checklist records whether an item was touched. The ledger records what the system believes, how that belief could be tested, and what strategy currently connects the evidence to the desired result.
But a working model still leaves a local question unanswered. Once the Orchestrator has a plan and assigns a subtask, the team begins producing messages and actions. Some of that activity will be useful; some will be repetitive, misdirected, or prematurely treated as success. The task ledger tells the system what the work means at the strategic level. The next control problem is to decide, turn by turn, whether the current work is actually moving forward and who should act next.