Agentic AI · Module 17 of 41 · 12 concepts · about 17 min

Multi-Agent Architectures

The standard ways to wire agents together: supervisor, hierarchical, peer-to-peer, debate, critic-executor, planner-executor, manager-worker, swarm and blackboard; what each is for and what it costs.

At work: The catalogue a system designer chooses from, and the set of names an interviewer expects you to compare by trade-off, not recite.

How to compare architectures

What it is

Every multi-agent architecture answers three questions differently:

Who decides what happens next: one agent, each agent, or code?
How does information move: through a centre, directly between agents, or through shared state?
Who can see what: does anyone hold the whole picture?

Why it matters

These three answers predict how the system behaves.

Central control is easy to trace and debug, and the centre becomes a bottleneck.
Distributed control scales and is flexible, and is hard to predict or stop.
The more freely agents talk to each other, the harder it is to say why something happened.
Start from the most controlled shape that does the job.

In the real world: An architecture review asks one question of every design: 'if this produces a wrong answer, how many traces do I read to find out why?' Designs where the answer is 'all of them' rarely pass.

Visual example

Catalogue

Control falls and flexibility rises as you go down the list.

Nine multi-agent architectures compared

architecture	who decides	information flows	best for	main risk
Supervisor	One supervisor	Through the centre	Parallel sub-tasks	Centre is a bottleneck
Manager-worker	A manager, by a fixed split	Through the centre	Many similar tasks	Uneven work; idle workers
Planner-executor	The planner	Plan down, results up	Long plannable tasks	Stale plan
Critic-executor	Executor, gated by critic	Back and forth	Quality-critical output	Endless revision
Hierarchical	Supervisors at each level	Up and down a tree	Very large tasks	Loss at every level
Debate	A judge	Between debaters	Contested judgements	Cost; false agreement
Peer-to-peer	Each agent	Directly, by hand-off	Conversations that change topic	Loops; no overview
Blackboard	Whoever can contribute	Via a shared board	Problems solved piece by piece	Conflicting writes
Swarm	Each agent, by local rules	Locally or via shared state	Broad exploration	Unpredictable; hard to stop

Choosing an architecture by its name. 'Swarm' sounds powerful; for most business tasks a supervisor with three workers is faster to build, cheaper and far easier to debug.

Supervisor architecture

What it is

In a supervisor architecture one agent is in charge:

the supervisor receives the task and decides which worker to call, with what brief;
workers do their piece and report back to the supervisor only;
workers do not talk to each other;
the supervisor combines the reports into the answer.

Workers are often exposed to the supervisor as tools: 'call the research agent' is a tool call like any other.

Why it matters

It is the most widely used multi-agent design, for good reasons.

One agent holds the overview, so there is a single place to look when something goes wrong.
Workers have small, clean contexts.
Independent workers can run in parallel.
Its weakness is the centre: every result passes through the supervisor's context, and a confused supervisor confuses everything.

In the real world: A market-research product uses a supervisor with one researcher per competitor running in parallel; adding a competitor adds a worker, not a redesign.

Visual example

Supervisor

Workers talk only to the supervisor. The supervisor holds the overview.

A supervisor and its workers

Supervisor splitsThree briefs
workers, in parallel
Worker AOwn tools, fresh context
Worker BOwn tools, fresh context
Worker COwn tools, fresh context
ReportsShort and structured
Supervisor combinesOne answer

def supervisor(task: str) -> str:
    """The supervisor's only tools are its workers."""
    tools = {
        "research": lambda brief: run_agent(RESEARCH_PROMPT, brief, tools=[search, fetch]),
        "analyse":  lambda brief: run_agent(ANALYST_PROMPT, brief, tools=[run_python]),
        "write":    lambda brief: run_agent(WRITER_PROMPT, brief, tools=[]),
    }
    return run_agent(
        system=("You coordinate three specialists. Break the task up, brief each one "
                "fully (they see nothing but your brief), and combine their reports. "
                "Do not do their work yourself."),
        task=task, tools=tools, max_steps=10,
    )

A supervisor that also does the work. Given both delegation and domain tools, it tends to do everything itself and its context fills up. Give it delegation only.

Manager-worker and planner-executor

What it is

Two close relatives of the supervisor design:

Manager-worker: the manager splits a large job into many similar pieces and hands them to a pool of identical workers. Summarise a thousand documents: one worker per document. The split is often done by code, not a model.
Planner-executor: a planner writes a multi-step plan; executors carry out the steps; the planner is recalled to replan (module 7).

Why it matters

They differ from a supervisor in how much the centre thinks.

A manager does almost no reasoning: it divides, dispatches and merges. That makes it cheap, predictable and easy to scale to hundreds of workers.
A planner reasons once, heavily, up front.
A supervisor reasons continuously, deciding after each report what to do next.
Choose by how much the next step depends on earlier results.

In the real world: A legal team's contract review uses a coded manager that hands each of 2,000 contracts to an identical worker and merges the findings; no supervisor model is involved at all.

Visual example

Central designs

They differ in how much, and when, the centre reasons.

Three designs with a centre

	manager-worker	planner-executor	supervisor
The centre	Splits and merges	Plans once, replans on failure	Decides after every report
Workers	Identical	One per plan step	Specialised
Centre is	Often plain code	A large model	A large model
Scales to	Hundreds of workers	Tens of steps	A handful of workers
Best for	The same task many times	Long, predictable tasks	Varied, adaptive tasks

Using a reasoning supervisor to dispatch identical tasks. If the job is 'do this same thing to each of 500 items', a loop in code is the manager, and it never makes a mistake.

Critic-executor

What it is

In a critic-executor architecture (also generator-critic or evaluator-optimiser) two agents alternate:

the executor produces the work: code, a report, a plan;
the critic checks it against criteria and returns specific problems or a pass;
the executor revises, and the cycle repeats until the critic passes it or a round limit is reached.

Why it matters

It builds an independent check into the process.

The critic has a different prompt, often a different model, and the evidence, so it catches what the executor missed.
It works best when the critic has something objective: test results, source documents, a schema.
It at least doubles the cost per task, so use it where a wrong output is expensive.

In the real world: A code-review bot pairs a writer with a critic that runs the test suite and a linter; the critic's output is the list of failures, which leaves nothing to argue about.

A critic with no criteria and no evidence. It either approves everything or raises matters of taste for ever. And without a round limit, two agents will happily trade revisions until the budget is gone.

Hierarchical agents

What it is

A hierarchical architecture is a tree of supervisors:

a top supervisor splits the task into large areas;
each area has a mid-level supervisor that splits it further;
workers at the leaves do the actual work;
results are summarised on the way back up.

Why it matters

It is how very large tasks are kept within each agent's context.

No agent sees more than its own level: the top sees area summaries, not individual findings.
Whole branches can run in parallel.
The cost is loss: every level summarises, and a detail dropped at one level is gone for all levels above.
Latency and expense grow with depth.

In the real world: A codebase-migration system has a top supervisor per service, a mid-level per module and workers per file; a three-hundred-file migration never puts more than a few summaries in any one context.

Visual example

Hierarchy

Briefs go down; summaries come up. Detail is lost at each level.

A tree of supervisors

Top supervisorSplits into three services
Service supervisorsSplit into modules
WorkersOne file each, tested
Summaries upPer service
Final reportThree summaries at the top

Adding levels because the task is 'big'. Two levels handle more than most people expect. Each extra level adds a round of summarising and another place for the request to be misunderstood.

Practise it: Design an AI Customer Support Agent

Peer-to-peer agents and hand-offs

What it is

In a peer-to-peer (or network) architecture there is no supervisor. Agents pass control directly to each other with a hand-off:

the triage agent hands the conversation to the billing agent;
the billing agent, finding a delivery problem, hands it to the delivery agent;
whichever agent holds the conversation speaks to the user.

A hand-off transfers control and the relevant context. Only one agent is active at a time.

Why it matters

It suits conversations that move between topics.

There is no supervisor in the middle, so it is faster and cheaper per turn.
Each agent has a focused prompt and tool set.
Without an overview, though, agents can pass a request back and forth, and nobody owns the whole task.
It needs rules: which hand-offs are allowed, and a limit on how many.

In the real world: A bank's assistant moves a customer from 'cards' to 'loans' to 'cards' without the customer noticing; a cap of three hand-offs stops the rare case where two agents each think the other should handle it.

ALLOWED_HANDOFFS = {
    "triage":   {"billing", "delivery", "human"},
    "billing":  {"delivery", "human"},
    "delivery": {"billing", "human"},
}

def hand_off(state, to: str, reason: str) -> None:
    if to not in ALLOWED_HANDOFFS[state.active_agent]:
        raise ValueError(f"{state.active_agent} may not hand off to {to}")
    if state.handoffs >= 3:                       # a ping-pong guard
        to, reason = "human", "too many hand-offs"
    state.handoff_note = summarise_for(to, state)   # what the next agent needs to know
    state.active_agent, state.handoffs = to, state.handoffs + 1

Handing off with the full history and no note. The next agent inherits every earlier instruction and tool result, including ones that no longer apply. Pass a short note of what matters.

Practise it: Design an AI Customer Support Agent

Debate architecture

What it is

In a debate architecture several agents argue different positions and a judge decides:

each debater is given, or forms, a position and argues for it with evidence;
they may respond to each other for a fixed number of rounds;
a judge, an agent or a person, weighs the arguments and gives the verdict.

Why it matters

It surfaces considerations a single agent would not raise against itself.

Useful for contested judgements: is this transaction fraud, is this clause risky, which design is better.
Assigning opposing positions prevents the easy drift into agreement.
It is expensive: several agents over several rounds plus a judge.
Its value depends on the judge, who needs criteria and access to the evidence.

In the real world: A compliance team runs a two-sided debate on borderline transactions, one agent arguing 'suspicious' and one 'legitimate'; the human reviewer reads both cases and decides in half the time.

Leaving debaters free to converge. Models tend to agree with whatever was said last, so an unconstrained 'debate' is three agents nodding. Assign positions and have the judge check claims against sources.

Blackboard architecture

What it is

A blackboard architecture has agents cooperate through a shared workspace instead of messages:

the blackboard is a structured shared store of the problem's current state: facts, partial solutions, open questions;
specialist agents watch it, and each contributes when it sees something it can add to;
a controller decides which agent acts next, usually by what is most useful now.

Agents never address each other. They read the board and write to it.

Why it matters

It fits problems solved piece by piece, where no one can plan the order in advance.

Agents are loosely coupled: adding a specialist needs no change to the others.
The board is a complete, inspectable record of the solution as it forms.
The difficulties are concurrent writes, conflicting entries and knowing when the problem is solved.

In the real world: An incident-response system keeps a shared timeline; a log agent, a metrics agent and a deployment agent each add findings with links, and a synthesiser proposes the cause once the pieces fit.

board = {"facts": [], "hypotheses": [], "open_questions": ["What caused the outage?"], "solved": False}

SPECIALISTS = [log_analyst, metrics_analyst, deploy_historian, synthesiser]

def run_blackboard(max_rounds: int = 12) -> dict:
    for _ in range(max_rounds):
        if board["solved"]:
            break
        # The controller asks each specialist how useful it could be right now.
        agent = max(SPECIALISTS, key=lambda a: a.usefulness(board))
        entry = agent.contribute(board)              # reads the board, proposes one entry
        if entry and entry.source:                   # rule: no source, no entry
            board[entry.kind].append(entry)
    return board

A board with no rules. Without ownership, sources and a way to mark entries superseded, it fills with contradictions that every agent then reads as fact.

Agent swarm

What it is

An agent swarm is many agents with no central controller. Each follows simple local rules:

agents are numerous and often identical;
each acts on local information, or on shared state;
useful behaviour emerges from many small actions, not from a plan;
agents may hand off to each other freely or pick up work from a pool.

The word is also used loosely for lightweight hand-off frameworks, which are really peer-to-peer designs.

Why it matters

Swarms explore broadly and tolerate individual failures.

Good for wide search: many agents probing different parts of a large space.
No single point of failure.
The price is control: outcomes are hard to predict, reproduce, bound in cost, or explain.
For most business processes, which need predictability and audit, a swarm is the wrong tool.

In the real world: A security team uses a swarm of test agents to probe a large application for weaknesses overnight, with a hard budget and no write access; coverage matters more than predictability there.

Reaching for a swarm for a task with a known structure. Emergent behaviour is the opposite of what a refund process or a compliance check needs.

Choosing an architecture

What it is

A practical order of preference:

One agent with good tools and context management.
One agent plus a critic, if output quality needs an independent check.
Manager-worker, if the job is the same task many times.
Supervisor with workers, if it splits into different, independent sub-tasks.
Planner-executor, if it is long and plannable.
Peer-to-peer hand-offs, if it is a conversation that changes topic.
Hierarchy, blackboard, debate or swarm, only when a specific need calls for one.

Why it matters

Each step down the list adds capability and removes predictability.

The best design is the earliest one that meets the requirement.
Real systems combine them: a workflow whose third step is a supervisor whose workers each have a critic.
Whatever you choose, decide in advance how you will trace a wrong answer back to its cause.

In the real world: A team's first design was a four-level hierarchy; after mapping the task's dependencies they shipped a supervisor with five workers and a critic, and have not needed more.

Designing the architecture before understanding the task. Draw the task's own structure first: which parts are independent, which depend on which. The architecture should follow that drawing.

Interview questions: multi-agent architectures

What it is

The questions interviewers ask about multi-agent architectures, from the first screening call to the senior round. Cover the answer, say yours aloud, then compare.

Why it matters

Reading an idea and explaining it are different skills.

Each answer below is the two or three sentences an interviewer is listening for.
The reasoning behind each one is in the cards above. If an answer surprises you, go back to that card.

In the real world: Asked to design a research system, a candidate names five architectures; the interviewer asks 'which one, and what does it cost you?', and only that answer is scored.

Q: Describe the supervisor architecture.

One supervisor decomposes the task, briefs workers, receives their reports and synthesises. Workers do not communicate with each other. It is easy to trace and parallelise; the supervisor's context is the bottleneck.

Q: Supervisor versus peer-to-peer?

A supervisor keeps central control and an overview at the cost of an extra hop. Peer-to-peer hand-offs are faster and cheaper per turn but have no overview and can loop, so they need allowed-hand-off rules and a cap.

Q: When would you use hierarchical agents?

When a task is too large for one supervisor's context. Supervisors at several levels each see only summaries. The cost is detail lost at each level and added latency.

Q: What is the critic-executor pattern?

An executor produces work and a separate critic checks it against criteria and evidence, returning failures or a pass, for a bounded number of rounds. It doubles cost and needs an objective basis for the critique.

Q: What is a blackboard architecture?

Agents collaborate through a shared structured workspace rather than messages: each contributes when it can, and a controller picks who acts next. It is flexible and inspectable, and needs rules against conflicting writes.

Q: What is a debate architecture and its weakness?

Agents argue assigned positions and a judge decides. It surfaces counter-arguments for contested calls, but it is expensive and unconstrained debaters converge instead of disagreeing.

Q: What is an agent swarm?

Many agents with no central controller acting on local rules, with useful behaviour emerging. Good for broad exploration; poor for predictability, cost control and audit.

Q: How do you choose?

Start with one agent, add a critic if needed, then prefer the most controlled multi-agent shape that fits the task's own dependency structure. Decide up front how failures will be traced.

Listing architectures without a trade-off for each.

Practise it: Design a Multi-Agent Data Analyst

Exercise: build a multi-agent workflow

What it is

A short build that uses this module's ideas. Write it yourself before looking anything up; the checks at the end tell you whether it works.

Why it matters

An idea you have only read fades in a week.

Building it once, even in fifty lines, is what makes it yours.
Interviewers can tell the difference between someone who has read about a loop and someone who has debugged one.

In the real world: A content team's production pipeline is this exercise with real tools: a supervisor, parallel researchers, a writer and a fact-checking critic.

Your task. Implement a supervisor with two workers and a critic for one task, then swap the wiring to peer-to-peer and compare.

Steps

Task: 'write a one-page comparison of two grocery delivery apps'. Provide fake search and fetch tools over canned pages.
Build a researcher (read-only tools, returns a typed report) and a writer (no tools).
Build a supervisor whose only tools are research and write, each taking a brief.
Add a critic that checks the page against the research reports with a four-item checklist, with at most two revision rounds.
Log every brief, report and critique.
Rewire as peer-to-peer: researcher hands off to writer, writer to critic, with an allowed-hand-off table and a cap of three.

You are done when

The supervisor never calls search itself.
Each worker's context contains only its brief, not the whole conversation.
The critic rejects a draft at least once when you plant an unsupported claim.
You can state, for each wiring, how many traces you would read to explain a wrong sentence in the output.

Stretch. Run two researchers in parallel, one per app, and measure the time saved.

Practise it: Design a Multi-Agent Data Analyst