One model, several jobs
A manager handing work to specialists is the ordinary shape of a multi-agent system, and most of the reason people build one is to run the parts at the same time. That reason is unavailable here, and it is worth stating first because everything else follows from it.
This kernel holds one engine and one holder for it. Two mutable borrows of the engine at once is undefined behaviour, and a decode slipped between two of somebody else's calls corrupts the cache, the position and the last token, which produces confident nonsense rather than an error. So the workers run one after another. What a workflow buys here is specialisation and a record of who did what.
The other usual motive is already refuted in this tree. Three independent evaluators voting for a better answer was measured at 76.9% against 77.8% for the strongest one alone. What earns its place is their disagreement: where all three agree the answer is right 90.3% of the time, and where they split, 50%. A router that knows when it is guessing is worth more than a point of accuracy.
Why memory is a filesystem
A manager and its workers need somewhere to put what has been decided and what came back. The obvious place is a conversation, and it is the one place this machine cannot afford. Parking a 512-slot cache writes thousands of blocks to the store, so swapping a context per worker costs more than the work does.
So the memory is a graph in the namespace, and a context switch becomes a read. That is not a compromise: the namespace is already a content-addressed tree of nodes, which is exactly the thing that would otherwise have to be built. It comes with deduplication, copying in constant time, comparison of whole subtrees in one step, and versioning of the entire graph as a single hash.
That last property is the one that matters. A run's root hash is a complete statement of what the run produced. Two runs of one workflow can be compared exactly, for nothing, by one comparison.
What a run is
A plan, the steps that have completed, and whatever is being built. The plan is a file, re-read at every step, so the schedule is a function of what is written rather than of anything held in memory. Two readers of the same plan pick the same next step.
The plan uses parent pointers rather than indentation, because indentation stops being unambiguous the moment a goal contains a newline, and a goal is text a model wrote.
The manager, and the only number that matters
An episode re-encodes its whole history at every step, so a run of N steps spends time proportional to N squared. The manager encodes the prompt once, leaves the engine in place, and decodes N actions from there. It then writes each decision into the plan.
The consequence is the result. Measured on a four-step goal with a 0.6B model, planning cost four decodes and running the plan cost none at all. A worker holding a decision somebody already made is a dispatcher.
A written action is checked against the trust level again at the moment it runs. A plan is a file, and a file can be edited by anything that can write, so admission is decided where the work happens.
What two runs must agree about
The first version of this required two runs of one plan to produce the same graph, and the experiment said no. A run writes its own steps inside the directory a worker then lists, so the second run legitimately saw something the first had changed.
The decision was identical both times. The observation could not be. So a step records the two separately: what the worker chose, which two runs must agree about, and what the world answered, which is allowed to differ. A comparison reports them apart, because decisions differing is a defect and observations differing is the world having moved.
Roles, and the measurement that said no
A specialist here costs 23.7 KB, since a worker is the base model wearing a sparse adapter that can be attached and detached while it runs. The obvious next step is to train one per role from the transcripts the earlier work produced, and to put each through the same four judges the self-improvement loop uses.
That was built and measured, and the answer is that it does not work. Across 24 workflows the base model answered 100% of the held-out decisions correctly before any training, and the paired test found no disagreement in either direction.
The reason is structural rather than a shortage of data. A transcript records what the model chose, and it chose by taking the highest-scoring option. So the label is the answer the model already gives, and training on it asks the adapter to reproduce whatever produced it. Keeping only the steps that succeeded does not escape that, because succeeding means the tool ran and says nothing about whether it was the right tool.
On that evidence a role is a naming convention, and the page says so rather than reporting a number that would look better. A role adapter needs a label from somewhere else: a person naming the right tool, a judged outcome, or a larger model as the teacher. A transcript is none of those.
Running while nobody is watching
A workflow may advance overnight, and doing so takes two separate things.
The plan declares that it wants to. That alone grants nothing, and it cannot: a plan is a file, so a workflow that declared its own autonomy would be the thing being gated writing its own permission. The operator grants it by typing back part of the plan's address, which is the same idiom used for approving an application or a staged update. The command is not in the model's vocabulary at all, so no amount of decoding reaches it.
The grant names the plan's contents, so editing a plan revokes it. It names the plan without its progress, and that detail is the whole feature: hashing the file as written would mean the first step revoked the grant that let it take that step, which is a gate that works exactly once while looking like it is holding.
Unattended work runs read-only, and the enforcement is the grammar rather than a check afterwards. At that level a mutating tool has no spelling.
What this does not do
It does not make the plans good. A 0.6B model asked to decompose a goal will copy the argument out of the worked example it was shown, and will once answer the stop word where an argument belongs. Those are real and are not plumbing, and tuning the prompt further against the same two checkpoints would only make the number better on the set it was tuned on.
It does not run anything in parallel, and no amount of work on this part would change that. The engine has one holder.
And it does not decide anything about correctness. The graph records what happened and makes it comparable. Whether the workflow was worth running is a separate question, and this machinery is deliberately silent about it.