Split Parallel Agent Work Around Deliverables and Dependencies

Split parallel work around artifacts that can be completed and checked independently. Give every task a required input, an owned output and a concrete condition for starting its dependent work. This makes the work graph useful even if you coordinate it with plain notes rather than an agent scheduler.

For a first pass, write down four things: what must be decided first, what can then proceed independently, what files are shared and who will assemble the result.

A four-task feature change

Consider a fictional project adding category search to a list of articles. The feature should match text within a selected category, retain the original item order and show a useful empty state. The example below is a planning exercise, not a report of agents running or a measured delivery schedule.

The output contract is a small query object and ordered results:

Query v1
- text: a string; trim surrounding whitespace
- category: a category ID, or "all"

Search behavior
- Match the trimmed query against article titles, ignoring ASCII letter case.
- Empty text means no text restriction.
- category="all" means no category restriction.
- Preserve the input item order.

Result items
- Preserve each item's id, title and category.
- The view provides its own empty-result message.

That contract gives the matcher and the view something to build against. It deliberately leaves product questions, such as searching article bodies or ranking by relevance, outside this change.

Draw the work graph

flowchart LR
    A["A · Contract and shared fixtures"] --> B["B · Matcher module"]
    A --> C["C · Search controls and states"]
    B --> D["D · Integration and combined checks"]
    C --> D

The arrows describe required outputs. B and C can proceed together after A is usable. D can prepare its checklist earlier, but it cannot check the assembled feature until both implementation artifacts exist.

GitHub's task-scoping guidance recommends clear problem descriptions, acceptance criteria and relevant file directions. The following cards apply that idea to this fictional feature; they do not assume a particular platform's concurrency or permissions.

Give each task an owned artifact

Task and role	Input	Owned delivery	Ready for downstream use when…
A: contract editor	Feature goal and existing item shape	`search-contract.md` and a shared example fixture	Query fields, empty-input rules, ordering and expected fixture IDs agree
B: matcher implementer	Accepted Query v1 and fixture	`search-items.js`, with proposed checks	It handles the contract cases and identifies the exact change and check results
C: view implementer	Accepted Query v1 and fixture	Search controls, empty state and view-specific checks	It emits the agreed query shape and handles the defined result states
D: integrator	Exact B and C deliveries plus Query v1	Combined change, shared configuration and integration record	Matcher and view work together against the same contract and selected checks

Use role labels for ownership; an actual team can map them to people or agents. Give shared entry points and configuration to D. If B or C discovers a necessary shared-file change, include a proposal in the delivery rather than having both overwrite it.

A small shared fixture makes “matches the contract” inspectable:

Items, in this order:
1. id=a, title="Voice drafts", category=guide
2. id=b, title="Draft review", category=reference
3. id=c, title="Keyboard notes", category=guide

Expected examples under Query v1:
text=" draft ", category=all       -> [a, b]
text="",        category=guide     -> [a, c]
text="DRAFT",   category=reference -> [b]
text="absent",  category=all       -> []

These are expected answers derived from the fictional rules, not recorded test results.

Copy a task card

Task and responsible role:
Required input and version:
One owned delivery:
Files this task may change:
Shared files to propose to the integrator:
Checks needed for this delivery:
Actual check results or explicit not-run status:
Reference to the exact delivered version:
Downstream task that consumes it:
Open questions that would change the contract:

A task ending its chat is a communication event. A delivery becoming usable is an artifact decision: the consumer can find the expected version, understand it and check its relevant conditions.

For example, “matcher finished” is insufficient if its delivery renamed category to categoryId. C may already be emitting the agreed field. Resolve that contract difference before asking D to combine both sides.

Fix an over-parallel plan

A weak plan starts all four tasks immediately. B invents the query fields, C invents a different shape and D edits shared configuration while both are still changing assumptions. More simultaneous activity has produced more coordination work.

A corrected sequence is:

Stage	Useful work	Start condition
1	A defines Query v1 and the fixture; D prepares integration questions	The feature goal is understood
2	B and C build their separate outputs	A's contract and expected cases are consistent
3	D combines the exact deliveries	B and C identify compatible artifacts and their actual check status
4	Relevant owners address combined findings	A concrete mismatch or failure has been identified

This is a dependency sequence, not a promise about duration. If the matcher and view cannot be separated without repeatedly renegotiating the interface, one sequential task may be easier to finish.

Handle a changed contract explicitly

Suppose category search now needs multiple categories. Record a Query v2 proposal and identify which B and C work it affects. Decide whether to finish v1 or revise both deliveries. Silently editing the shared note while downstream work continues makes the graph unreliable.

Use parallelism where stable inputs permit separate progress. Keep the work graph small enough that each arrow points to a real artifact, and make the final task responsible for checking the combination rather than adding together individual success messages.