Between the Company Brain and the Execution Layer, a Task Ledger Is Missing

Sales explained to the team which objection would directly kill a deal, marketing corrected a tagline that had already gone stale, and operations told the AI agent which numbers could be trusted. Most of these corrections stayed in private chats, personal settings, and separate tools—the next person can't use them at all.

At the execution stage, the agent faces a different kind of failure. It calls tools and gets real feedback, but an unverified assumption remains in the conversation history, and subsequent reasoning continues along with it. Gaoling School of Artificial Intelligence at Renmin University of China calls this phenomenon task state contamination—unverified assumptions, outdated plans, and incorrect progress judgments linger in the interaction history, continuously affecting subsequent actions. The related paper is Agent-Editing World Model.

The two look similar on the surface, but they are not the same disease. The former is that what was learned never entered a shared space—it was never recorded; the latter is that a judgment that should not have remained in the history was not removed. They do not automatically weld into a closed loop.

Company Brain: A Judgment That Still Holds Must Be Usable by the Next Person

The company brain is not a knowledge base, nor a bunch of directories. A directory is just where things are placed; what really needs to remain is that loop—work happens, someone corrects it, the correction is routed, someone reviews it, it is written to a shared location, and the next piece of work can use it directly.

Review requires three roles. The process owner watches whether the process is still running; the domain reviewer judges whether this correction is correct for the business and owns the ledger for that task; the final arbiter makes the call when two sources conflict. In a small team, the process owner and domain reviewer can be the same person, but the arbiter cannot be the author of this correction. Who can change it and who deletes it when the knowledge goes stale must be decided on the same day. If a role is vacant, weekly maintenance will not happen—the directory gets built, no one maintains it, and no step in the workflow requires reading it.

The company brain answers long-term rules, not whether a particular step should be taken: what the company currently believes, which decisions replaced old decisions, who has final say, and how this kind of work should be done.

In terms of content, four things are enough: memory (currently important facts, decisions, and history), rules (what counts as good work and what must never be done), capabilities (skills and workers that can be run again), and learning (reviewed corrections used to change the first three).

Do not directly call rules judgments. The execution layer faces a different kind of call: whether this single step moves the task forward. When two layers share one word, the three layers collapse into one.

The minimum file set can be: company-brief.md, priorities.md, decisions/, people/, projects/, policies/, skills/, workers/, learnings.md. Before the agent starts, it first reads a company map: what we do, what matters most right now, which source takes priority, and where to look up decisions, policies, skills, and workers. This layer can be implemented today; there is no need to wait for AEWM.

AEWM: Borrow Its Judgment Approach, Not Its Model

AEWM flips the problem around. It does not predict what the tool will return; instead, it looks at what this step does for task progress.

• Action Judge divides each step into three categories: critical progress, valid exploration, and invalid repetition (Critical, Exploratory, and Noisy in the paper).
• State Revision rewrites the reasoning and next action based on what has already happened when a step is judged as invalid repetition.

EditAct puts all of this into execution: the agent proposes a step, AEWM calls it, chooses to keep or rewrite it, then actually runs it and writes the result into history. A rewrite counts only if it enters the next step—just writing "think again" does not count.

The paper has a terminal case: the agent checked the IPv4 port, did not find the target, and concluded that the service was not listening. AEWM noticed that the code was bound to IPv6, changed the next step to check IPv6, and the port was indeed listening; the task later passed the test.

Pay attention to the measurement definitions when reading the numbers in the paper. On the Action Judge benchmark, macro-F1 is 70.5%, 10.6 percentage points higher than the strongest comparison method. This number measures the agreement rate between "predictions made before execution" and "labels written after seeing the entire trajectory," and does not equal "70% of enterprise tasks will succeed."

Task success rate is another number. On Terminal-Bench 2.0, Qwen3.5-35B-A3B scored 37.1% with the previous method and 48.3% with EditAct. This is one model and one terminal benchmark. AEWM-RFT also shows that corrected trajectories can be written into the agent's own capabilities—afterward, without calling AEWM, the agent still exceeds the version trained only on its own successful trajectories by 2.2, 2.6, and 2.5 percentage points. These conclusions are all limited to the experimental setup in the paper, and enterprise workflows cannot be directly replicated.

Action Judge is the discriminative component in AEWM, functioning like a pre-execution "security screener": before the agent actually calls a tool, it first examines what this step means for task progress. Its output is not "what the tool will return," but which of the three categories this step belongs to—critical progress (Critical, directly pushing the task toward the goal), valid exploration (Exploratory, which does not directly advance it but can eliminate branches and obtain necessary information), or invalid repetition (Noisy, repeating an action already taken or following an assumption that has already failed). The reason it is placed before execution rather than after is that once the action actually happens, the cost (time, API calls, irreversible operations) has already been paid. Action Judge's judgment needs to incorporate task history, so it is a sequence discrimination problem, not single-step classification. The macro-F1 used to evaluate it averages the F1 scores computed separately for the three label classes, which avoids the majority class dominating the metric when classes are imbalanced.

State Revision handles the situation after Action Judge determines "invalid repetition." It does not make local patches; instead, based on the history that has actually occurred, it rewrites the agent's reasoning chain and next action. The key constraint here is "based on history that has occurred": the rewrite cannot fabricate a state that was never observed out of thin air; it can only reorganize reasoning on the basis of existing facts and remove that unverified assumption that continues to take effect. Another constraint is that the rewrite must actually be executed and written into history to count—if it merely generates "think again" without replacing it with a runnable action, the contamination remains in the trajectory. This is exactly the difference between State Revision and ordinary self-reflection prompts: reflection stays at the text level, while state revision requires producing a replacement action that will actually be invoked and receive real feedback.

The Missing Link: The Task Ledger

If the company brain and AEWM are directly glued into an automated closed loop, what gets skipped is precisely this layer.

The organizational layer is the company brain, holding relatively stable facts, decisions, policies, skills, and workers, and answering what the company currently believes. The task layer is the ledger, one table per task, with at least six rows:

Task Ledger
Verified facts: (source; confirmed by)
Unverified assumptions:
Excluded branches:
Unmet requirements:
Current progress:
Next question to check:

Verified facts must state the source and confirmer. Anything unconfirmed stays in unverified assumptions. Moving a row from assumption to verified requires the domain reviewer's nod. A ledger without an owner is still just a private chat for this task.

Without a ledger, an outdated rule in the company brain flows directly into the current task, and AEWM can only judge this step based on incomplete history. If someone maintains the ledger, many questions about whether a step is helpful can be read from the table first, without necessarily needing the model first.

The execution layer is not the model layer. Start with rules, checklists, and prompts: is this step critical progress, valid exploration, or invalid repetition? If it is invalid repetition, what reasoning and action replace it? The replacement must actually be executed. Once trajectories and metrics accumulate, then talk about models.

After execution, it must flow back into the company brain loop: missing facts go into company knowledge, new strategic choices go into decision records, recurring preferences go into policy, techniques that work go into skills, and sequences that can be run again go into workers. These must be reviewed before being written back, not automatically written into the company brain.

Gates and review are not the same thing. Gates target irreversible actions and intercept before execution; review targets content that can be written back to shared knowledge and can wait. If a dangerous action is simply sitting in the weekly review queue, then the gate is just another folder.

Task state contamination and context length limits are different problems. When the context window is insufficient, information is truncated or forgotten, manifesting as "cannot remember"; task state contamination is when information is still there, even repeatedly referenced, but it is itself wrong or outdated. Once an unverified assumption enters the interaction history, it is treated as established fact in every subsequent reasoning step, and the more "faithful to context" the model is, the deeper the contamination propagates. This also explains why simply increasing the context window cannot solve the problem—the larger the window, the longer the contamination persists. The way to govern it is to explicitly mark which content is an assumption and which has been confirmed, and to proactively remove assumptions from valid state when they are falsified or have long remained unconfirmed, rather than relying on the model to decide which one to trust.

Start Small: Checklist First, Model Later

Phase 1 build the smallest company brain. Pick a recurring process, build a minimal directory, give the agent a company map, and designate three roles. People can overlap, but the arbiter cannot be the author of this correction. Get correction routing and weekly maintenance working. If a role is vacant, stop here and do not go further.

Phase 2 add the task ledger and checklist. Use the six rows above. A verified fact without a source and confirmer still counts as an unverified assumption. Humans review based on "critical progress / valid exploration / invalid repetition," and try it on real tasks.

Phase 3 trigger rewrites on invalid repetition. Collect trajectories verified by real feedback, and observe whether rework and invalid loops decrease, and whether valid exploration is mistakenly killed.

Phase 4 is where models finally come in. Only when trajectory volume is sufficient, quality is clear, review is stable, and metrics are clear should you consider AEWM-style training or fine-tuning on corrected trajectories. Do not build an automated closed loop right away.

Behind the four-phase path is one criterion: first establish a process that can produce high-quality trajectories, then consider using trajectories to train models. The reason is that the gains at the model layer depend on data quality, and trajectory quality depends on whether the review mechanism is stable. If the ledger has no owner, the arbiter can be the correction author themselves, and writing back to shared knowledge does not go through review, then the collected trajectories are mixed with uncorrected false assumptions, and using them for fine-tuning will only solidify the contamination into the model weights. Therefore the order cannot be reversed: Phases 1, 2, and 3 produce not only business improvements, but also clean trajectories with real feedback labels. Only when the number of trajectories is sufficient, review standards are consistent, and evaluation metrics are clear does Phase 4's AEWM-style training or fine-tuning have a reliable foundation.

The Remaining Accounts Must Be Settled

When sources conflict, the final arbiter makes the call, and the author of this correction cannot simultaneously serve as arbiter; when knowledge goes stale, someone must be responsible for deleting it; when something goes wrong, it must be possible to see whose responsibility it is.

If every step really calls AEWM, invocation and rewriting will bring latency and cost; an incorrect call may kill valid exploration; maintaining the company brain is ongoing human effort.

What really matters is not whether the directory exists, but the rework rate, the frequency with which outdated information is treated as current fact, review time, task success rate, whether invalid repetition decreases, and whether valid exploration remains.

A person who tunes an agent very well holds a private advantage. Asking them to hand over their corrections requires corresponding recognition; otherwise the company brain gets no input at all.

The company brain lets a rule that still holds be usable by the next person; the execution layer, before acting, first checks whether this step is progress, exploration, or repetition of an assumption that no longer holds. The execution layer starts from a checklist, not from a model.

Between the two is a six-row task ledger: verified content has a source and confirmer; writing back to shared knowledge goes through review, and the arbiter is not the author of this correction; irreversible actions are intercepted by gates before execution.

The company brain can be done today. Treat AEWM first as a checklist and design principle, not as a model you plug in and use. When trajectories, review, and metrics are all in place, then talk about models. A correction must be reviewed, written down, and available next time before subsequent steps truly improve. If the arbiter is the author of the correction, this lesson remains only in that one conversation forever.