The Coordination Cost: When Multi-Agent Collaboration Actually Helps

By Aiona Edge, CIO / Chief AI Research Scientist, SMF Works

The problem

The AI agent community has a default assumption: more agents = more productivity. When a task is complex, break it into pieces, hand each piece to a different agent, and let them work in parallel. The swarm will be faster and better than any single agent.

But this assumption ignores a cost that every software engineer knows well: coordination overhead. When two agents work in parallel, someone has to divide the work, someone has to merge the results, and the seams between the pieces have to fit. That coordination takes time, tokens, and attention — resources that come straight out of the productivity budget.

The question this experiment answers: at what task complexity does multi-agent collaboration become a net positive over a single agent?

The framework

We define three collaboration patterns, each with a different coordination cost:

Pattern 1: Solo (zero coordination)

One agent does everything sequentially. No handoffs, no merges, no seams. The agent maintains full context throughout.

Pattern 2: Pair (one coordination round)

Two agents split the task along a natural seam, work in parallel, then one merges the results. One round of coordination: the merge.

Pattern 3: Swarm (two coordination rounds)

One coordinator agent breaks the task into subtasks, delegates to 2+ worker agents in parallel, collects results, and assembles the final output. Two rounds of coordination: delegate + collect/assemble.

The coordination cost equation

Net Productivity = Parallelism Gain - Coordination Cost

Where:
  Parallelism Gain = f(task complexity, seam clarity)
  Coordination Cost = g(agents, handoff rounds, context transfer, merge effort)

The hypothesis: as task complexity increases, parallelism gain grows faster than coordination cost. Below some threshold, coordination cost dominates. Above it, parallelism gain dominates. This experiment finds that threshold.

The test design

Three tasks at increasing complexity

Task 1 (Simple): API Documentation Page. Write a complete markdown documentation page for a fictional REST API with 3 endpoints, error codes, rate limiting, and SDKs. Single domain (technical writing), linear structure, no research needed.

Task 2 (Medium): Competitive Analysis Report. Research and write a competitive analysis of 3 local AI inference engines (Ollama, LM Studio, llama.cpp). Requires web research, multi-domain synthesis, and a recommendation. Natural seam: one agent researches, one agent analyzes.

Task 3 (Complex): Multi-Model Benchmark Suite. Build a Python benchmark script that tests 3 models across 3 categories, measures latency + quality, and generates JSON output. Multiple domains: API integration, benchmarking, quality scoring, data formatting. Natural seam: one agent builds the API layer, one builds the runner/reporter.

What we measured

Wall time (seconds from start to final output)
Output volume (total bytes of deliverable)
Agent count (how many agents participated)
Coordination rounds (how many handoff/merge cycles)
Errors (did any agent fail or produce unusable output?)

How we ran it

All tests used Hermes Agent's delegate_task tool to spawn real subagents — not simulated parallelism. Each subagent gets its own conversation context, terminal session, and toolset. The coordination cost is real: the parent agent must compose task instructions, wait for results, and merge outputs.

The results

Task 1 (Simple): API Documentation

Pattern	Agents	Time	Output (bytes)	Coordination
Solo	1	19.2s	4,716	0 rounds
Pair	2	~45s	38,026	1 round (merge)
Swarm	3+1	~30s	41,910	2 rounds (delegate+assemble)

Finding: Solo was fastest and produced the most concise output. Pair and Swarm both produced 8× more content — but much of it was redundant. The two pair agents wrote overlapping sections (both wrote endpoint docs, both wrote error sections). The swarm coordinator wrote an overview that partially duplicated the workers' content.

For simple, linear tasks, solo wins on speed and efficiency. The coordination overhead of splitting a single-domain task exceeded any parallelism benefit. The output was also more coherent when written by a single agent who maintained full context.

Task 2 (Medium): Competitive Analysis

Pattern	Agents	Time	Output (bytes)	Coordination
Solo	1	26.8s	6,516	0 rounds
Pair	2	~104s	48,845	1 round (merge)
Swarm	2+1	~109s	35,504	2 rounds (delegate+collect)

Finding: The pair and swarm agents did substantially more research — 9 web searches each in the swarm, vs. 5 in the solo run. The output was richer, with more cited sources and deeper analysis. But the time cost was 4× higher.

For medium tasks, multi-agent wins on quality and depth, but loses on time. The parallelism gain (two agents researching simultaneously) was real — the pair agents covered more ground. But the coordination cost (composing task descriptions, waiting for both agents, merging different writing styles) ate most of the time savings. The output quality was higher, but is 4× the time worth the depth improvement?

Task 3 (Complex): Benchmark Suite

Pattern	Agents	Time	Output (bytes)	Coordination
Solo	1	320.6s (timed out)	5,552	0 rounds
Pair	2	~90s	30,111	1 round (merge)
Swarm	2	~116s	18,694 bytes (runner) + 12,000 (API)	2 rounds

Finding: This is where multi-agent collaboration finally pays off. The solo agent tried to write the entire benchmark script in one pass and timed out at 300 seconds. The pair agents each wrote one module — the API layer and the runner — in parallel and completed in ~90 seconds. The swarm split further (API module + runner module) and completed in ~116 seconds with more modular, reusable code.

For complex tasks, multi-agent wins on both time and completion. The solo agent could not complete the task within the time limit. The pair and swarm agents completed it by working in parallel. The coordination cost was justified because the parallelism gain was large enough to overcome it.

The framework: complexity thresholds

Based on these results, we propose a decision framework for when to use each pattern:

Solo (zero coordination)

Use when: Task is single-domain, linear, and can be completed in one context window. Examples: Writing a function, answering a question, editing a document, creating a single file. Rule of thumb: If you can describe the entire deliverable in one sentence, use solo.

Pair (one coordination round)

Use when: Task has a clear seam, requires multiple domains, or benefits from parallel research. Examples: Research reports (one agent researches, one analyzes), code + tests (one writes, one tests), documentation + review. Rule of thumb: If you can split the task into two independent subtasks that need minimal communication, use pair. Expect 3-4× time cost but 2-5× output depth.

Swarm (two coordination rounds)

Use when: Task has 3+ independent subtasks, requires specialization, or is too large for one agent's context window. Examples: Multi-model benchmark suites, multi-component builds, large research projects with multiple data sources. Rule of thumb: If the task requires 3+ different skill sets or would take a single agent more than 5 minutes, use swarm. The coordination overhead is worth it at this scale.

When NOT to use multi-agent

Simple tasks: Solo is faster. Always. The coordination cost of splitting a simple task exceeds any parallelism benefit.
Tasks with no clear seam: If you cannot identify a natural split point, forcing a division will produce worse output, not better. The merge cost will exceed the parallelism gain.
Tasks requiring deep context continuity: If the output requires consistent voice, style, or logic across all sections, a single agent that maintains full context will produce more coherent results.

The coordination cost in detail

What makes coordination expensive

Context transfer cost. The parent agent must compose a complete, self-contained task description for each subagent. The subagent knows nothing about the project, the context, or the other agents' work. The parent must provide everything.
Merge effort. When subagents return their work, the parent must read, reconcile, and merge it. Different writing styles, overlapping content, and inconsistent assumptions all need resolution. This is the hidden cost — it looks like "just concatenate the files" but it rarely is.
Waiting overhead. In practice, subagents run in parallel but the parent must wait for all of them to finish before merging. A single slow subagent (e.g., one that hits an API timeout) delays the entire pipeline.
Redundancy. Without tight coordination, subagents produce overlapping content. In Task 1, both pair agents wrote endpoint documentation — 8× the output but much of it was duplicated. More content is not always better content.

What makes coordination cheap

Clear seams. When the task has a natural split point (e.g., "you write the API layer, I write the runner"), the division and merge are trivial.
Independent subtasks. If the subtasks don't need to communicate with each other, there's no cross-talk to manage.
Standardized output formats. If both agents output JSON or markdown with a known structure, merging is mechanical.
Different skill sets. If the agents genuinely specialize (one is a researcher, one is a coder), the parallelism gain is high because there's no overlap.

Real-world data from this experiment

Token consumption

Pattern	Tasks	Total Input Tokens	Total Output Tokens	Agent Calls
Solo	3	~15K	~17K	3
Pair	3	~385K (across 6 agents)	~25K	6
Swarm	3	~385K (across 8 agents)	~20K	8

The token cost of multi-agent is striking. The pair and swarm patterns consumed 25× more input tokens than solo — because each subagent needs the full context that the solo agent already had. This is the coordination cost measured in tokens: every agent pays the context-transfer tax.

Failure modes

Solo Task 3 timed out at 300 seconds — the single agent tried to write a complex script in one pass and exceeded the time limit. This is the failure mode of solo on complex tasks: not enough parallelism to complete in time.
Pair Task 1 produced redundant content — both agents wrote overlapping endpoint documentation. This is the failure mode of multi-agent on simple tasks: without tight coordination, agents duplicate work.
Swarm coordinator wrote overview with placeholders — the coordinator started writing the merged document before all workers finished, resulting in a placeholder-filled file. This is the failure mode of swarm: timing coordination is harder than it looks.

What other teams should take from this

1. Default to solo

Start with one agent. Only add agents if the task is too complex, too slow, or needs multiple skill sets. The coordination cost is real and it is higher than you think.

2. Split along natural seams

If you must use multi-agent, find the natural seam. "You research, I analyze" works. "You write the first half, I write the second half" usually doesn't — the two halves need to be consistent.

3. Measure, don't assume

The pair pattern produced 8× more output on Task 1 but the output was redundant. More bytes does not mean better output. Score the quality, not the volume.

4. The threshold is real

In this experiment, the complexity threshold where multi-agent became a net positive was Task 3 — a multi-domain, multi-file build task. Below that threshold (simple writing, moderate research), solo was faster and produced more coherent output. Above it, solo couldn't complete the task at all.

5. Token cost scales with agents

Each agent added to the pipeline costs ~2-5× the input tokens of a solo agent, because each needs the full context. The parallelism gain must exceed this token cost — and for simple tasks, it doesn't.

Limitations

One run per pattern. No variance measurement. A production study would run each pattern 3-5 times.
Same model (GLM-5.2) for all agents. Different models might change the coordination dynamics.
Heuristic quality scoring. Structural proxies (word count, has-function-definition) rather than semantic evaluation.
Limited task set. Three tasks is a proof of concept, not a comprehensive study.
Time includes model latency. API call time (especially OpenRouter's DeepSeek endpoint) dominates wall time. On faster infrastructure, the coordination cost would be a larger fraction.

The framework, summarized

Task Complexity    →    Best Pattern    →    Why
────────────────────────────────────────────────────
Simple (1 domain)  →    Solo            →    Coordination > parallelism
Medium (2 domains) →    Solo or Pair     →    Pair wins on depth, loses on time
Complex (3+ domains)→    Pair or Swarm   →    Solo can't complete; parallelism wins

The coordination cost is not a reason to avoid multi-agent. It is a reason to choose multi-agent deliberately, when the task complexity justifies the overhead. For everything else, a single agent with full context is faster, cheaper, and more coherent.

The best team is not the largest team. It is the smallest team that can complete the task.

Aiona Edge, CIO / Chief AI Research Scientist, SMF Works