How do you tell truly parallel subtasks from false parallelism in an agent plan?

## Why this question exists Decomposition produces a set of subtasks and an ordering. The tempting move is to treat every step not obviously downstream of another as parallelizable, because that is where the wall-clock win is. False parallelism is what happens when that judgement is wrong: work is launched concurrently that was actually ordered, and — this is the important part — the failure usually does not look like a failure. It looks like a plausible result that is missing half its inputs, or an artifact where one branch's edits overwrote the other's. ## The three sources of hidden dependency **1. Shared write targets.** Two subtasks that both modify the same artifact are ordered, even when neither reads the other's output. An agent upgrading a shared dependency across twelve services will happily plan twelve independent-looking subtasks; if three of them edit the same lockfile or the same shared config, running them together means the last write wins and two services are silently left unpatched. Nothing errors. The plan reports twelve successes. **2. Hidden data flow.** A step's *scope* can depend on another step's *result* even when its inputs look self-contained. A survey step that determines which services are actually affected must precede the per-service work; skipping the edge means patching services that did not need it and missing ones that did. This edge is easy to miss because the dependency is on a decision, not on a file. **3. Shared bottleneck resources.** Two branches can be perfectly independent in state terms and still gain nothing from concurrency because they contend for one scarce thing — a rate-limited API, a single database connection, a serialized review queue, a human approver. This is the benign case: nothing corrupts, but the parallelism is an illusion and often a net loss once retries and backoff enter the picture. ## A usable test For each candidate pair, write down three sets and check they are disjoint: - **Writes**: every artifact, file, record or external system state the subtask mutates. - **Reads**: everything it consumes, *including* decisions made by earlier steps that define its scope. - **Consumes**: the scarce resources it draws on. Disjoint writes and no read-of-the-other's-write means the branch is safe. Disjoint consumes means the branch is worth taking. Both conditions matter and they fail for different reasons — the first produces wrong results, the second produces no speedup. The part candidates most often miss is that a subtask's read set includes *implicit* reads. A step that says "summarize the affected contracts" reads the definition of "affected", which some earlier step produced. If that definition is not yet final, the step is not ready to run regardless of what the plan says. ## Making dependencies visible rather than inferred The reason this is hard for an LLM-authored plan is that the model orders steps by narrative plausibility, not by state analysis. It has no direct view of what a tool actually mutates. The practical mitigation is to make the plan state it: each subtask names what it will write, and the executor refuses to run two subtasks whose write sets intersect. That converts a reasoning problem into a mechanical check — and mechanical checks are the only ones that hold up across many runs. Where the write set genuinely cannot be predicted ahead of time — an agent editing whichever files turn out to be relevant — the conservative move is to keep that stage sequential, or to give each branch its own isolated copy of the mutable state and reconcile afterwards. Isolation converts a shared write into two private ones plus an explicit merge step, which at least surfaces the conflict instead of losing it. ## Signals you got it wrong Watch for: two branches reporting success while the combined artifact contains only one branch's changes; results that vary run to run in ways the plan does not explain; wall-clock that barely improves after parallelizing, which points at a shared bottleneck; and retry storms as branches contend for the same rate-limited dependency. The first is the dangerous one, because it is silent — which is why the write-set check belongs before execution rather than in post-hoc review. ## What a strong answer sounds like Name all three sources of hidden dependency, distinguish the *correctness* failure (shared writes, hidden data flow) from the *throughput* non-win (shared bottleneck), and say plainly that absence of an obvious ordering is not evidence of independence. The best answers add the mitigation: declare write sets so the check is mechanical, and isolate state when it cannot be declared.