Fieldnotes / engineering
← Orchestration patterns

Watch & compare

Orchestration patterns

Different ways to see the same idea. Play one cut at a time, then return to the guide to try it yourself.

Why we recommend Join the checks

Choose Join the checks as the main entry: it makes incomplete and failed review joins, human-visible failure, and fresh evidence after a patch change concrete. Baseline clearly contrasts serial and parallel scheduling and gives reconciliation its own work interval, but it never shows failure or stale evidence. Split by dependency is the strongest complement: a field/handler mismatch exposes the cost of unsafe fan-out, and its corrected ending waits for the handler before running tests.

Original · 26 sec

Original explanation

Orchestration assigns work and coordinates results across steps or agents.

Read the video sequence
  1. 0–11.5s: Independent API and database reviews are scheduled serially. Reconciliation begins at 10.7s after both results arrive and completes at 11.5s.
  2. 12.8–18.95s: The same illustrative tasks reset and run in parallel from 14.3s. The first report leaves Reconcile at 1/2; the second arrives at 18.95s.
  3. 19.2–23.3s: Reconciliation runs and completes at 20s. Success holds until the fade starts at 22.5s; the remaining tail is blank. Timing illustrates scheduling, not measured speedup or review correctness.
About this cut

Production: Original prototype; model not recorded.

Recommended · Astra · 30 sec

Join the checks

Parallel checks can share a frozen patch, but only fresh, acceptable results may cross the join into a separate human approval step.

Read the video sequence
  1. 0–9.4s A frozen patch A goes to two independent model reviewers: API compatibility and database migration. Both report a pass. The coordinator waits until both reports arrive, then sends a bundle to a human approver, who reviews and approves it.
  2. 9.4–13.8s A different patch B clears the earlier results and starts both checks again. The API report arrives first. The join shows one of two; approval waits while the database check continues.
  3. 13.8–17.5s The database reviewer reports a failure. Its red report reaches the join, blocking the approval-ready handoff. A red failure notice then reaches the human approver, whose state changes to REPAIR. Failing evidence is visible without permitting approval.
  4. 17.5–24.3s An engineer supplies a repaired patch C; the repair itself is offscreen. Both old reports are cleared because the code snapshot changed. Both checks run again, and their fresh passing reports reach the join.
  5. 24.3–30s The fresh bundle reaches the human approver for review and a separate approval decision. The result holds before fading to the opening background. This is an illustrative workflow, not a guarantee that passing model reviews establish correctness.
About this cut

Production: gpt-6-astra.

Revision: gpt-6-astra comparative review.

Illustrative fixed workflow and timing; no measured speedup or quality guarantee.

PASS is a model review outcome, not proof of correctness; human evidence inspection remains necessary.

Failure blocks the approval-ready handoff, not engineers’ access to failing evidence; repair happens offscreen.

Read-only access and permission enforcement are configured outside the animation; persistent prompts cannot enforce permissions.

Audio was analysed but not physically listened to.

Original author self-review is preserved; subsequent comparative review and edits are credited separately.

Alternative · Fable · 30 sec

Split by dependency

Fan subtasks out in parallel only when neither needs the other's output; when one does, keep the independent work parallel and sequence the dependent step by forwarding the prerequisite result.

Read the video sequence
  1. 0–6.3s An orchestrator hands two independent tasks, tests and docs, to Worker A and Worker B at the same time. Each writes its own row in the shared code and both results return; the orchestrator chimes green. This is the normal case: parallel work on independent subtasks.
  2. 6.3–11s Before dispatch, the old tests and docs results turn amber and are marked stale. The orchestrator fans out a field rename and a handler that uses it. A renames the field to total_cents, but B used the old name amount. The handler turns red; a red dashed dependency bracket and HIDDEN DEPENDENCY label reveal the mismatch.
  3. 11–15.4s A red redo instruction carries total_cents to Worker B. B rewrites the handler, the row turns green and the dependency bracket becomes green and dotted. The worker task completes one rework round trip late; the old tests and docs remain stale, so this is not a validated or approval-ready patch.
  4. 15.4–17s The stage resets. The field and handler rows return to the old name, and the bracket between them is now shown in orange from the start: the dependency is known before any work is dispatched.
  5. 17–20.5s Worker A renames the field while Worker B does the independent docs task in parallel. The field result, total_cents, travels back to the orchestrator, which holds it for the dependent step.
  6. 20.5–23.85s SEQUENCED appears. The orchestrator forwards total_cents with the handler task. The handler lands at 22.8 seconds without conflict; its completion report returns before tests are dispatched. The dependency bracket becomes green and dotted.
  7. 23.85–30s Tests are dispatched only after the handler is complete. Their result lands at 25.9 seconds and returns before the final join at 26.9 seconds. The resolved state holds, then the stage fades back to the opening title. The plan illustrates correct dependency ordering; enforcement and permission configuration are not shown.
About this cut

Production: anthropic/claude-fable-5-1.

Revision: gpt-6-astra comparative review.

The rename-field/handler example is an illustrative scenario, not a recorded agent run; real conflicts may surface later or not at all.

"Known dependency" stands for a planning decision by a person or the orchestrating model; nothing here shows dependencies being detected automatically or guarantees they will be.

Sequencing is a plan, not an enforced constraint. Written or persistent instructions to an orchestrator do not enforce ordering or permissions.

The red redo round trip stands in for coordination cost qualitatively; no latency, token, or cost figures are claimed.

Audio was analysed from the final AAC: sample peak -1.908 dBFS, signal at all 101 scheduled cue windows, and spectrogram inspected; it was not physically listened to. Overlapping cues were not isolated for audibility.

Independently authored alternative to the baseline cut; a different model is provenance, not proof of quality, and no comparative winner is claimed.

The docs task is assumed independent of the renamed API field; API documentation that consumes that field must also wait for the rename. Tests in the final sequence validate the completed handler; writing test code earlier would be a different task.

Distinct rows illustrate separate output ownership, not permission for agents to mutate one checkout freely; actual editing needs isolated ownership or controlled integration.

These animations use sound effects rather than narration. The written guide explains the mechanism and its limits. Model names describe how a cut was made, not a quality ranking.

What the review found