Coordinate by contract. Parallelize only when safe.
Define ownership, handoff artifacts, and evidence before splitting work. Use optional helpers when the harness supports them—or execute the same workstream sequentially without changing the contract.
Sequential stages with explicit artifacts — each stage completes before the next begins. Illustrative topology; helper availability depends on the client.
Selected formation: PIPELINE. Step 1 of 5. Active roles: research.- research01
Owned scope · read-only
- implement02
Owned scope · owned source
- validate03
Owned scope · project checks
- review04
Owned scope · read-only diff
- deliver05
Owned scope · evidence handoff
nodes light as active · dashed boundary = file ownership scope · packet = handoff
Portable coordination
Workstreams describe role boundaries, file ownership, and handoffs. Use client-native helper spawning only when it is available and safe; otherwise execute the same workstream plan sequentially in one session. The method stays portable because the contract lives in repository-visible ownership, handoff, and evidence artifacts—not in a client-specific spawning feature.
Parallelism without ownership multiplies ambiguity
More agents do not automatically produce better work. Without declared scopes, two workers can edit the same control point, repeat the same research, or hand back outputs that cannot be reconciled. The durable unit is the workstream contract: objective, owned paths, dependencies, output artifact, and proof.
This page covers the mechanics. For the case behind adopting TRW for a team — read TRW for Teams.
File ownership is a contract, not a wish
Declare one writer for each path before work begins. A capable harness may surface or reject overlap, but the portable guarantee is procedural: detect shared files in the plan, serialize those edits, and review the combined diff. Independent scopes may run together; shared control points belong in sequential waves.
src/module.*scope — writable
tests/test_module.*scope — writable
SCOPE DECLARATION
one owner per path
OVERLAP DETECTION
before work begins
CONFLICT RESOLUTION
serialize shared files
Four coordination formations
These are planning patterns, not a promise that every client can spawn helpers. Use the same topology as sequential passes when delegation is unavailable; ownership and evidence obligations stay unchanged.
Small or tightly coupled work.
Use one owner, one diff, and project-native validation. Start here; add coordination only when the evidence shows the task genuinely decomposes.
Sequential stages with clean handoffs.
Use when each stage depends on the previous output and cannot start until its predecessor is complete. This works equally well as sequential passes in one session.
Parallelizable research → single merge.
Use when the same read-only task splits into independent axes and one owner can reconcile the outputs. Parallel execution is optional; independent evidence is the requirement.
Quality-critical decisions via adversarial evaluation.
Use when a consequential decision benefits from competing proposals, adversarial critique, and an explicit judge. More opinions do not guarantee correctness; resolve critical dissent with evidence.
Wave/shard execution
Waves express dependency order. Workstreams inside a wave may run concurrently only when their owned paths and outputs are independent. A manifest is an optional planning artifact—not mandatory tool overhead—and a sequential client can execute the same rows one at a time.
Common questions
Do I need to run agents in parallel to use TRW?
How does file ownership work if I need the same file edited twice?
Is agent spawning experimental?
Make every handoff explicit. Keep one owner per file.
Start sequentially. Add helpers only where scopes are independent and the current harness can coordinate them safely.