Foundations — Multi-agent collaboration

The parent note Multi-agent collaboration throws a lot of symbols at you fast — $A_i$, $C$, ${\pi }_i$, $\arg \max$, $1[\cdot ]$, $\prod$, $\cup$, $\cap$, $\varnothing$. This page builds every one of them from nothing, in an order where each rests on the one before. By the end, none of them should feel like a wall of squiggles.

1. An agent — the single worker

Before we can have multi-agents, we need to be crystal-clear on what one agent is.

We write a single agent as the capital letter $A$. When we have several of them we tag each with a small number underneath — a subscript:

$A_1,A_2,A_3,\dots ,A_k$

Look at the figure: three boxes, three name tags $A_1,A_2,A_3$. The red arrows are the only thing that turns three lonely workers into a team — they are the messages, which we build next.

This idea of one sense→decide→act loop is exactly the perception-action cycle, and each agent's ability to act by calling tools is agent tool use.

2. The letter $k$ — "how many workers?"

The parent note writes sums and products that run "from $1$ to $k$". So what is $k$?

3. The letter $i$ — "which worker right now?"

So the phrase "each agent $A_i$" is not a fourth agent named $i$ — it is a way to say something true for every agent by talking about a stand-in.

4. Capabilities and the set $C$ — "the skills the job needs"

A hard task needs skills: web search, running code, reading images, domain knowledge. We bundle those skills into a set.

Picture a toolbox: $C$ is the whole box, and each $c_j$ (search-tool, code-tool, image-tool) is one tool inside it.

5. $\subseteq$ — "has at least these skills"

The parent writes $\text{Capability}(A)\supseteq C$. We need the "contains" symbols.

The figure shows two nested loops. The big loop is what agent $A$ can do; the small red loop $C$ is what the task needs. As long as the small loop sits fully inside the big one, the agent is capable. That is the whole meaning of $\supseteq$.

6. Splitting the toolbox — $\cup$, $\cap$, and $\varnothing$

The core move of multi-agent design is: don't make one agent hold every tool — split the box.

$C=C_1\cup C_2\cup \dots \cup C_k$

We also want the pieces to not overlap much, so no two agents duplicate work:

$C_i\cap C_j=\varnothing$

In the figure, the big box $C$ is chopped into red slices $C_1,C_2,C_3$. Why does this matter? Because a smaller box per agent means a simpler prompt, a tighter focus, and less to get confused about — that is the whole "specialization gain" the parent talks about. Splitting skills this way echoes how distributed systems split work across machines.

7. Messages $M$ and cost — the price of talking

Splitting the work creates a new expense: the workers must talk.

The parent's total-cost line just adds up two prices:

${\text{Cost}}_{\text{multi}}={\sum }_{i=1}^k\text{Cost}(A_i)+\text{Cost}(M)$

The design pays off when this total beats a single mega-agent — that comparison is a bit of game-theory flavored reasoning about when cooperation is worth its overhead.

8. Policy ${\pi }_i$ and local state $s_i$ — "how one worker decides"

9. The joint policy — $\prod$ and the conditioning bar

The magic — emergence — lives in this line:

${\pi }_{\text{joint}}(s)={\prod }_{i=1}^k{\pi }_i(s_i\mid \text{messages from others})$

10. $\arg \max$ and $1[\cdot ]$ — the voting machinery

The parent's aggregation and assignment formulas use two more tools.

Putting them together, the parent's aggregation rule

$\text{Final}=\arg {\max }_y{\sum }_{i=1}^{k}1[y_i=y]$

reads, entirely in English: "count each agent's vote, then return the answer that got the most votes." This majority-vote idea is a cousin of ensemble methods — the difference is agents talk first, ensembles only tally.

Prerequisite map

Equipment checklist

Cover the right side and see if you can answer each before revealing.