We Ran a 4-Agent Swarm Against One Agent With a Scratchpad. The Scratchpad Won.

Why this matters

Sit in enough architecture reviews and you'll spot the tell: someone proposes four agents when one would do, because four agents look like a real system and one agent looks like a demo. Guess wrong on that call and you don't pay once — you pay a coordination tax on every single run, forever, for output a plain scratchpad would have matched.

The swarm we shipped and quietly dismantled

We built four agents for a ticket-resolution pipeline — planner, coder, reviewer, tester — passing structured messages between them. Getting the handoffs stable took two weeks. Then we ran it head-to-head against a single agent with a markdown scratchpad: one running file where it wrote its plan, its findings, its open questions, as it went. Same batch of real tickets, both sides.

• ▹The single agent won on correctness — and not by a slim margin, on most tickets.
• ▹The reviewer kept second-guessing calls the coder had already made with better context, because it was reviewing a summary, not the reasoning that produced it.
• ▹Bugs crept in at the handoffs — the planner's assumptions didn't survive translation into the coder's prompt.
• ▹Debugging the swarm meant pulling four transcripts and reconstructing who told whom what. Debugging the single agent meant reading one file, top to bottom.

We didn't kill the swarm because multi-agent is a bad idea. We killed it because this ticket never needed splitting in the first place — splitting it only added failure surface, not capability.

What "embarrassingly parallel" actually means for tickets

The term is borrowed from distributed computing, and it's exact: a workload is embarrassingly parallel when the subtasks share no state, need nothing from each other's intermediate output, and the results merge with zero negotiation — think rendering independent pixels of an image. That's the bar multi-agent has to clear before the parallelism pays for itself instead of costing you.

• ▹Passes the test: the same lint-and-fix pass across 30 unrelated repos. Five independent landing-page variants for an A/B test. Summarizing 200 support tickets that never reference each other.
• ▹Fails the test: a feature that touches the API contract, the frontend, and the migration in one PR — every piece constrains the others, so whoever's working on it needs live context from the rest, not a merge at the end.
• ▹Fails the test: chasing a flaky test. The fix could live anywhere in the call stack, so splitting the search space up front usually just means someone's searching the wrong half.
• ▹The tell: if you can't describe the subtasks without saying "then" or "depends on," it isn't embarrassingly parallel — it's sequential work in a parallel costume.

The tax nobody puts on the roadmap

Multi-agent carries three real costs, and none of them show up in the estimate — they only surface once agents disagree or duplicate work, which is precisely the moment you can least afford a surprise.

• ▹Coordination overhead — every handoff is a serialization step. The sender compresses its reasoning into a message; the receiver reconstructs enough context to act on it. That round trip burns tokens and latency even when nothing goes wrong.
• ▹Redundant context — without a shared scratchpad, each agent re-derives facts the others already nailed down: re-reading the same file, re-deriving the same constraint, because there's no single place holding the working state.
• ▹Unresolved disagreement — when the reviewer and the coder disagree, something has to arbitrate. Usually that's a fixed hierarchy (reviewer wins, even when it's wrong) or a human. And a human arbitrating every disagreement defeats the whole point of automating the ticket.

The before/after: same ticket, two architectures

We picked one representative ticket — add a rate-limit header to an existing endpoint, plus a test — and reran it five times each way, same model, same repo state.

4-agent swarm:      ~14 min wall clock,  ~3.2x tokens,  2 of 5 runs needed human tie-break
1 agent + scratchpad: ~6 min wall clock,   1x tokens,     0 of 5 runs needed intervention
Correctness (tests pass + no regression): swarm 3/5, single agent 5/5

The swarm wasn't just slower and pricier — it was less correct. The coordination overhead ate the budget that should've gone into solving the ticket, and the two failed runs were exactly the disagreement-arbitration problem from above, playing out in real time.

The one class of task where the swarm did win

One workload did belong to the swarm: the same static-analysis-and-autofix pass, run across 40 independent microservice repos. Each repo was self-contained, no agent needed anything from another, and merging results meant concatenating 40 independent PRs — zero negotiation.

• ▹How to spot it in your backlog: the task already reads as "do X across N things," and the N things never reference each other.
• ▹The merge step is mechanical — concatenate, aggregate, pick-the-best-of-N — not a judgment call about how the pieces fit together.
• ▹A failure in one branch doesn't change the correct answer for any other branch.
• ▹If all three hold, multi-agent buys you wall-clock time roughly proportional to N agents, with none of the coordination tax, because there's nothing to coordinate. Day 3 goes deeper on when this actually pays off in production.

The 5-minute test

Before you spin up a second agent, try writing the whole task as one prompt for one agent — as if you had to hand it to a single capable engineer with a notebook and nothing else.

• ▹If it writes cleanly as one prompt with one scratchpad, that's your architecture. No swarm needed.
• ▹If you catch yourself writing "first do A, and once A's done, use its output for B," you've got a sequential task — multi-agent won't fix that, it'll just insert a lossy handoff in the middle.
• ▹If you catch yourself writing "do this same thing N times, over N independent things," that's your real embarrassingly-parallel signal — not spare GPU budget, not the fact that multi-agent sounds more architecturally serious.
• ▹The failure to write it as one prompt — that's the signal. Agent count isn't the signal. It's a symptom people reach for when they skipped this test.

Extend your knowledge

• ▹Run the 5-minute test on the last three tickets your team labeled 'good multi-agent candidate.' Write each as a single prompt and see how many actually resist it.
• ▹Instrument one real run both ways — single agent with a scratchpad vs. your current swarm — and compare token cost and wall-clock time directly, the way we did above. The numbers usually settle the debate faster than the meeting does.
• ▹Read up on 'embarrassingly parallel' from distributed computing — it predates AI by decades, and the litmus test transfers to agent workloads almost unchanged.
• ▹Come back for Day 3: when multi-agent actually earns its keep — the backlog patterns worth building coordination for, and what that coordination layer should look like once the tax is worth paying.