orchestratinglisted

# Orchestrating One decision, made once, at task arrival: what structure does this work deserve? Answer it deliberately instead of drifting into one inline context. ## First decision: structure at all? Inline, solo work is the default. Structure costs briefing, integration, and review, so it must pay for itself. Split or delegate only when at least one of these holds: - Independent subtasks exist that do not reshape each other. - Bulk reads or long execution would drown the context that has to decide later. Protect the orchestrator's context; spend subagent context. - A different model or runtime is demonstrably better at a subtask. - Stakes times uncertainty justify multiple attempts or independent checks. Keep inline anything you cannot yet decompose, any critical path where each step reshapes the next, and anything small enough that coordination costs more. ## Route by task shape | Task shape | Structure | |---|---| | One clear path, routine stakes | Inline. No structure. | | Long-horizon work with unknown ownership, unresolved decisions, or unclear sequencing that prevents an honest spec or plan | mega-orchestration:wayfinding: map uncertainty and resolve the next decision before design or planning. | | 2+ independent tasks, no shared state | Parallel fan-out (below): one focused agent per task, dispatched together. | | Deterministic mechanical changes sharing one oracle | Bulk mechanical mode: one owner, one bounded batch, one focused verification set. | | A wri