Coordinate dependencies and reusable skills.

Turn a long goal into a process

“Build a small game” is not one useful action. The source example breaks it into rules, move validation, an interface, integration, and checks. Some outputs are prerequisites for others. A dependency graph records those relationships explicitly.

The game rules must exist before the validator can implement them. The validator and interface can proceed in parallel once their shared contract is settled. Integration waits for both; integration checks wait for an integrated result. A flat to-do list can name all the right tasks while missing these constraints.

In the lab, the flat rule starts the next listed task whenever a worker is free. With two workers it starts the validator at time 0, before the rules finish at time 2. That task is marked as having invalid inputs. Its downstream outputs remain invalid even if they finish quickly. Completion is not evidence that the prerequisites were met.

Parallel time is different from total work

The default software tasks take 2, 4, 3, 2, and 1 time units. With one worker they take 12 elapsed units. With two workers and no overhead, rules finish at 2, the interface at 5, the validator at 6, integration at 8, and checks at 9. Total work is still 12 units; some of it overlaps.

The longest dependent chain is rules → validator → integration → checks, taking 2 + 4 + 2 + 1 = 9. This is the critical path under the zero-overhead assumptions. A third worker cannot shorten that chain: only two tasks are ready in parallel. More available workers do not create more independent work.

Delegation adds communication, task setup, and integration costs. Set overhead to 6 in the lab. The delegated interface now takes 9 units and finishes at time 11. Integration and checks bring elapsed time to 14, slower than the single worker’s 12. Total work rises to 18. These invented times illustrate a tradeoff; they do not measure actual people, agents, or hardware.

The lab uses a fixed list order and assigns the lowest-numbered free worker. It is a simple scheduler, not an optimizer. A more capable scheduler could decline an expensive delegation, choose different assignments, or consider deadlines and variable costs. Compare such alternatives with the same tasks and constraints.

Hierarchy changes the decision scale

Planning over every primitive action at every step can produce too many choices. A reusable skill lets a high-level controller select a larger action, while a lower-level policy handles its details. In hierarchical reinforcement learning, a temporally extended skill is often called an option.

An option has three parts:

• Initiation set: the states in which it is allowed to start.
• Internal policy: how it selects actions while running.
• Termination rule: when it returns control, whether through success, failure, or a bounded stop.

“Verify the integrated build” is a concrete example. It cannot start before valid integration. Its internal policy checks the entry-point contract, runs fixed move cases, and records a result. A failed check terminates it immediately; a successful sequence terminates after three steps. The parent controller receives that result and decides whether to repair, change its plan, or stop.

This resembles calling a software function, but a learned option may act over multiple environment transitions and use a learned internal policy. Our widget is a programmed, deterministic option. Demonstrating the interface of a skill is not the same as training hierarchical reinforcement learning.

Shared files need shared-state rules

The source’s coordination example has one coding agent editing a file while another refactors it. Both local changes can make sense, yet their combination can fail.

In the widget, A adds bounds checking. B renames the entry point. Both drafted from version 1. If A commits first and B blindly replaces the file with its old whole-file draft, B’s rename erases A’s bounds checking. The workers did not intend to undo each other, but their write protocol allowed it.

A version check compares the draft’s base version with the current file version before accepting a write. After A creates version 2, B’s version-1 draft is stale and is rejected. B must inspect the current file and reapply its intended rename while preserving the new bounds behavior. The refreshed draft can then commit against version 2.

The example’s reapplication is simple and programmed. Real edits can require semantic conflict resolution and new tests. A matching version prevents this stale-write race; it does not prove that the proposed change is correct.

A repeated message should not repeat its effect

A caller can lose an acknowledgement and retry an operation that already succeeded. Idempotency means repeating an operation has the same relevant effect as performing it once.

The lab assigns a stable operation identity to a particular draft. With receipt reuse enabled, replaying a successfully committed draft returns its original receipt without writing again or increasing the file version. Rebuilding B’s draft creates a new identity because it is a new proposed operation.

Version checks and idempotency solve different problems. Version checks detect stale bases. Receipt reuse handles duplicate delivery of the same successful operation. Turn both off and replay an old commit after another worker’s change: the repeated whole-file write can undo that later change. Turn only version checks on and the old retry is rejected rather than recognized as an already-completed request.

The simulation records receipts only for successful writes. A rejected stale draft must be refreshed before it can succeed. No repository files or external systems are modified by these controls.

Ownership, recovery, and independent verification

An orchestrator needs explicit ownership: who is responsible for each task and artifact, which version they read, and what output contract they must satisfy. A and B can own different responsibilities while still editing the same file. Ownership clarifies accountability; coordination rules handle the overlap.

Useful recovery is specific to the failure. For a stale base, refresh and reapply the change. For a missing contract, repair the interface. For a failed move case, inspect the corresponding behavior. Blindly retrying unchanged work does not repair an incompatibility. Retain the failed observation so the parent controller can update its plan.

The independent checks in the option use a 3×3 board with coordinates 0, 1, and 2. The interior square should be accepted; the three supplied out-of-bounds squares should be rejected. The expected answers come from the task specification, not from the draft’s self-assessment. A renamed file with no bounds check therefore passes the contract check but fails behavior checks.

Passing these four cases is limited evidence. Other game rules, malformed inputs, interactions, and unseen cases still need testing. A scheduler reporting five completed tasks is also different from these checks passing.

Teams introduce a credit-assignment problem

Workers may optimize local metrics that do not match the overall goal: lines edited, tasks closed, calls completed, or speed. Two fast local edits can leave a broken integrated result. More autonomous workers also introduce duplicated work, conflicting plans, inconsistent memories, and coordination expense.

Credit assignment asks which contributions improved the joint outcome. In this toy model, A alone leaves the old entry point, while B alone leaves bounds checking missing. Both coordinated changes are needed for the intended result. A stale overwrite removes part of that value even though another commit was made.

The comparison cards isolate these contributions under the current protocol. They do not solve general multi-agent credit assignment. Real evaluation may use carefully controlled ablations and matched tasks, while accounting for interactions: removing a worker can also change the schedule, workload, and available information. A reward based only on individual activity can encourage behavior that harms the final product.

Central coordination, shared contracts, ordinary concurrency mechanisms, and independent verification often address these problems more directly than asking a model to “reason better.” Add autonomous workers when their measured benefit justifies their complexity and overhead.

Transfer the graph to a narrated tutorial

Before switching the lab to the tutorial scenario, sketch a graph for producing a narrated video. Identify a shared input, work that can overlap, an integration step, and the final acceptance checks. Explain what would need redoing if the script changed midway.

Inspect a worked task graph

Approve the script → record narration and produce visuals in parallel → edit audio and visuals together → check the final tutorial. Both branches should use the same approved script version. Editing waits for both. A script change can invalidate narration and visuals, so the editor needs versioned inputs and a decision about which artifacts to regenerate.

The supplied times are 3, 4, 5, 3, and 2 units. One worker takes 17; two workers with zero overhead take 13. With overhead 6 on the visual branch, the two-worker plan takes 19. The same dependency principles transfer even though the artifact and acceptance criteria differ.