Agents
/parallelParallel agents are fast only when the work can separate.
The part that feels like free speed
Two agents are faster only when the work can separate
Give two AI agents two tasks at the same time and the arithmetic looks irresistible. If each task takes twenty minutes, perhaps the pair finishes in twenty instead of forty. Sometimes it does. Sometimes the agents return two individually plausible changes that take another hour to reconcile.
A parallel-agent workflow runs multiple pieces of work at once. Its speed is conditional. The elapsed time is not merely the longest task. It also includes decomposing the work, giving each agent enough context, coordinating decisions, reviewing every result and integrating the parts. Parallelism helps only when the time saved exceeds those added costs.
Two ways the same keystroke ends
Run tangled work in parallel and you can go slower
Independence does not mean that the tasks live in different repositories or never mention the same file. It means their coupling is controlled. Each task has a named owner, the information passed between tasks has an agreed shape, and combining the results should not change meaning according to which result lands first. If one agent must revise its work whenever the other makes a reasonable choice, the interface is not stable enough yet.
Consider an online-booking feature. First, the team agrees the interface, meaning the exact information passed between two parts: a successful booking returns an event identifier, start time and confirmation status; a rejected booking returns one of three named reasons. Agent A owns the calendar adapter and its contract tests. Agent B owns the confirmation screen and builds against fixed examples of those responses. Neither may change the interface. A reviewer can check each result against the same agreement, then integrate them and run one labelled event through a controlled test calendar. The check confirms the screen and calendar match, then removes the test event.
That is a good use of delegating to subagents. The ownership is explicit, each result can be reviewed on its own and the final test has a clear outcome: one calendar event and the matching confirmation on screen. The agents still require review and an integration check. They save elapsed time because those costs are smaller than waiting for one implementation to finish before starting the other.
Parallel speed needs controlled coupling
The work separates only after ownership and the shared interface are stable enough to review independently.
- Agree the booking contract Success and rejection responses have fixed meanings. Shared interface
- Assign mutable surfaces Calendar adapter and confirmation screen have separate owners. Explicit ownership
- Build against the same examples Each result can be checked without waiting for the other. Independent review
- Integrate in a controlled calendar Create one labelled test event and confirm both surfaces match. Combined evidence
- Clean up and accept Remove the test event; one owner judges the combined result. Authority boundary
Speed is real only if dispatch-to-accepted-result becomes shorter.
When the slices aren't disjoint yet
Isolation contains a collision; it does not settle it
Now give one agent “add timezone support” and another “improve the booking form.” Both change the form, validation rules and date formatting. One stores a universal timestamp and converts it for display. The other starts passing preformatted local times between the browser and server. Both branches may pass their own tests, yet their assumptions conflict. Whichever patch lands second changes the meaning of the first.
The decision rule is simple: if two tasks can make incompatible choices about the same behaviour, do not dispatch them yet. Decide the shared rule first, assign one owner to each mutable surface and define what each task may return. After that, the work may separate. If the second task genuinely needs the first result, keep the dependency sequential.
A worktree, a separate working copy of the same repository, can keep agents from overwriting one another while they work. It prevents working-tree overwrites and defers some conflicts to integration; it does not resolve the design disagreement. Overlapping patches still need an integration owner, an intentional merge order and a review of the combined behaviour. Isolation is useful infrastructure, not proof of independence.
A worktree isolates one layer
Separate working directories prevent direct overwrites, while shared services and semantic integration remain.
- Working copies Uncommitted files, generated output and focused test state stay separate.
- Repository history Branches and repository objects still belong to the same repository.
- External resources Databases, ports, caches, credentials and provider accounts need separate isolation.
- Design assumptions Two clean branches can still encode incompatible choices.
- Integration gate One owner reviews merge order, combined behaviour and cleanup.
Mechanical separation buys a safer boundary. It does not manufacture independence.
Earn it before you spend it
The speed is the reward, not the shortcut
Before dispatch, write down seven things: the owner; the allowed surfaces, meaning the files, resources or services the agent may change; the stable inputs; the expected output and evidence; prohibited actions; the condition for stopping or escalating; and the person who will integrate the results. Destructive changes and external side effects remain reserved for explicitly named authority. Then ask whether either task can invalidate the other's assumptions or whether merge order can change the outcome. A “yes” means resolve that boundary first or run the work in order.
This is harness engineering applied to coordination. The structure makes authority and evidence visible before several agents start making changes. It also protects the scarce resource in the system: human review attention. Five agents may produce five outputs at once, but a reviewer still has to understand the claims, inspect the evidence and judge the combined result.
Small tasks, unstable requirements and changes with heavy integration costs may be faster in sequence. Parallel research can also be deliberately redundant when independent opinions are the goal, but that buys stronger comparison rather than automatic speed. My student rule is to measure the whole path from dispatch to accepted result, not the number of busy terminals. Parallelism has earned its place when it shortens that path without hiding ownership, moving unresolved decisions into the merge or lowering the standard of review.
Parallelize when ownership is explicit, interfaces are stable, results can be reviewed independently and merge order does not change their meaning.