Multi-Agent Topologies

Overview

Section 1 built one bounded agent with a surface you can police. Sooner or later somebody proposes several.

Sometimes they are right. This topic covers the arrangements and the three reasons that actually justify one; the next covers the bill, which is why the answer is usually still one.

Three arrangements

Supervisor and worker. One agent holds the goal, decomposes it, delegates narrow subtasks, and assembles the results. The plan lives in one place, which means there is one place to audit and one place to gate. This is the most common arrangement and the most defensible.

Peers. Several agents work against shared state with no hierarchy. The appeal is flexibility; the problem is that no single component holds the plan, so there is nowhere to review what the system intends to do. For consequential work this is close to disqualifying — Section 1 spent a whole topic establishing that a reviewable plan is where oversight attaches.

Critic. One agent produces, a second attacks the output. This is the one arrangement where a second agent adds something a single loop cannot: genuine independence. But it only works if the critic has different information or a different objective. A critic running the same model on the same context with the same instructions is Reflexion with extra latency, and the previous section already explained why that converges confidently rather than correctly.

Why do you want a second agent?

graph TD
  Q{"Why a second<br/>agent?"} -->|"independent subtasks,<br/>no shared state"| P["<b>Parallelism</b><br/>wins wall-clock,<br/>not quality"]
  Q -->|"a reading-heavy subtask<br/>would fill the main<br/>loop's context"| I["<b>Context isolation</b><br/>worker reads,<br/>returns a conclusion"]
  Q -->|"planning needs judgement,<br/>bulk work does not"| C["<b>Role differentiation</b><br/>capable planner,<br/>cheap worker"]
  Q -->|"it seems more<br/>sophisticated"| N["<b>No</b><br/>one bounded agent"]

  classDef gate fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef ok fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef best fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef no fill:#D8D3CB,stroke:#B8B2A8,stroke-width:2px,color:#3F3F3F
  class Q gate
  class P,C ok
  class I best
  class N no

Three legitimate reasons and one that is not. The amber leaf is the strongest architectural case, and it is the one that gets proposed least.

Parallelism applies when subtasks are genuinely independent — several sources to consult, several records to process, nothing shared between them. The win is wall-clock time. It is not a quality win, and pretending otherwise is how multi-agent gets oversold.

Context isolation is the strongest case and deserves more attention than it gets. Some subtasks require reading a great deal of material to produce a small conclusion. Done inline, the raw material lands in the main loop’s context and stays there, crowding out everything else for the rest of the interaction. Done by a worker, the material is read somewhere else and only the conclusion comes back. The main loop never sees it.

Role differentiation assigns a capable model to judgement and a cheaper one to bulk work. There is a non-obvious architectural reason to do this as delegation rather than by switching models inline: caches are scoped to a model, as Module 4 established, so changing model mid-interaction discards the cached prefix you have been paying to maintain. A worker running a different model keeps the main loop on one model and one warm cache. That is a cache-driven argument for delegation, and it is the kind of reasoning that does not appear in any diagram.

Start with copies of yourself

The cheapest way into delegation, and the one to try first: delegate to another instance of the same agent — same model, same tool surface, narrower task and its own context.

You get context isolation, which is the main prize, without acquiring a second thing to configure, version, evaluate and debug. If that works, you have solved the problem. If it demonstrably does not, you now have evidence for introducing a differently-configured worker, which is a much better position than starting there.

The sequence matters because each step adds a component with its own failure modes, and the first step gets you most of the benefit.

What the arrangements cost in oversight

Worth flagging before the next topic, because it is an oversight question rather than a cost question.

Section 1 built an action boundary: tenant scope from the session, allowlists, confirmation gates, idempotency keys issued by your code. Every one of those must hold for every agent that can reach a tool. A worker with its own tool access is a second place where the boundary must be enforced, and the failure mode is a worker that was given broader reach than the supervisor because nobody wrote down that it needed the same constraints.

The design rule: tool access is granted per agent, and the narrower agent gets the narrower surface. A worker that reads should not hold credentials that can act. This follows directly from least privilege, and it is routinely violated by giving every agent the same tool list for convenience.

Rejected, with one place it might later earn its keep

Multi-agent is explicitly rejected for the action path, and the reasoning is in the next topic’s arithmetic rather than in preference.

The action loop does one thing: establish what should change, confirm if required, make the change, verify it. The steps are sequential and dependent — there is no parallelism to exploit, the context is small, and the judgement all sits in one place. A supervisor delegating “call the reschedule API” to a worker would add a coordination boundary around a single API call.

Where it might genuinely earn its place: searching the historical ticket corpus. That is reading-heavy by construction — a query may touch many conversations to establish whether a similar problem has been resolved before, and none of that raw material is needed once the conclusion is drawn. Done inline, it floods the loop’s context with other customers’ redacted tickets for the remainder of the interaction. Done by a worker that reads and returns “three similar cases; all resolved by resetting the device; none required a credit”, the main loop stays clean.

That worker would be a copy of the same agent with a narrower tool surface — documentation and ticket search only, no action tools, read-only credentials, tenant scope asserted identically.

The reconsideration trigger, in Module 3’s bet format: introduce the search worker if context measurements show ticket-corpus retrieval consuming enough of the window to degrade later steps in the same interaction — and not before, since the single-agent baseline is what any multi-agent design must beat.

Feeds the workbook

The rubric requires that multi-agent is either justified against coordination cost or explicitly rejected. Either is a pass; silence is not. Name the reason from the diagram if you adopt it, and name the measurement that would change your mind if you reject it.

Check your understanding

1. Which of the three legitimate reasons, if any, applies to the case system? What measurement would confirm it?
2. A proposed worker is given the same tool list as the supervisor “for simplicity”. What is the specific risk, and what is the fix?
3. A critic agent is proposed to check the action plan. What would it need in order not to be Reflexion with extra latency?

---

→ Three good reasons exist. Here is the bill that usually outweighs all of them. — The coordination cost