Parallel Agents

Running N workers at once is a Promise.all. The technique is ordinary and nothing about it earns a unit.

What earns the unit is that every hazard in a fan-out is a concurrency hazard, and none of them needs a model. Four stub workers writing files reproduce all of them, deterministically, in milliseconds. That is worth saying plainly because it is easy to assume the difficulty lives in the agents.

Three hazards

Shared path. Two workers write the same file. Last writer wins, every write succeeds, and nothing reports the loss.

Shared working directory. A worker resolves a path from the repository root rather than its own worktree, and reads a neighbour's state. Term 13 built the isolation this depends on.

Ordering. Results collected in completion order rather than task order. This is the quiet one: nothing errors, nothing is lost, every value is correct, and the association between task and result is simply gone.

The receipt

artifacts/19-parallel.json, with no model anywhere in the run:

isolated: 4/4 landed, intact true
  task order      a b c d
  returned order  a b c d   (preserved, not completion order)
  delays          40 10 30 0ms

pre-flight on a shared path -> a and b and c and d both write
  .../shared/result.json. Last writer wins and nothing reports the loss.

run anyway: 1 file(s) actually on disk for 4 workers, 3 output(s) lost: b, c, d
  every write succeeded, no error was raised, and the run reported four workers done

The delays are staggered so completion order genuinely differs from task order. Without that, the ordering guarantee is asserted against a run where the two happen to agree, and the test proves nothing.

Collision detection is a pre-flight check rather than a post-run one, and that is forced by the failure mode. After the fact there is a file that exists, with plausible contents, and no signal. There is nothing to detect.

The line that was almost wrong

The demo first reported 4 file(s) on disk for 4 workers. It was reading collect(), which reads one path per worker — and in the collision case that is the same path four times. The filesystem held one file. The line counted reads and called them files, which would have printed a reassuring number over the exact failure being demonstrated. It now counts distinct paths.

The same trap has a test: collect() returns four entries for four workers even when three of them lost their work, so the check compares content by worker id rather than counting files.

Break it first

mutation                                     tests                demo
collisions never refused                     2 failed | 7 passed  exit 1
losses counted by file rather than content   2 failed | 7 passed  exit 1
results returned in completion order         1 failed | 8 passed  exit 0

The third row is honest about a limit: the demo checks that isolated workers keep their output, and shuffling the return order does not lose any. The tests catch it because one of them asserts the returned order explicitly, and another asserts that the run really did finish out of order — without that second test, the first is checking a coincidence.

Where it overlaps

Line H is isolation and parallel safety, and this is the rung where it stops being theoretical. Term 13 supplies the worktrees, term 11 measured what fanning out costs, term 22 adds a planner and a merge step on top. Line C is delegation topology: this is delegation without a coordinator, which is the arrangement that fails quietly rather than loudly.