6.2.6 · D2AI Agents & Tool Use

Visual walkthrough — Multi-agent collaboration

1,931 words9 min readBack to topic

Before any symbol appears, agree on words:


Step 1 — Draw the task as a pile of skills

WHAT. Picture the whole job (short for Task) as a box that demands a set of skills. We write that set as

Read it term by term:

  • — the capabilities the task needs, the full pile.
  • — individual skills, one lego brick each ("search", "code", "test").
  • — how many bricks. Bigger = harder, broader job.
  • The curly braces just mean "a set — a collection with no repeats".

WHY. We cannot compare "one agent" to "many agents" until we say what work exists to be done. The skill-pile is that fixed amount of work. Nothing on this page changes ; we only change who carries which bricks.

PICTURE. Four coloured bricks stacked inside the task box — that stack is .

Figure — Multi-agent collaboration

Step 2 — The single agent must swallow the whole pile

WHAT. One agent can only do the task if it owns every skill:

Term by term:

  • — our one lonely agent.
  • — the set of skills actually has.
  • — "is a superset of", i.e. "contains at least everything in". So 's skills must cover the whole pile , and maybe more.

WHY the symbol and not ? We only need to have every needed skill; it may know extra useless ones. says exactly "covers, possibly with slack" — a plain would wrongly forbid the extras.

PICTURE. One big agent-circle stretched to wrap around all four bricks. It is straining — that strain is the coming problem.

Figure — Multi-agent collaboration

Step 3 — Why swallowing everything gets expensive fast

WHAT. The cost of the single agent grows as the pile grows. Sketch it as a curve: as (number of skills) rises, rises faster than a straight line — its prompt gets longer, its context window fills, its attention splits, its mistakes multiply.

WHY draw a curve and not a line? A line would mean "each new skill costs the same fixed amount". But a jack-of-all-trades pays a penalty for juggling: skill 5 doesn't just add its own cost, it also makes skills 1–4 harder to keep straight (longer prompt, more confusion). That compounding is why the curve bends upward — it is super-linear.

PICTURE. A cyan curve climbing steeply against amber "number of skills" axis.

Figure — Multi-agent collaboration

Step 4 — Split the pile: give each agent a corner

WHAT. Instead of one agent, cut the pile into chunks and hand one chunk to each agent:

Term by term:

  • — how many agents we use. This is the knob we get to turn.
  • — the chunk of skills given to agent .
  • — "union": glue the chunks back together and you recover the whole pile . No skill is lost.
  • — the "" is "overlap"; is the empty set. So chunks don't overlap: no two agents redo the same work. "(or tiny)" allows a little shared context (they still need to talk).

WHY union and empty-intersection together? Union guarantees coverage (task still fully done); empty intersection guarantees no waste (nobody duplicates effort). Coverage without waste — that is the entire promise of specialization.

PICTURE. The four bricks separated into small circles, one specialist hugging each — no strain now.

Figure — Multi-agent collaboration

Step 5 — Each specialist is cheap — but talking isn't free

WHAT. Now write the bill for the many-agent plan:

Term by term:

  • — the "" (sigma) means "add up". Add the cost of all specialists. Each is small because each has a short, focused prompt (it sits low on the Step-3 curve).
  • — the price of the Messages agents send each other. Coordination is not free: someone has to explain, hand off, ask again.

WHY does this new term appear now and never appeared for the single agent? A lone agent talks only to itself, so . The moment you have two agents, they must exchange information — and that exchange is the tax you pay for splitting the work. Keep this term in mind: it is the reason many agents can lose.

PICTURE. Small cheap specialist-circles, with amber arrows between them labelled "messages = Cost(M)".

Figure — Multi-agent collaboration

Step 6 — Lay both bills side by side: the crossover

WHAT. Multi-agent wins exactly when its bill is smaller: Expand both sides using Steps 3 and 5:

WHY this is the central result. Everything the parent note listed — specialization gain, parallelism, low communication overhead — is just a way of making the left side smaller than the right. Read the picture:

  • The flat-ish line is 's upward-bending curve from Step 3.
  • The many-agent cost has two parts: a falling part (each specialist is cheaper as we add more, because chunks shrink) plus a rising part (more agents = more chatter). Their sum is a U-shaped valley.
  • Where the U dips below the single-agent curve — that shaded band — is where you should go multi-agent.
Figure — Multi-agent collaboration

Step 7 — The degenerate cases (never skip these)

WHAT & WHY & PICTURE, one per case. A derivation is only trustworthy if it survives its extremes. Three matter:

Case (one agent). Then , no one to message, so and the inequality becomes false. Correct! With one agent, "multi-agent" collapses back into "single agent"; there is no win to be had. The math refuses to lie.

Case "skills don't split" ( large). If every chunk needs almost every skill, no agent is really specialized — each is nearly as heavy as — while you still pay . Then always. Lesson: collaboration needs separable work. A tightly-coupled task should stay single-agent.

Case "message tax dominates" ( huge). Even perfect specialists lose if they must renegotiate constantly (think chatty Peer-to-peer Negotiation-style consensus with no clean interface). The valley in Step 6 lifts entirely above the single-agent line — no crossover exists. Lesson: clean interfaces (well-shaped hand-off prompts) are what keep small enough to win.

Figure — Multi-agent collaboration

Step 8 — Time, not just money: why parallel work sharpens the win

WHAT. Cost isn't only tokens — it's also waiting. If the specialists work at the same time, the wall-clock time is not the sum but the slowest one plus the chatter:

Term by term:

  • — "" picks the largest single agent's time. Because they run in parallel, you wait only for the slowest, not for all of them added up.
  • — plus the time spent passing messages.

WHY and not here, when cost used ? Money is spent by every agent whether or not they overlap, so money adds (). Time overlaps when they run together, so you only feel the longest one (). Same system, two different accountants — that distinction is the heart of "parallel with aggregation" from the parent note, closely related to ensembles that also run many models at once.

PICTURE. Five bars (agents) running left-to-right in parallel; the finish line sits at the tip of the longest bar, plus a small amber message tail — versus a long single serial bar.

Figure — Multi-agent collaboration

The one-picture summary

Everything above in a single frame: the rising single-agent curve, the U-shaped multi-agent valley, the sweet-spot band where the U dips below, and the three danger zones flagged in Step 7.

Figure — Multi-agent collaboration
Recall Feynman retelling — say it to a 12-year-old

A big job is a pile of skill-bricks. One robot could carry the whole pile, but the more bricks it juggles the clumsier and slower it gets — its cost curls upward. So we split the pile: give each little robot just one brick. Each little robot is fast and cheap because it only thinks about its one thing. But now the robots have to talk to fit their pieces together, and talking costs something too. If we use just a few robots, the talking is cheap and the specialists are cheap, so the total is way less than the one big robot — that's the valley, that's where we win. If we use too many robots, they spend all day talking and the win vanishes. And if the job can't really be split, or the robots can't get a word in edgewise, one big robot was better all along. That whole trade-off is the tiny line — and now you can see it.

Recall Check yourself

When does multi-agent beat single-agent? ::: When — specialists cheap enough that their sum plus message cost undercuts the one big agent. Why do we add () costs but take the max for time? ::: Money is paid by every agent regardless of overlap, so it adds; parallel agents overlap in time, so you only wait for the slowest (). Give one case where multi-agent must lose. ::: When skills can't be separated (chunks overlap heavily) or when message cost dominates — either lifts the multi-agent valley above the single-agent curve.