---
title: 'Parallel Projects, Sequential Tasks'
synced_from_vault: true
vault_source: 03-living-docs/patterns/Parallel-Projects-Sequential-Tasks.md
public: true
type: pattern
tags:
  - pattern
  - systems-thinking
  - agent-design
  - parallelism
  - scaling
aliases:
  - Merge Tax
  - Parallel Projects Sequential Tasks
created: 2026-02-24T00:00:00.000Z
origin: 'Dave Paola — original synthesis, Feb 24 2026'
---

| | |
|-|-|
| **Category** | Systems Thinking / Agent Design |
| **Source** | Dave Paola (original synthesis, Feb 24 2026) |
| **Surfaced** | Conversation with a peer founder about parallelizing AI agent work |

---

## Core Concept

> "As the parallelism grows, the time spent resolving merge conflicts grows faster than the time spent coding. So your agents just spend all their time resolving conflicts. Dialing back the parallelism and just doing things sequentially is actually *faster* past a certain point."

The coordination cost of parallel work within a single project is **superlinear** — it doesn't just limit your speedup ([Amdahl's Law](/patterns/amdahls-law)), it creates a crossover point where parallelism makes you *slower*. Past that point, sequential execution wins.

**The prescription:** Parallel *projects*, not parallel tasks within projects. The unit of parallelism is the project, not the task.

---

## The Merge Tax

Every parallel branch creates a future merge event. The cost of that merge is not constant — it depends on how much the codebase has changed since the branch was created, which depends on how many *other* parallel branches have been merged. This creates a compounding effect:

- 2 parallel agents: occasional conflicts, easy to resolve
- 5 parallel agents: frequent conflicts, some cascading
- 9 parallel agents: "a clusterfuck" — agents spend more time resolving conflicts than writing code

The merge tax is superlinear because each resolved conflict changes the base, invalidating other branches' assumptions. Agents *can* resolve merge conflicts — but their ability to do so doesn't change the fundamental math that the conflicts grow faster than the productive work.

---

## Why This Matters for AI Agent Design

The temptation with cheap AI compute is to massively parallelize: spin up 10 agents, each working on a different task in the same codebase, merge everything at the end. This feels like it should be 10x faster. In practice:

1. **Agents produce code that assumes a shared state** — but parallel execution means no agent sees the others' changes
2. **Merging is inherently sequential** — PRs can only be merged one at a time
3. **Each merge potentially invalidates subsequent merges** — creating cascading rework
4. **The coordination layer (conflict resolution) grows faster than the production layer (code writing)**

The better architecture: run agents sequentially within a project, sharing context through a protocol (like WCP) rather than competing over shared files. Each agent picks up where the last left off, with full context. No merge conflicts, no wasted work.

---

## Where It Applies

| Context | Parallel Unit | Sequential Unit | Why |
|---------|--------------|-----------------|-----|
| **AI agent workflows** | Projects (separate repos/namespaces) | Tasks within a project | Merge conflicts grow superlinearly |
| **Engineering teams** | Squads (own their service) | Features within a squad | Same principle — Brooks's Law is the human version |
| **WCP architecture** | Namespaces (independent) | Work items within a namespace (sequential agent handoffs) | Design matches the physics |
| **Git workflow** | Repositories | Branches within a repo | The branching model works because repos are independent |

---

## Connection to WCP Design Principles

This pattern is why WCP is designed the way it is:

- **Principle #1 (Evolve from working systems):** Sequential context sharing emerged from actually building things, not from theorizing about parallelism
- **Principle #5 (No enforced transitions):** WCP doesn't orchestrate parallel agents — it's a shared context layer for sequential handoffs
- **Namespaces as the parallel unit:** Different namespaces are completely independent. Different projects CAN run in parallel because they don't share state. Within a namespace, agents work sequentially and share context through work items, comments, and artifacts.

WCP's architecture embodies this pattern: the tool supports parallel *projects* (namespaces) while encouraging sequential *work* (activity logs, status transitions, context-rich handoffs between sessions).

---

## Relationship to Other Laws

| Law | What It Says | How This Extends It |
|-----|-------------|---------------------|
| Amdahl's Law | Sequential portions limit speedup | This extension: coordination costs can make parallelism *net negative*, not just limited |
| Conway's Law | Org structure mirrors system architecture | Parallel teams → parallel systems → integration pain at the boundaries |
| Brooks's Law | Adding people to a late project makes it later | Same superlinear coordination cost, applied to humans instead of agents |

---

## The Test

Before parallelizing work within a project, ask: **"Will these parallel streams need to be merged into a shared codebase?"** If yes, you're paying the merge tax. Consider whether sequential execution with shared context (WCP, detailed handoff notes) would actually be faster end-to-end.

---

## Cross-References

- [Amdahls-Law](/patterns/amdahls-law) — the theoretical foundation (this extends it)
- [Conways-Law](/patterns/conways-law) — org-level version of the same coordination cost
- [Augmentation-Over-Automation](/patterns/augmentation-over-automation) — humans sequence work, agents execute; the sequencing IS the human value-add