Tutorial 10B: Run parallel work and two independent reviews

Tutorial 10A established one coordinator and one worker. Now you will use the same small protocol for parallel work and an independent two-reviewer gate.

The goal is not to maximize agent count. Parallelism is useful only when work units are genuinely independent and their results can be reconciled against clear evidence.

What you will accomplish

You will ask one owner to publish two independent analysis tasks, wait for both to close, publish one two-run review task, and disposition every review result. The intended reviewers use different harnesses without hard-coding particular session IDs.

1. Start with two independent work units

For the public Palmer Penguins data, split work by question rather than by arbitrary file range:

• one task counts rows by island;
• one task counts rows by species.

Neither result depends on the other, so separate workers can claim them concurrently. A later summary task can depend on both closed tasks.

Give the coordinator this prompt:

Parallel claims may begin on adjacent scheduler wakes. Kanban guarantees atomic capacity, not simultaneous model starts.

2. Verify evidence before closing prerequisites

Each worker checkpoints its data source and calculation, then submits. The owner checks that:

• island counts sum to 344;
• species counts sum to 344;
• the data source is the local public dataset; and
• no file, credential, or live Fleet configuration changed.

Only after that review does the owner explicitly close both tasks. The dependency gate then makes the summary task claimable.

3. Publish one review task with two run slots

Independent review belongs in one task with two runs, not two separately targeted tasks. The owner publishes the task with total_run_limit = 2 and a free-form harness:distinct capability. Each prospective reviewer must read the review task's existing runs, look up the claiming agents, and claim only if its own registered harness differs from every prior reviewer. The intended final set is two mutually harness-distinct reviewers.

Also add a cooperative reviewer:is-not-owner check so the coordinator does not review its own work. These checks improve independence inside a trusted board; they are not an authentication or anti-collusion boundary.

Ask the coordinator:

The capability is intentionally descriptive. There is no fixed roster of Claude Code, Codex, or OpenCode session IDs, and the server does not interpret the key as a reserved policy name. Each worker performs the stated check against live board records before claiming.

4. Keep reviews actionable

Each reviewer returns a verdict plus dispositionable items. A useful item states:

• the exact evidence or missing evidence;
• the affected result or tutorial claim;
• the operational impact;
• the smallest correction; and
• the focused acceptance check.

The owner deduplicates by root cause, then records one disposition for every finding, non-blocking note, and stated gap:

• Fix now and rerun the relevant check.
• Track explicitly as a bounded future item when it is valid but outside the current task.
• Accept a documented tradeoff with evidence.
• Reject a duplicate, unsupported hypothesis, or out-of-scope proposal with a concrete reason.

If a proposed fix would change observable Kanban semantics—capacity, ownership, events, run or task states, leases, or authority—the owner marks it blocked on explicit operator approval. Review agreement alone is not authorization for a protocol change.

5. Close in dependency order

The owner completes the sequence in this order:

1. verify and close both parallel analysis tasks;
2. allow the dependent summary run to execute and submit;
3. verify and close the summary task;
4. wait for both review runs to submit;
5. disposition every review item and run any focused recheck; and
6. close the review task.

This produces a complete, queryable chain without reopening terminal runs or relying on an informal human relay between agents.

6. Takeaways

• Split only genuinely independent work; use dependencies for real prerequisites.
• Atomic capacity prevents duplicate claims but does not promise simultaneous starts.
• One multi-run review task is the canonical two-reviewer pattern.
• harness:distinct is a live cooperative check, not a hard-coded roster or server policy.
• Reviewers submit evidence; the owner disposes every candidate and closes the task.
• A protocol-changing recommendation stops for explicit operator approval.
• Continue to Tutorial 10C: See, recover, and clean up a Fleet.