2026-10-15
In a company, sales has explained which objection kills a deal. Marketing has corrected an outdated claim. Operations has told an agent which numbers can be trusted. Most of those corrections stay in private chats, personal settings, and separate tools. The next person cannot use them.
An agent at execution time is a different failure. It calls a tool, gets real feedback, and an unverified assumption stays in the dialogue. Later reasoning keeps following it. Gaoling School of Artificial Intelligence at Renmin University calls this task-state contamination: unverified assumptions, outdated plans, and wrong progress judgments remain in the interaction history and steer later action. The paper is Agent-Editing World Model.
The two look alike. One is something learned that never entered a shared place. It was not recorded. The other is a judgment that should not have stayed in the history. It was not removed. They are not one disease. They also do not weld into an automatic loop.
A company brain is not a knowledge base, and it is not a stack of directories. Directories are only where things sit. What has to remain is the loop. Work happens. Someone corrects it. The correction is routed. Someone reviews it. It is written into a shared place. The next piece of work can use it.
Review needs three roles. The process owner watches whether this process is still running. The domain reviewer checks whether the correction is right for the business, and owns the ledger for this task. The final decider settles it when two sources conflict. In a small team, the process owner and the domain reviewer can be the same person. The decider cannot be the author of this correction. Who may change it, and who deletes it when it goes stale, is named the same day. If a role is empty, the weekly maintenance does not happen. The directories get built, then no one maintains them, and no step of the work has to read them.
What it answers is a standing rule, not whether this one step should be taken.
What the company believes now. Which decisions replaced older ones. Who has the final say. How this kind of work should be done.
Four things are enough. Memory: the facts, decisions, and history that matter now. Rules: what counts as good work, and what must not be done. Capability: skills and workers that can be run again. Learning: reviewed corrections, used to change the first three.
Do not call the rules a judgment yet. The execution layer has another kind of call: whether this single step moves the task forward. Use one word for both, and the three layers collapse into one.
The smallest set of files can be these: company-brief.md, priorities.md, decisions/, people/, projects/, policies/, skills/, workers/, learnings.md. Before an agent starts, it reads a company map. What we do. What matters most now. Which source wins. Where to look up decisions, policies, skills, and workers.
This layer can be done today. It does not wait for AEWM.
AEWM turns the question. It does not predict what the tool will return. It looks at what this step does to progress on the task.
It has two abilities. Action Judge sorts the step into three kinds: critical progress, useful exploration, and useless repetition. The paper's words are Critical, Exploratory, and Noisy. State Revision: if the step is useless repetition, rewrite the reasoning and the next action from the same history that has already happened.
EditAct puts that into execution. The agent proposes a step. AEWM calls it. Keep it or rewrite it. Then actually run it, and write the result into the history. The rewrite has to enter the next step. A note that says "think again" does not count.
One terminal case in the paper: the agent checked an IPv4 port, did not find the target, and treated the service as not listening. AEWM noticed the code bound IPv6, changed the next step to check IPv6, and the port was listening. The task later passed its tests.
Read the numbers in the paper's terms. On their Action Judge benchmark, macro-F1 is 70.5%, 10.6 points above the strongest comparison. That number is how often a prediction made before execution agrees with a label written after the whole trajectory was seen. It is not "70% of enterprise tasks succeed."
Task success is a different number. On Terminal-Bench 2.0, Qwen3.5-35B-A3B with the previous method scores 37.1%. With EditAct it scores 48.3%. That is one model and one terminal benchmark. AEWM-RFT also shows that revised trajectories can be written into the agent's own ability. After that, AEWM is not called. The agent still beats one trained only on its own successful trajectories, by 2.2, 2.6, and 2.5 points.
These are results inside the paper's setup. An enterprise workflow cannot copy them.
Glue the company brain and AEWM into an automatic loop, and this layer is what you skip.
The organization layer is the company brain. It holds relatively stable facts, decisions, policies, skills, and workers. It answers what the company believes now.
The task layer is a ledger. One sheet per task. Six lines at minimum:
Task ledger
Verified facts: (source; who confirmed)
Unverified assumptions:
Excluded branches:
Unmet requirements:
Current progress:
Next question to check:
A verified fact names its source, and who confirmed it. Anything unconfirmed stays under unverified assumptions. Moving a line from assumption to verified takes a nod from the domain reviewer. A ledger with no owner is still a private chat for this task.
Without the ledger, a stale rule in the company brain flows into this task. AEWM also judges the step from an incomplete history. If someone maintains the ledger, many questions of "does this step help" can be read off the sheet first. A model is not required first.
The execution layer is not the model layer. Start with rules, checklists, and prompts. Is this step critical progress, useful exploration, or useless repetition. If it is useless repetition, what reasoning and action replace it. The replacement has to be executed for real. Collect trajectories and measures, then talk about a model.
After execution, route through the company brain's loop. A missing fact goes to company knowledge. A new strategic choice goes to the decision record. A repeated preference goes to policy. A trick that worked goes to skills. A sequence that can be run again goes to workers. These are reviewed before they are written back. They are not written into the company brain automatically.
A gate and a review are not the same thing. The gate covers irreversible actions, and it blocks them before execution. Review covers what may be written back into shared knowledge, and that can wait. If a dangerous action only sits in the weekly review queue, the gate is just another folder.
Stage one is the smallest company brain. Pick one process that keeps coming back. Build the smallest directory. Give the agent a company map. Name the three roles. People may overlap. The decider cannot be the author of this correction. Run the correction route and the weekly maintenance. If a role is empty, stop here. Do not go on.
Stage two adds the task ledger and a checklist. Use the six lines above. A verified fact with no source and no confirmer still counts as an unverified assumption. Review by hand with "critical progress / useful exploration / useless repetition." Try it on real tasks.
Stage three triggers a rewrite on useless repetition. Collect trajectories that real feedback has checked. See whether rework and useless loops go down. See whether useful exploration was killed by mistake.
Stage four is when a model can be considered. Enough trajectories of clear quality. Stable review. Explicit measures. Then consider training of the AEWM kind, or fine-tuning on revised trajectories. Do not start with an automatic loop.
When sources conflict, the final decider settles it. The author of this correction cannot also be the decider for it. Someone deletes knowledge when it goes stale. When it is wrong, it is clear whose it is.
If AEWM is actually called on every step, the call and the rewrite add delay and cost. A wrong call can kill useful exploration. Maintaining the company brain is ongoing human work.
Look at these, not at whether the directories exist. Rework rate. How often stale information is treated as a current fact. Time spent on review. Task success rate. Whether useless repetition went down. Whether useful exploration stayed.
A person who has tuned an agent well holds a private advantage. Asking them to hand the correction over requires recognition. Otherwise the company brain gets no input.
The company brain lets a rule that still holds be used by the next person. The execution layer looks at the step before it runs: progress, exploration, or repetition of an assumption that no longer holds. The execution layer starts as a checklist, not a model.
Between them is a six-line task ledger. What is verified has a source and a confirmer. Writing back to shared knowledge goes through review, and the decider is not the author of that correction. Irreversible actions are blocked by the gate before they run.
The company brain can be done today. Treat AEWM first as a checklist and a design principle, not as a model you plug in. When the trajectories, the review, and the measures are in place, then talk about a model.
A correction has to be reviewed, written down, and usable next time before later steps get better. If the decider is the author of the correction, one lesson still stays in that one conversation.