Agentic AI

Workflows And Multi Agent Systems

Multi-Agent Architectures

NLP Module 8, Chapter 5 introduced orchestrator-worker patterns, and the AI Notes cover classical multi-agent systems. This chapter is about when the architectu

JrCodex·6 min read

Jr Codex Agentic AI Notes

Level: Advanced Prerequisites: Chapter 2: State, Checkpointing & Durability; NLP Notes, Module 8, Chapter 5 Time to complete: ~25 minutes

Table of Contents

  1. The Only Good Reasons
  2. Supervisor-Worker
  3. Hierarchical Teams
  4. Debate and Peer Review
  5. The Blackboard Pattern
  6. Choosing an Architecture
  7. Summary & Next Steps

1. The Only Good Reasons

NLP Module 8, Chapter 5 introduced orchestrator-worker patterns, and the AI Notes cover classical multi-agent systems. This chapter is about when the architecture actually pays.

The Three Legitimate Reasons
─────────────────────────────────────────
  1. CONTEXT ISOLATION
     Each agent needs a different, large context
     that would not co-exist in one window.
     The strongest reason by far.

  2. TOOL SET SIZE
     One agent would need 40 tools; selection
     accuracy collapses past ~20 (Module 2, Ch.3).
     Split by domain.

  3. GENUINE PARALLELISM
     Independent sub-tasks that can run at the same
     time, each needing multi-step reasoning.
─────────────────────────────────────────

The Bad Reasons — All Common
─────────────────────────────────────────
  ✗ "Specialised personas produce better output."
    Marginal at best. A good prompt does this
    within one agent.

  ✗ "It mirrors how our team is organised."
    Your org chart is a solution to HUMAN
    constraints — bandwidth, expertise, politics.
    None of those apply here.

  ✗ "More agents means more intelligence."
    More agents means more coordination overhead
    and more places to fail. Chapter 5.
─────────────────────────────────────────

2. Supervisor-Worker

The default and, in most cases, the correct multi-agent architecture.

The Structure
─────────────────────────────────────────
              ┌────────────┐
    task ────►│ SUPERVISOR │
              └─────┬──────┘
         ┌──────────┼──────────┐
         ▼          ▼          ▼
     worker A   worker B   worker C
      (docs)     (data)     (web)
         │          │          │
         └──────────┼──────────┘
                    ▼
              SUPERVISOR
              synthesises
─────────────────────────────────────────

class Supervisor:
    def __init__(self, client, workers): self.client, self.workers = client, workers
 
    def run(self, task, max_delegations=6):
        state = {"task": task, "results": {}, "delegations": 0}
 
        while state["delegations"] < max_delegations:
            decision = self.decide(state)                  # which worker, or done?
            if decision.done:
                return self.synthesise(state)
 
            worker = self.workers[decision.worker]
            result = worker.run(decision.subtask)          # worker has its OWN context
            state["results"][decision.worker] = summarise(result)   # SUMMARY only
            state["delegations"] += 1
 
        return self.synthesise(state)                      # bounded — Module 4, Ch.4
The Detail That Makes It Work
─────────────────────────────────────────
  The supervisor receives a SUMMARY of each worker's
  result, never the worker's full transcript.

  That is the entire point. Worker A may burn 30,000
  tokens researching and return 300 tokens of
  findings. The supervisor stays clean and can
  coordinate ten workers within one context.

  A supervisor that ingests full worker transcripts
  has all the cost of multi-agent and none of the
  benefit.
─────────────────────────────────────────

3. Hierarchical Teams

Supervisors of supervisors, for genuinely large tasks.

The Structure
─────────────────────────────────────────
                 EXECUTIVE
                     │
        ┌────────────┴────────────┐
        ▼                         ▼
   RESEARCH LEAD            ANALYSIS LEAD
        │                         │
   ┌────┴────┐               ┌────┴────┐
   ▼         ▼               ▼         ▼
 web       docs           stats     modelling
─────────────────────────────────────────

The Cost of Each Layer
─────────────────────────────────────────
  Every layer adds a summarisation step, and every
  summarisation LOSES information.

  By the time a leaf agent's finding reaches the
  executive, it has been compressed twice. Nuance,
  caveats and uncertainty are exactly what
  summarisation drops first.

  TWO LEVELS is almost always the practical limit.
  Three is usually a sign the task should have been
  split into separate runs.
─────────────────────────────────────────

4. Debate and Peer Review

Several agents produce or critique independently, then reconcile.

async def debate(client, question, personas, rounds=2):
    positions = await asyncio.gather(*[                    # INDEPENDENT first — no anchoring
        argue(client, question, persona=p) for p in personas
    ])
 
    for _ in range(rounds):
        critiques = await asyncio.gather(*[
            critique(client, question, own=p, others=[o for o in positions if o is not p])
            for p in positions
        ])
        positions = await asyncio.gather(*[
            revise(client, p, c) for p, c in zip(positions, critiques)
        ])
 
    return await judge(client, question, positions)        # a separate arbiter decides
When Debate Genuinely Helps
─────────────────────────────────────────
  HELPS      questions with real competing
             considerations — a design trade-off, a
             risk assessment, an ambiguous
             classification. Surfacing the
             disagreement IS the value.

  DOES NOT   factual questions. Three agents
             debating a database value produces
             three guesses and a vote. Query the
             database.
─────────────────────────────────────────

The Independence Requirement
─────────────────────────────────────────
  Generate the initial positions IN PARALLEL,
  without letting agents see each other's work.

  Sequential debate ANCHORS: agent two largely
  agrees with agent one, agent three with both, and
  you have paid for three agents to produce one
  opinion.
─────────────────────────────────────────

5. The Blackboard Pattern

A shared workspace that any agent may read from and write to, with no fixed control flow.

class Blackboard:
    """Shared state; agents contribute when their preconditions are met."""
 
    def __init__(self): self.entries, self.version = {}, 0
 
    def write(self, key, value, by):
        self.entries[key] = {"value": value, "by": by, "at": time.time()}
        self.version += 1
 
    def read(self, key): return self.entries.get(key, {}).get("value")
 
async def blackboard_run(agents, board, goal, max_rounds=8):
    for _ in range(max_rounds):
        before = board.version
        for agent in agents:
            if agent.can_contribute(board):                # a PRECONDITION check
                await agent.contribute(board)
        if board.version == before:                        # nobody could add anything
            break                                          # ── the natural stopping point
    return board
Strengths and the Catch
─────────────────────────────────────────
  STRENGTH   genuinely flexible. Agents contribute
             opportunistically as information
             becomes available, in no fixed order.

  CATCH      hard to bound, hard to debug, and the
             stopping condition is subtle. It is the
             least predictable pattern here.

  Use it for open-ended exploratory problems where
  you cannot specify the order in advance. Do not
  use it where a supervisor would do — which is most
  of the time.
─────────────────────────────────────────

6. Choosing an Architecture

Decision Guide
─────────────────────────────────────────
  Clear sub-tasks, one coordinator
      ──► SUPERVISOR-WORKER. The default. Start here.

  Very large task, sub-tasks that themselves
  decompose
      ──► HIERARCHICAL, two levels maximum.

  A judgement call with real competing views
      ──► DEBATE, with independent first positions.

  Exploratory, order genuinely unknowable in advance
      ──► BLACKBOARD, and bound it carefully.

  You are unsure which applies
      ──► ONE agent with all the tools. Measure it.
          Then read Chapter 5.
─────────────────────────────────────────

Test the Baseline First
─────────────────────────────────────────
  Before building any of these, run the single-agent
  version and record quality, cost and latency
  (Module 7).

  Multi-agent must BEAT that baseline, not merely
  work. Teams routinely ship a multi-agent system
  that is slower, costlier and no better — because
  nobody measured the alternative.
─────────────────────────────────────────

7. Summary & Next Steps

Key Takeaways

  • The three legitimate reasons for multi-agent are context isolation, tool-set size and genuine parallelism; personas and org-chart mirroring are not among them.
  • Supervisor-worker is the default, and it works because the supervisor sees summaries rather than full worker transcripts.
  • Every hierarchy layer adds a lossy summarisation, so two levels is the practical limit.
  • Debate helps on genuine trade-offs and not on factual questions, and its initial positions must be generated independently or the agents simply anchor on each other.

Concept Check

  1. What exactly does a supervisor gain by receiving summaries instead of full worker transcripts?
  2. Why is a three-level hierarchy usually a design smell?
  3. Why must debate positions be generated in parallel rather than sequentially?

Next Chapter

→ Chapter 4: Agent Communication

Jr Codex — 1-on-1 Personalized Coaching | Back to Module Index | Back to Agentic AI Index