Worked examples — Multi-agent collaboration
This page is the "put a number on it" companion to the parent topic. The parent told you why multiple agents beat one big agent; here we actually compute the trade-off in every situation you might meet — cheap coordination, expensive coordination, agents that fail, agents that vote, the limit of infinitely many agents, and an exam-style trap.
Before any example, one promise: every symbol below is defined the first time it appears, in plain words, and tied to a picture.
The scenario matrix
The core question of this whole topic is a cost comparison:
Every real situation is one cell in this matrix. We will hit all of them.
| Cell | Case class | What's extreme about it | Example |
|---|---|---|---|
| A | Cheap talk, good split | tiny, specialists much cheaper | Ex 1 |
| B | Expensive talk (chatty agents) | dominates → multi loses | Ex 2 |
| C | Zero split () — degenerate | Multi collapses back to single | Ex 3 |
| D | Parallel latency (wall-clock, not tokens) | Time is , not sum | Ex 4 |
| E | Majority voting with a wrong minority | Robustness math (odd ) | Ex 5 |
| F | Sequential pipeline error propagation | One weak stage kills the chain | Ex 6 |
| G | Limiting value: agents | Coordination cost blows up | Ex 7 |
| H | Real-world word problem (dollars + time) | Combine token cost and latency | Ex 8 |
| I | Exam twist: overlapping capabilities | The trap | Ex 9 |
The figure below is not a summary picture — it is the tool you place each example onto as you go. Every example ends by telling you which point on this curve it is; keep the figure open beside the examples and mark them off.

Reading it (we will return to it example by example): the horizontal axis is , the number of agents. The blue curve is the doing-work cost from Ex 7 — it falls as you split. The pink curve is the pairwise talk cost — it rises as agents multiply. The yellow curve is their sum, and its lowest point (the white dot) is the sweet spot number of agents. Ex 3 sits at the far left (), Ex 7 walks you along the whole curve, and Ex 1 vs Ex 2 are the same with the pink curve shifted up.
Example 1 — Cell A: cheap talk, clean split
Forecast: Guess now — will the 30 units of chatter ruin the deal, or is still comfortably under 300?
- Add up the doing-work cost. . Why this step? This is the first term of — the productive spend before anyone talks.
- Add the talk cost. , so . Why this step? Coordination is never free; we must include or we'd cheat in multi-agent's favour.
- Compare. . Multi-agent wins by units. Why this step? The whole decision is this one inequality from the matrix.
Verify: Specialization saving alone is units; we "spend back" on talk, netting . Both routes give . ✓ On the s01 figure this sits at small on the left, where the yellow total curve is still falling — a healthy net gain.
Example 2 — Cell B: chatty agents (multi loses)
Forecast: The doing-work part is identical to Ex 1. Only the talk changed. Does 150 units of chatter flip the verdict?
- Total multi cost. . Why this step? Same formula; only grew.
- Compare. . Multi-agent loses by units. Why this step? This is the parent's warning made concrete — "communication overhead must not dominate."
Verify: Break-even talk budget is . We spent , so we overshot by exactly , matching the -unit loss. ✓ On the s01 figure this is the same as Ex 1 but with the pink talk curve pushed up so high that the yellow total has climbed back above the single-agent line.
Example 3 — Cell C: the degenerate
Forecast: With one agent, is literally equal to ?
- Sum with a single term. . Why this step? A sum with one element is just that element — check the boundary of the formula.
- Talk cost with no partners. . Why this step? Messages require at least two parties; forces .
- Total. . Why this step? Confirms multi-agent gracefully degenerates into single-agent — no contradiction, no free lunch.
Verify: ; the inequality is false (not strict). Correct: at there is nothing to gain. ✓ On the s01 figure this is the far-left endpoint () of the yellow curve, the marked "k=1 : Ex3" point.
Example 4 — Cell D: latency is a max, not a sum
Forecast: Sequential is . Parallel should be much less — but which number governs it, the biggest reader or the total?
- Sequential time (tokens-style sum). minutes. Why this step? If one agent read them one after another, times add.
- Parallel time uses the slowest. Using the exact parallel-time rule from the definition above, Why this step? Everyone starts together; you're done only when the slowest finishes — that's why it's a , not a sum. This is an equality, not an approximation, because the readers genuinely run at once and the message pass happens once at the end. The straggler sets the pace.
- Speed-up. faster. Why this step? Quantifies the benefit of parallelism separately from token cost. (Here the is honest: is not a round number, so we round the ratio to two decimals.)
Verify: The bottleneck is the 12-minute reader; . Speed-up Rounding to 2 d.p. gives . ✓ On the s01 figure, this example lives on the time story, not the cost curves — but it is the reason the blue "doing-work" curve is worth chasing at all: without parallelism you'd pay the sum (31), with it you pay only the max-block (14). Keep it in mind as the hidden time-axis behind every on the plot.
Example 5 — Cell E: majority voting with a wrong minority
Before we count votes, define the three symbols the voting rule uses.
Forecast: One agent disagrees. Does majority voting rescue us? How decisive is the vote, and how many more could have gone wrong before we'd be in danger?
- Count votes. For candidate : . For : the sum is . Why this step? This is the inner sum of the rule — each switch fires only when an agent's answer matches the candidate.
- Pick the winner. keeps the candidate with the bigger count: , so . Why this step? returns the input answer, not the count — that's the majority answer.
- Vote gap. votes — a decisive result this time. Why this step? Tells us how comfortably 42 won the actual ballot.
- Fault tolerance (a separate number). With , agents could be wrong and 42 would still hold the majority. Only 1 was wrong here, safely under the limit. Why this step? This is the design guarantee of odd — independent of today's ballot — and it is a different quantity from the vote gap in step 3.
Verify: Total votes . ✓ Vote gap ; fault tolerance ; these two numbers are deliberately different (3 ≠ 2) and mean different things. ✓ This example doesn't sit on the s01 cost/time curves at all — it is a robustness axis orthogonal to them, and that is exactly why parallel-with-voting (Ex 5) buys reliability that the pure cost curve of s01 cannot show.
Example 6 — Cell F: sequential pipeline error propagation
Forecast: Each stage is a strong 0.9. Four of them — is the chain still "pretty good", or does it quietly rot below 70%?
- Independence multiplies. . Why this step? Independent successes multiply; the pipeline is a chain of "AND" conditions, so one failure anywhere breaks it.
- Compute. , i.e. about 65.6%. Why this step? Turns the abstract "error propagates" warning into a number.
- Interpret. Chance of at least one failure = . Why this step? Shows a 4-stage chain fails a third of the time despite each part being "reliable".
Verify: exactly; and . ✓ This is why the parent flags pipelines as "error-propagation" risky. On the s01 figure, a long pipeline corresponds to large (many stages) — the same region where the yellow curve is climbing — so both cost and reliability push back against over-splitting.
Example 7 — Cell G: the limit
Forecast: Splitting more should keep cutting the work cost — but pairwise messages grow like . Which force wins as grows huge?
- Write the total. . Why this step? One falling term (work) plus one exploding term (talk) — exactly the tension drawn as the blue and pink curves on the s01 figure.
- Plug . . Why this step? We sample a small near the left of the s01 curve, where the falling work term (90) still dominates the tiny talk term (1) — the yellow curve is high but heading down.
- Plug . . Why this step? We sample near the middle, close to the white "sweet spot" dot on s01, where work (30) and talk (15) are roughly balanced and the total is at its lowest — this is the cheapest configuration.
- Plug . . Why this step? We sample a large on the right of s01, where the tiny work term (9) is drowned by the exploding talk term (190) — the yellow curve has shot back up, showing over-splitting is wasteful.
- Limit. As , the term but , so . Why this step? Proves "more agents" is not monotonically better — pairwise coordination eventually dominates, which is the upward-sweeping right tail of the yellow curve on s01.
Verify: , , as computed; the sequence dips then climbs (), confirming a minimum between and , matching the yellow-curve valley and the white sweet-spot dot in the s01 figure. ✓
Example 8 — Cell H: real-world word problem (dollars and time)
Forecast: Seven agents at 5 cents each is 35 cents — close to 40. Will multi-agent win on both money and time, or trade one for the other?
- Dollar cost, multi. 7 \times 0.05 + 0.03 = 0.35 + 0.03 = \0.38$. Why this step? Dollars follow the Cost rule — they sum over all 7 agents plus messaging. Parallelism does not reduce token spend.
- Compare dollars. . Multi-agent cheaper by $0.02. Why this step? Small but real; the split barely pays for the extra messaging.
- Time, multi. Here the searcher runs before and the synthesizer after, so their times add, but the 5 readers overlap, so we take their : minutes. Why this step? Time follows the Time rule: over the parallel reader block, plus the sequential searcher, synthesizer and message pass.
- Compare time. , so multi is faster. Why this step? Time uses max for the parallel block (Ex 4's lesson) — that's where the huge speed-up hides.
Verify: Dollars: vs , saving . ✓ Time: ; . ✓ Multi wins on both axes here. On the s01 figure this is a modest () still on the falling/left side of the yellow curve — cheap enough that the split pays off, exactly as the plot predicts.
Example 9 — Cell I: the exam twist (overlapping capabilities)
Forecast: The split "looks" 50 units better. But overlap breeds conflict. Does the 40-unit conflict tax swallow most of the gain, or flip the verdict entirely?
- Identify the overlap. — this violates the clean-partition assumption from the parent. Why this step? The whole efficiency argument assumed minimal overlap; spotting the violation is the exam's real question.
- Add the conflict tax to . The effective coordination cost rises by 40 units, because resolving a conflict is an exchange of messages. Why this step? Conflict resolution belongs in the talk term , not somewhere magical — it is extra communication forced by the overlap.
- Net verdict. Intended saving conflict tax units net gain. So multi-agent still wins — but only barely, and the margin is fragile: any more overlap (a bigger tax) would erase it. Why this step? Shows the overlap did not reverse the verdict here, but nearly did — which is exactly the danger the "minimal overlap" rule guards against.
Verify: , so the strict win still holds (thinly). Had the tax been , the net would be and multi-agent would tie or lose — precisely the failure mode the "minimal overlap" rule prevents. ✓ On the s01 figure, the conflict tax acts like adding to the pink talk curve — pushing the whole yellow total up and shrinking the winning region.
Recall Why do we insist
be minimal? Overlap ::: creates conflicting actions between agents, and resolving those conflicts adds to , eating the specialization saving.
Wrap-up: where each example sits on the curve
Links: Multi-agent collaboration · 6.2.05-Agent-tool-use · Ensemble-methods (Ex 5 voting) · Distributed-systems (Ex 4, Ex 7 coordination) · Game-theory (Ex 9 conflict) · 6.2.02-Perception-action-cycle · 6.3.01-Prompt-engineering-for-agents.