Launching five agents on one large issue does not create five independent units of progress. If all five edit the same module, interpret the same vague requirement, and compete for one integration decision, the team may have created a queue of conflicting patches.
Parallel work pays off when tasks can progress independently and their boundaries are clear. The hard part is often not running more agents. It is designing a work topology that limits shared state, names an owner for every interface, and budgets time for integration and review.
Draw the dependency graph before assigning workers
Break the goal into work units and mark which units depend on others. A useful split might be:
| Work unit | Depends on | Output | Can proceed in parallel? |
|---|---|---|---|
| Define the new request/response contract | Product decision | Reviewed interface note | No, decide first |
| Add a parser for the settled contract | Contract note | Parser and focused tests | Yes |
| Update a separate client adapter | Contract note | Adapter and focused tests | Yes, if its files are independent |
| Add integration coverage | Parser and adapter | Integration tests | After both outputs exist |
| Validate the combined behavior | All changes | One integrated result | No, one owner should accept it |
The table makes dependencies visible. Starting implementation before the interface is settled can produce parallel work that must all be redone when the decision changes.
Parallelize independent slices, not copies of the same judgment
Good candidates for parallel work usually have:
- separate files or modules;
- explicit input and output contracts;
- limited shared mutable state;
- independent tests or fixtures;
- a clear handoff point.
Poor candidates include two agents editing the same state machine, multiple workers independently redefining a public API, or several reviewers given the same context and then treated as statistically independent votes. Different agent names do not guarantee different assumptions, tools, training data, or blind spots.
For one current platform example, OpenAI’s Agents API announcement describes coordinating subagents and running programmatic tool calls in parallel. Those are execution capabilities, not evidence by themselves that a particular work decomposition reduces end-to-end effort.
Parallel analysis can still be useful. Ask one worker to inspect migration risks and another to inspect test coverage, then have a responsible integrator compare their evidence. Do not count agreement as proof when both may have relied on the same mistaken premise.
Name one owner for every shared surface
Assign ownership at the level where conflicts actually occur:
- one owner for the interface or schema;
- one owner for each shared file or module;
- one integrator for the combined branch;
- one person accountable for the final acceptance decision.
Workers should return bounded changes with a short report: paths changed, tests run, results, assumptions, and unresolved questions. Avoid giving every worker authority to merge into the shared branch; that converts a coordination problem into a shared-state race.
For code, isolated branches or worktrees can reduce accidental collisions. For research or review, separate notes with source links preserve the reasoning each worker used. The integration owner then compares outputs and resolves contradictions rather than concatenating them blindly.
Include integration in the schedule
Total completion time is shaped by the longest dependency path plus handoffs, conflict resolution, combined checks, and review. If the team counts only the time spent by workers, it leaves integration invisible.
For example, three parallel changes may each finish quickly but share a generated file, rely on different versions of a contract, and fail together under the integration tests. The result is not three completed tasks; it is one unresolved integration episode.
Reserve explicit time for:
- collecting results and confirming each worker stayed within scope;
- comparing assumptions and resolving interface differences;
- applying the changes to one canonical branch or workspace;
- running checks against the combined state;
- reviewing seams between components and documenting what remains unknown.
The combined state needs fresh evidence. Separate green results from isolated branches do not prove that their combination works.
Start with the smallest useful team
For a first pilot, choose an issue that has at least two genuinely independent slices. Give each slice a named output, separate workspace, and common integration criteria. Record:
- time to first useful result;
- human coordination and review minutes;
- duplicate or conflicting work;
- interface changes after work began;
- integration failures and rework;
- combined acceptance result.
Then compare with a similar task handled sequentially or with the team’s established workflow. Do not compare a highly decomposable task with a tightly coupled one and attribute the entire difference to agent count.
Add another worker only when the work graph has another independent slice and the first group’s coordination cost is understood. More workers can increase capacity, but they can also increase the number of handoffs and the effort needed to establish one coherent result.
Separate coordination from authority
A coordinator can distribute work and collect evidence without receiving permission to merge, release, or decide product policy. Keep the coordinator’s authority no broader than its task requires. A human or deterministic gate should own the final acceptance boundary according to the risk of the change.
This is an organizational design choice as much as a model choice. Clear work units, stable interfaces, isolated execution, and explicit accountability help whether the workers are AI agents, human developers, or a mix of both.
The topology review
Before launching parallel work, answer:
- Which tasks are independent, and which are blocked on a decision?
- Which files, services, datasets, or environments are shared?
- Who owns each shared interface and the final integration?
- How will conflicting assumptions be detected?
- Which tests must run on the combined result?
- How will review and coordination effort be counted?
- What condition ends parallel execution and returns the task to one owner?
If the answers are missing, adding agents is likely to make the uncertainty move faster. First make the work graph legible; then parallelize the slices that remain independent.
References
- Hassan et al., “A Roadmap for Agentic Software Engineering”
- OpenAI, “Introducing the Agents API” (2026-09-10)
- METR, “We are Changing our Developer Productivity Experiment Design” (2026-02-24)
Source, license, and AI assistance
This article develops the organizational-design and parallel-delegation questions in Part II of From Vibe Coding to Agentic Software Engineering. The source record credits ChatGPT as preparer and identifies CC BY-NC-SA 4.0. This version is substantially reorganized and expanded with a work-topology model, integration practice, and updated references, and is shared under the same license: CC BY-NC-SA 4.0.
AI disclosure: The article text was generated primarily by AI. A human publisher supplied the topic, source material, and editorial direction, and remains responsible for checking claims and examples before publication.
Top comments (0)