More Agents Won't Speed Up Every Part of Your Pipeline — Designing the Parallel/Serial Line

Deriving What Stays Serial From the Invariants

What stays serial is reasoned backward from the promises you must not break (the invariants), not from preference. The hardest promise in my pipeline is that the Japanese article count and the English article count are always equal. It's the premise for avoiding a 404 on language switch, and if it breaks, trust in the whole site is damaged.

To hold this invariant, the operation that "writes a JA/EN pair as one unit" must not be split. If two agents fire a push into the same category at the same time, you can end up with a half-finished state where only one side's English version lands first during a rebase. So while generation (drafting) can be parallel, the join step of verify → count check → push is kept on a single serial track per repository.

[parallel OK] per-site drafting (independent outputs)
        ├─ agent-A: claudelab ja/en drafts
        ├─ agent-B: gemilab ja/en drafts
        └─ agent-C: antigravitylab ja/en drafts
                    │
[serial required] per-repo join (the single track that holds the invariant)
        for repo in repos:
          gate(repo) -> assert ja_count == en_count -> push(repo)

The point is to make the serial region as small as you can. "All serial" is safe but slow. Keep serial only the minimal stretch that touches the invariant you want to protect, and open everything else to parallel. How you draw this boundary is, directly, how fast the whole thing runs.

Deriving the Concurrently Runnable Set From a Dependency Graph

Managing the line purely in your head will always fall apart as tasks grow. If you keep inter-task dependencies as an explicit graph, you can derive "the set you may run at the same time right now" mechanically. Below is a minimal implementation that computes the critical path and each stage's parallel-runnable set from a dependency map. When you write orchestration with Antigravity's SDK, inserting this preprocessing makes the "openings you may line up" surface on their own.

// tasks: declare each task's dependencies (an array of prerequisite task names)
const tasks = {
  draftClaude:  { deps: [],                cost: 40 }, // generation is independent
  draftGemini:  { deps: [],                cost: 40 },
  draftAnti:    { deps: [],                cost: 40 },
  gateClaude:   { deps: ["draftClaude"],   cost: 8  }, // verification depends on its draft
  gateGemini:   { deps: ["draftGemini"],   cost: 8  },
  gateAnti:     { deps: ["draftAnti"],     cost: 8  },
  pushAll:      { deps: ["gateClaude","gateGemini","gateAnti"], cost: 6 }, // the join
};
 
// group tasks whose deps are satisfied into "waves" (same wave = concurrently runnable)
function scheduleWaves(tasks) {
  const done = new Set();
  const waves = [];
  const all = Object.keys(tasks);
  while (done.size < all.length) {
    const ready = all.filter(
      (t) => !done.has(t) && tasks[t].deps.every((d) => done.has(d))
    );
    if (ready.length === 0) throw new Error("cyclic dependency");
    waves.push(ready);
    ready.forEach((t) => done.add(t));
  }
  return waves;
}
 
// compute the critical-path length (the theoretical minimum wall-clock time)
function criticalPath(tasks) {
  const memo = {};
  const longest = (t) => {
    if (memo[t] != null) return memo[t];
    const base = tasks[t].deps.reduce((m, d) => Math.max(m, longest(d)), 0);
    return (memo[t] = base + tasks[t].cost);
  };
  return Math.max(...Object.keys(tasks).map(longest));
}
 
console.log(scheduleWaves(tasks));
// => [['draftClaude','draftGemini','draftAnti'], ['gateClaude','gateGemini','gateAnti'], ['pushAll']]
console.log("critical path:", criticalPath(tasks), "→ 40 + 8 + 6 = 54");

The value 54 that criticalPath returns is what matters. It represents the theoretical floor: "even with infinite agents, you won't go faster than this." No matter how parallel the three drafts run, as long as the join pushAll exists, the whole thing pins to the length of one draft plus verification plus the join. Knowing this floor before you add agents keeps your judgment honest.

Measuring That Throughput Doesn't Scale Linearly

Even when the floor is visible in theory, the actual gain has to be measured. Keep a plain harness that times wall-clock while varying the degree of parallelism, and you'll grasp the "agent count that actually helps" for your pipeline.

#!/usr/bin/env bash
# vary parallelism across 1, 2, 4 and time the total wall-clock for the same jobs
set -euo pipefail
jobs=(draftClaude draftGemini draftAnti)   # jobs that can run independently
 
run_one() { sleep "$((RANDOM % 3 + 2))"; }  # replace this with the real generation call
 
for p in 1 2 4; do
  start=$(date +%s)
  printf '%s\n' "${jobs[@]}" | xargs -P "$p" -I{} bash -c 'run_one "{}"' _ 2>/dev/null || \
  printf '%s\n' "${jobs[@]}" | xargs -P "$p" -I{} sleep 2
  end=$(date +%s)
  echo "parallelism ${p}: $((end - start))s"
done

When I measured my article-generation pipeline in my own environment, instead of the naive 4x speedup, even at parallelism 4 the wall-clock only shrank by about 1.8x versus the parallelism-1 case. The reason is plain: generation can be opened up in parallel, but the serial stretch of verify and push, and the shared model-API quota, remain. That "1.8x" figure is exactly the retreat line that says adding more agents no longer pays. If you want more speed, shortening the serial stretch itself (lighter verification, a different join granularity) does more than adding agents.

Where I Drew the Line in My Pipeline

The boundary I eventually settled on is very simple, and it comes down to three rules.

1. Open drafting to parallel per site (independent outputs, so they may be lined up).
2. Close verification, count check, and push to serial per repository (the single track that holds the invariant).
3. Cap concurrent calls to the model API so the agents don't devour a shared quota among themselves.

I recommend keeping them in this order. With just those three, the line-waiting backup that had appeared when I increased agent count almost entirely disappeared.

Parallelism is the work of finding independent parts and opening them up; it isn't a race to move everything at once. Put the promise you want to keep into words first, leave serial only the smallest stretch that touches it, and lay out the rest. The order is always this direction.

As a next step, write down just one place in your currently-parallel work where multiple agents "write to the same mutable state." That spot is the real bottleneck that won't get faster no matter how many agents you add.