choosing-graph

Overview

Two choices, made before the first turn of real work and stated out loud: the coordination graph — how the agents on this task are wired — and the reality anchor — the contact with reality that proves the result. Both are coordination, so a main agent fixes both when it dispatches and the anchor travels with the brief. A dispatched worker states its own graph for its own task and works inside the anchor it was handed.

Naming the anchor is not naming the tests. The anchor fixes the category and its checkpoint; inside it the worker and the user choose the method — which seam, which cases, which tool. That split is docs/roles.md's, and it keeps the brief clear of the worker's own work definition.

Both are stated, not asked. The human anchor carries the one user question described below.

Coordination graphs

Which graph applies follows from how the work actually runs.

• single-loop — one agent carries uncomplicated work whose length is visible end to end. A coordinator driving one dispatch's lifecycle, or a worker using one coworker as a check, remains a single loop.
• sub-agent fan-out/fan-in — a main agent or dispatched worker sends clear, converged branches to subagents and integrates their results.
• orchestrator-worker — the coordinator runs multiple app-rooted workers through status events. A dependency graph and a capped batch use this shape. It is the only graph that writes ~/.straw-boss/plans/<slug>/plan.json; the other two carry no dispatch plan.

orchestrator-worker is settled ahead of the other two: more than one app-rooted worker under one coordination loop keeps that shape whatever else runs beside it.

single-loop and sub-agent fan-out/fan-in create no plan.json and no repo-internal Straw Boss planning or spec document. An app-rooted dispatch still writes its own ~/.straw-boss/dispatch/<app>--<slug>.json instruction and .contract.md; these are the dispatch's lifecycle record, archived once the dispatch wraps up.