20 Coordinate parallel work while it happens

Two agents can work in different files and still implement incompatible systems. One changes a status producer so that complete means transfer has ended. Another changes a consumer so that complete enables immediate use. No line collides. The combined application announces readiness before publication finishes.

This is why coordination cannot be postponed to the merge command. File isolation solves one class of interference. It does not align meanings, preserve decision authority, or discover that two apparently independent tasks rely on the same assumption.

Before splitting work, identify the shared promises. For our resource example, these include resource identity, the meaning of availability, the publication boundary, and the survival of the previous version after failure. Workers can own disjoint implementations of those promises. They cannot independently redefine them and expect a clean merge to reconcile the result.

Detect the kind of conflict

A textual conflict is visible in overlapping edits. A semantic conflict appears when compatible text produces incompatible behavior. An ownership conflict occurs when two workers each believe they may decide the same change. A stale-assumption conflict arises when an otherwise valid proposal depends on a contract that has since changed.

These distinctions suggest different responses. Overlapping comments may need a trivial edit. A disagreement about readiness needs a decision and affected tests. A stale proposal may need only revalidation if the intervening change is irrelevant; automatically throwing it away wastes work. Automatically applying it risks restoring an obsolete decision.

In the running example, imagine two workers propose changes involving ResourceStatus. The acquisition worker wants to add checked; the interface worker wants to treat every state other than acquiring as usable. Early coordination could produce this record:

Detected dependency: Both proposals depend on the meaning of readiness.

Proposal: Add a distinct checked state. Keep usability tied to publication, not to absence of transfer.

Acquisition owner: Confirms it can emit the new state without changing publication ownership.

Interface owner: Confirms it will remain in a preparing presentation until publication settles; requests a fixture for the held boundary.

Integration owner: Accepts the contract revision, updates the shared fixture, and asks both workers to revalidate against that revision before application.

Consent here means each affected owner has actually considered the proposed obligation. A coordinator should not write “all agreed” because no worker objected before a deadline. Nor should a worker's agreement be treated as authority to override the requester on a product decision.

Guard application where stale state matters

Once work has been prepared against a shared base, integration must check whether that base still applies. A proposal can name the contract revision it assumes and the write set it intends. The integrator compares those assumptions to current state before applying it. If they differ, the next step is classification: irrelevant change, compatible adjustment, or a decision that needs reopening.

Such a mechanism is useful when several pending proposals can become stale. It may be needless machinery for two read-only researchers and one serial writer. The risk follows mutable shared authority, not participant count.

Coordination state itself can become stale. A reservation left by a stopped worker should not block the repository forever, but an old heartbeat does not prove that the owner is gone. A paused process can still own a lock. A new process can reuse a familiar identifier. Recovery is another concurrency problem, with a more dangerous opportunity to mistake uncertainty for permission.

Passeur's September 25 repair addresses this at a specific owner. Independent review found a stale-lease recovery race; the implementation introduced a persistent recovery guard and exact-generation checks. Source tests include sixteen competing reclaimers with one successful acquisition, and a paused child that continues to exclude a contender. The recorded checks are bounded Linux/process evidence, not proof of every host recovery path. Repair record, competing reclaimers, paused owner.

The application-level lesson is narrower than “add locks.” Mutation authority needs evidence appropriate to the object being protected. The identifier of a task, the generation of a repository lease, and permission to alter a product contract are different kinds of evidence.

Ask whether the work should be parallel

Coordination has a cost even when it succeeds. Stable independent tasks can amortize that cost. Rapidly changing shared concepts may not. The scaling-agent study provides a useful restraint: its results vary with task structure, and its software evaluations use only twenty tasks in each of two benchmarks. It cannot establish a generally optimal number of coding agents. Towards a Science of Scaling Agent Systems, version 3.

A practical alternative is to keep one implementation owner and parallelize investigation, test design, or review. Another is to stabilize one small shared contract before opening several write assignments. These choices do not forgo all concurrency. They place it where workers can make progress without repeatedly renegotiating their inputs.

Exercise a clean merge that fails

Create two small changes in the illustrative application: one changes when the producer emits completion; the other changes when the consumer enables use. Keep their write sets disjoint. Verify that both focused suites can pass while a held-publication integration test fails.

Then introduce a shared readiness contract and repeat the handoff. Record when the incompatibility becomes visible and how much work must be revised. Finally, make one proposal stale by changing the contract before application. The observable outcome is early detection plus a justified integration decision, not merely a successful text merge or a larger coordination log.