Sequential And Parallel Delivery

Sequential delivery is the default because one owner preserves context. It is also the easier beginner-friendly HITL path: one thread, one artifact trail, one validation story.

Parallel delivery is earned when it reduces context pressure without creating ownership ambiguity. The parent run still owns synthesis, integration, and final judgment.

Parallel delivery is often discussed as a speed tool, especially during implementation. Parallel waves can be faster, but they are also costlier: more workers, more coordination, more integration work, and more chances for conflicting assumptions. That framing is still incomplete. A single subagent can be worth using when it protects the parent thread from carrying a large research trail, package-source inspection, validation investigation, or isolated patch attempt.

Use Sequential Delivery When

the same files or contracts are likely to be touched by multiple tasks
implementation choices in one area shape another area
the validation gate is shared across the full change
the work is small enough that parallel coordination would add overhead
the source of truth is still being reconciled

Sequential delivery reduces coordination risk. It is usually the right choice for docs refactors, schema changes, shared package contracts, and cross-cutting workflow edits.

It is also the safest default when the operator is still learning the harness. Manual HITL already provides useful control without adding parallel coordination on top.

Parallel Offload Types

Parallel work has two common shapes.

Readonly offload sends research, audit, source inspection, or validation investigation to a worker. Write offload sends an implementation slice to a worker only when ownership is narrow enough for the parent to integrate safely.

Use Parallel Waves When

tasks have disjoint write scopes
each task has a clear owner, source set, and validation gate
a parent plan defines merge order and conflict handling
readonly research can run ahead of writing
final integration has one owner who reconciles docs, metadata, and validation

Parallel waves are useful for large feature sets across unrelated apps, multi-surface audits, and independent docs sections with clear boundaries.

Required Plan Shape

create-plan owns the detailed task graph. At this level, parallel work should not start until the plan makes these boundaries explicit:

owned paths and forbidden paths
source set and validation per wave
dependency order
shared files that only the integrator may edit
final integration owner

Failure Modes

Two workers edit the same route metadata without coordination.
A child task updates implementation docs while another updates the canonical routed page from different assumptions.
Parallel branches pass local checks but fail together because a shared contract drifted.
The final integrator lacks enough context to resolve contradictory wording or validation evidence.

Done Signal

Sequential work closes after the single owner validates and reports. Parallel work closes only after each wave reports evidence, the integrator reconciles shared artifacts, route metadata is coherent, and final validation covers the combined state.