Fleet Series 03 — Workers: the Hands of the Fleet

Working notes for a planned episode — an outline, not an article. Details will shift when it gets scripted. Series index: Building the Fleet.

Deep dive on the task worker: the unit that picks up one leaf, does the work in isolation, and hands back a diff plus evidence.

The hook

The worker is deliberately boring — and that's the point. All the intelligence lives in the task shape and the gates around it; the worker just executes one well-specified leaf. Boring workers are what make parallelism, retries, and swapping models safe.

What the viewer walks away with

• What a worker actually does: claim a leaf, set up an isolated workspace, run the model, run the tests, report back
• The TaskStore port: where tasks live is abstracted — Forge (my Nous notebook), GitHub, and git-bug all satisfy the same protocol, so the same worker runs against any of them
• The sandbox seam: where code executes is abstracted too — local workspace or a gaol container behind one interface
• Concurrent workers: workspace fan-out with a serial reconcile barrier — N workers build in parallel, changes land one at a time (default concurrency 3)
• Hard-won gate lessons: thinking-token budgets, and making a local model actually read diffs (diff literacy)

Beats

• Anatomy of one leaf execution, end to end, ~2 minutes (Explainer plate 2 is this beat, animated)
• The two ports (TaskStore, sandbox) as the reason the fleet is portable — swap the forge, swap the runtime, worker unchanged
• Parallelism: three workers, three jj workspaces, one reconcile queue — why the barrier is serial on purpose
• The git-bug TaskStore: tasks that live inside the repo itself, no external tracker — bridges into episodes 06 and 07

Demo ideas

• Kick off 3 concurrent workers on independent leaves, watch the workspaces fan out and the reconcile barrier land them in sequence
• Same worker, two TaskStores: one leaf from Forge, one from git-bug in the target repo

Source material

• The concurrent-workers build (July 2026): workspace fan-out + serial reconcile barrier
• The git-bug TaskStore in the forge repo
• gaol: the Isolation Substrate — the sandbox-seam story continues there

Open questions

• How much jj (Jujutsu) explanation does the audience need before workspaces make sense? Might warrant a 90-second sidebar or a separate short

Borrowed framings — errors as loop fuel; context as budget

Two connector-design points from the loop-engineering crash course, worth a beat each:

• Descriptive errors are loop fuel: an unattended loop can act on "missing repo scope — request it" but wastes attempts on "Error 403". Applies to the TaskStore ports, gate outputs, and tool surfaces — worth auditing ours against. (Its sibling principle, idempotent writes, we already practice: stable task identifiers, idempotent emit, one branch per change — worth naming on screen.)
• "Treat context as budget, not bucket": long runs accumulate junk context and degrade (their "doom loop"). Workers-as-separate-processes is our structural answer — the messy subtask happens elsewhere, only the clean result returns. A good on-camera reason why the worker is a process, not a subroutine of one big session.