Four topologies for delegating work

In our lesson on prompt testing and refinement, you constructed a practical two-agent system. A drafter produced the work, an independent critic scored it, and an orchestrator model, following its instruction, sent a draft below the bar back for revision for at most three rounds before returning the critic’s latest verdict with its score. The motivation for splitting those roles was mechanical: because everything the drafter generated occupied its own context window, asking that same agent to evaluate its own output made agreement the continuation the model tends toward. Handing the review to a second agent, whose context window holds the question and the draft without the drafter’s reasoning, reduced that bias. In that loop the orchestrator model compares the critic’s score with the bar, and no code makes the comparison.

That fundamental insight underpins all multi-agent architecture, and in this module, we will expand that foundation. Every specialist within a multi-agent system remains identical to the single agent you built in our lesson on agent design: an instruction structured into named blocks that anchors a general model to a dedicated responsibility. What changes here is the connective tissue linking multiple agents together. One operational principle governs the system: an agent’s system instruction specifies whom it must consult, and it selects among those specialists by evaluating a concise, one-line description of each. Every workflow topology is a concrete arrangement of that wiring, and every coordination failure stems directly from the fact that this wiring is expressed in natural language prose.

This design gives rise to two distinct architectural surfaces. Topology, the operational shape, defines who delegates to whom, and whether tasks route to a single specialist or across an entire panel in parallel. Voice defines how each agent articulates its responses; register, cadence, and tone operate as engineered constraints enforced by concrete directives in the instruction. By the end of this lesson, you will be able to select the most efficient topology for a given problem, calculate its computational cost, and trace each behavior a delegation rule or a register law asks for in a live transcript back to the line of configuration that asks for it.

One statement about this module’s numbers and pictures, made once. The configuration excerpts from the router’s file and the Council’s file are the files’ own lines. The Council transcript is a live run on 2026-07-13, three agents on ollama/qwen3:8b on one laptop, quoted verbatim; the whole run took about 85 seconds of wall-clock time across at least four model calls, and its exact count of calls was not recorded. The Style Council transcript is a live run on 2026-07-11 on gemini-3.5-flash, compressed for the page. The file as committed on the day of that run set a different temperature on each agent: the Router 0.3, the Analyst 0.4, the Peer 0.5 and the Mentor 0.7. Today’s file runs gemini-3.8-flash and sets no temperature, so every stylist samples at the provider’s default. The three figures draw topologies and omit cost, and the first one fans out to three specialists as if every one ran, where whether one runs or all do is the topology decision.

an orchestrator routes by reading specialist descriptions

A user request arrives that one of several specialists should answer. The entity choosing between those specialists is a language model, and the only material a model can evaluate during generation is the text inside its context window. What text must be present for it to choose reliably, and what must the chosen specialist receive so that an erroneous assumption formed during triage does not contaminate the subsequent task?

The coordinating model, the orchestrator, maintains a system prompt defining its narrow domain of direct responsibility alongside a short description for each specialist registered in the system. These descriptions provide the boundary conditions for delegation: concise statements detailing each specialist’s exact purpose, tools, and operational scope. When a prompt arrives, the orchestrator evaluates the input against those descriptions and delegates the task to the selected specialist.

Once delegated, the specialist executes its task within an isolated context window, governed by its own system instruction and its own dedicated tools. This architectural isolation protects token probabilities during generation. A context window dedicated to a single objective contains no competing directives or irrelevant conversational history to distort the attention distribution. The specialist remains unexposed to the orchestrator’s internal deliberations and the intermediate outputs of other specialists unless the orchestrator explicitly forwards that text. If the orchestrator entertained an erroneous assumption during triage, that assumption never enters the specialist’s context.

After completing its run, the specialist returns its output to the orchestrator. The orchestrator can then return the response directly to the user, delegate a follow-up task to another specialist, or synthesize multiple specialist outputs into a single response.

Every pattern in this module relies on this delegation mechanism: the routing decision occurs directly within the orchestrator’s inference turn as the model chooses which specialist to invoke. You can also lift this routing logic out of the model turn entirely and express it in deterministic code, which is the right optimization when an orchestrator’s sole responsibility is request triage.

one request through a multi-agent system

in

a user request

orchestrator

reads each specialist’s description and picks

its own instruction says what it does not answer itself

specialist A

own instruction, own tools, independent window

specialist B

sees nothing A saw

specialist C

sees nothing A or B saw

answers return to the orchestrator, which assembles the reply

multi-agent systems resolve into four topologies

Most multi-agent architectures resolve into four foundational topologies, or hierarchical combinations of them. We will examine them in the exact order you should evaluate them in practice.

solo: a single agent with tools is the baseline

A single agent equipped with targeted tools, answering the user directly without any delegation.

Starting with a solo agent is the right choice far more often than many engineers realize, and you should always treat it as your baseline design. A single agent configured with a reliable search tool and a database interface can handle an impressive spectrum of complex work without incurring multi-agent overhead. The Tutor is the pattern at its plainest: one agent, no delegation, and in its case no tools either.

router: one agent classifies and hands off

An entry-level agent dedicated entirely to intent classification and routing. It evaluates the user’s prompt, matches it against the available specialist descriptions, and hands off the entire turn to a single specialist. The router’s behavior is defined entirely within its instruction. Here are the router’s opening lines and one specialist entry, as the router’s file writes them:

orchestrator:
  name: "RouterAgent"
  instruction: |
    You are a triage router.
    You do NOT answer questions directly if they require specialized knowledge.
    Instead, you examine the user's request and delegate to the appropriate specialist:
    - If the user asks a coding or programming question, delegate to CodeExpert.

subagents:
  - name: "CodeExpert"
    description: "Answers programming questions: writes, explains, and debugs code in any language. Pass it the user's question verbatim, with any code they pasted. Returns the complete answer with every line of code written out."

Read that as: the orchestrator’s instruction holds the contract, saying when to hand off and to whom; each entry under subagents holds a name the contract can point at and a description the orchestrator reads when it decides. Two keys, and the whole router is in them.

Notice how this instruction reflects the identity block, which states an agent’s core purpose in a single declarative sentence. The directive starting with “You do NOT answer” enforces that boundary. Because triage and hand-off constitute the router’s entire function, this explicit negative constraint keeps the model focused on routing. Without it, a capable model presented with a technical coding prompt will simply attempt to answer the question directly. Generating an answer is the natural statistical continuation, which means your dedicated specialist would never be invoked.

Deploy a router when incoming requests fall into distinct categories that require different tools, specialized knowledge bases, or tailored communicative registers. A router is an agent whose sole task is classification. The same pattern appears wherever triage sorts requests by the computational depth they need rather than by the domain they belong to. Classifying requests before allocating computational resources remains one of the most effective strategies for managing operational costs in production.

Keep one structural nuance in mind. When a specialist’s response is the complete, final answer without requiring merging or editing, routing the final output back through the orchestrator turns that last turn into an unnecessary copy operation. Because even simple text forwarding introduces an opportunity for model error or latency, a well-built framework lets the specialist’s answer reach the user without passing back through the orchestrator. A framework does this with a dispatch step: the orchestrator becomes a classifier that names one route, code runs that route, and the route’s output is the reply.

your turn: route two visitor requests

The Riverside Community Fair, a fictional one-day event this course uses for practice, runs a router in front of three specialists, each registered with a one-line description:

ScheduleDesk: "Answers questions about when and where fair events happen, from the fair's schedule. Pass it the visitor's question verbatim. Returns the time, the place and the stall number."
LostAndFound: "Logs lost items and matches them against items handed in. Pass it the item's description and where it was last seen. Returns a reference number and the collection point."
VolunteerRota: "Assigns volunteers to shifts. Pass it the volunteer's name and the hours they offered. Returns the shift and the stall."

A visitor asks the fair’s router: “When does the bake sale open?” Which specialist gets it?

Read the bake-sale question against the three descriptions. ScheduleDesk’s says it answers questions about when and where fair events happen; neither of the others covers timing, so the router picks ScheduleDesk. What reaches ScheduleDesk is the visitor’s question verbatim, because its description says to pass it that way, and nothing of the router’s own deliberation.

The routing worked, and the same question shows why solo is the baseline: a single agent holding the schedule answers it in one call. A router earns its place only when the fair’s requests fall into categories that require different tools, specialized knowledge bases or tailored registers.

decomposer: a goal split into sequential stages

An orchestrator that breaks a complex objective into sequential stages, routes each stage to a dedicated specialist, and synthesizes the outputs. For example, a project manager agent might pass raw source data to an analytical agent, forward the resulting analysis to a technical writer, and deliver the finalized document to the user.

Use a decomposer workflow when your problem exhibits strict step-by-step dependencies—where step two cannot begin until step one has produced a concrete deliverable.

council: parallel specialists, balanced by a moderator

A panel of multiple specialists evaluating the exact same input concurrently, followed by an orchestrator that synthesizes their independent perspectives into a single unified verdict.

Our runnable specimen is the Council, which runs three distinct agents locally using ollama/qwen3:8b on one machine:

• The Moderator coordinates the deliberation and renders the final assessment. It maintains strict neutrality without taking an advocacy position, and its instruction dictates a structured verdict: the argument in favor, the argument against, and a synthesized conclusion spanning two to four sentences.
• The Advocate constructs the strongest honest case in favor, presented as exactly three numbered arguments. Its instruction includes an explicit escape hatch that supersedes the mandate to argue persuasively, allowing the model to state clearly that “the honest case is thin” rather than fabricating support for a flawed premise.
• The Skeptic constructs the strongest honest case against the proposition, delivering exactly three numbered objections focused on risks, edge cases, and structural flaws.

The Council configuration also assigns specific sampling temperatures to each role to reflect their responsibilities: the two specialists operate at 0.7 to encourage comprehensive exploration of arguments, while the Moderator operates at 0.5 to support measured, balanced synthesis. All three agents run on local ollama/ open weights, where the setting is yours to choose. Gemini accepts a temperature as well, and the engine passes one to it whenever an agent’s definition sets it; Google’s guide for its Gemini 3 models recommends keeping the default of 1.0, and most of this course’s Gemini agents, the Style Council’s among them, set none. Regardless of platform, per-agent sampling settings belong in the agent’s own definition, beside its prompt and its tools.

Deploy a council when an inquiry lacks a single verifiable factual answer and the primary value lies in balancing competing considerations—such as an architectural design review, a comprehensive risk audit, or a complex strategic decision.

each added agent adds latency and token cost

Before introducing additional agents to your system, calculate the computational and operational costs, using our specimen as a concrete baseline. That calculation needs three units, kept apart. Agents are the definitions in the file: the Council has three. A model call is one request from one agent’s loop to its model; the engine runs each agent as a loop of steps, one model call per step, feeding the step’s tool results into the next call, and the loop ends on a step that calls no tool. Provider requests are the requests actually sent to the model’s provider; when a transient failure is retried inside one model call, or a fallback model is tried, one model call sends more than one.

The Council is a team of three agents: a Moderator, an Advocate and a Skeptic. You send it one claim, and the Moderator returns one verdict.

How many times is a model called before that verdict arrives?

Because a sub-agent is a tool on its orchestrator, the Council needs at least four model calls where a solo agent with no tools answers in one. The Moderator makes one call that delegates to the Advocate and the Skeptic and a second, after both answers are in, that writes the verdict; each specialist makes at least one call in its own loop. The Moderator’s instruction asks for the Advocate first and then the Skeptic, and a Moderator that delegates in two steps makes three calls of its own, five in all. The engine’s own tests, run with scripted models, record both counts: two Moderator calls when both delegations come in one response, three when they come in two steps. With an 8-billion-parameter model running locally on a laptop, the live run took approximately 85 seconds from start to finish, on an engine that ran a step’s sub-agent calls one after another. In the current engine, sub-agent calls the Moderator makes in one step run at once, up to the team definition’s max_concurrency (four by default), so the wait shrinks toward the slower specialist’s call when the model server can answer two requests together; a local Ollama server with one request slot still answers them in turn. The Style Council follows the same arithmetic: asked for all three stylists, the Router delegates to each in turn and then presents the answers, so the reply costs at least five model calls (two of the Router’s and one per stylist), and seven if the Router delegates to one stylist per step. Token consumption follows the model calls, and each further call an orchestrator makes re-sends its growing context: the Moderator’s second call carries the user’s claim, its own first step and both reports. Latency grows with the calls wherever one waits on another’s answer.

There is also a second, more subtle operational cost to track. Every delegation boundary transfers text between distinct context windows. A sub-agent’s tool takes one string, request, which the orchestrator writes; the specialist’s turn starts from that string as its user message, together with its own earlier requests and answers from this conversation, which its session keeps. It never sees the orchestrator’s conversation with the user or another specialist’s session. Consequently, any background detail that the specialist requires but the orchestrator omits from request is permanently lost. This information isolation is intentional, but it will surface as an error the moment a specialist answers an inquiry without critical context that the orchestrator failed to forward. Every added agent introduces another boundary where vital context can be dropped.

You can watch that boundary by making the receiving agent say what it received. One added line in the specialist’s instruction asks it to open its reply with a one-sentence restatement of the request it was handed, and a matching line asks the orchestrator to quote that restatement in its verdict. Comparing the restatement with what the user typed shows whether every sentence the user wrote crossed the boundary.

Those costs land differently depending on the topology. In a decomposer, each stage reads the stage before it as input, so a wrong figure at stage one arrives at stage two as established material and every stage after builds on it; nothing downstream re-derives it, and the finished report carries the error with no gap anywhere to mark it. In a council, every specialist reads the same input, so one weak answer stays one answer, and the cost moves to the moderator, where an instruction to weigh both sides pulls the verdict toward the middle of whatever it was handed. Read a chain’s failure at the earliest stage that could have produced it, and a panel’s at the synthesis.

From these trade-offs, we can derive a clear architectural principle:

Add an agent only after one has failed: do not add an agent until a single agent with tools has actually failed at the boundary of specialization. Every extra agent adds latency, a context handoff, and one more thing that can fail.

When can you conclude that a single agent has genuinely failed? A single agent has reached its architectural limit when its system prompt begins to contradict itself—where guidelines for one subtask conflict with the instructions for another, or where one subtask requires powerful tools that you cannot safely expose to the entire workflow. Until you observe that structural breakdown in practice, maintain a solo architecture.

The Riverside Community Fair helper answers visitors from the schedule in its instruction, in a friendly voice. Now the organisers want the same helper to write their end-of-day summary, in a formal one.

Both conditions mark the point where prompting stops helping. An instruction shapes what one model does with the context it holds and the tools in its reach, and it cannot change what that context holds or which tools are in reach. Some tasks need exactly that change: a reviewer that has not read the draft’s reasoning, an observer that does not know what was requested, a writer that holds no search tool, two subtasks whose rules pull against each other. The course meets each of these by breaking the task into parts and giving each part its own agent, with its own window, instruction and tools. The critic in module 1.05 reviews a draft it did not write. The blind observer in module 2.07 inventories an image without knowing what was asked for, and a separate auditor judges that inventory against the specification. The arbiter in module 2.09 holds no search tools and writes only from two collectors’ reports. The solo agent stays your baseline, and when its failure is one of these, the repair is a second agent placed in the topology the task calls for.

the delegation contract

As we observed earlier, an orchestrator selects a specialist by evaluating that specialist’s description. Consider what this implies for system design: because an LLM reads and acts upon this text during routing, the description is the formal API contract between agents.

subagents:
  - name: "CodeExpert"
    description: "Answers programming questions: writes, explains, and debugs code in any language. Pass it the user's question verbatim, with any code they pasted. Returns the complete answer with every line of code written out."

Read that as: this is the only text the orchestrator has about CodeExpert when it decides. Write it the way you would write a function signature: what goes in, what comes back, and when to reach for it. The three sentences above do exactly that, in that order: when to call it, what to pass, and what it returns.

The complementary half of this contract resides in the orchestrator’s own system instruction. In the Council configuration, this is captured in a single directive: “You MUST consult BOTH of your subagents before answering,” accompanied by execution order instructions and a mandate to pass the user’s claim verbatim. That instruction represents the entire routing engine: the model reads the contract alongside each specialist’s description and reasons across both.

The delegation contract. An orchestrator’s instruction says who it must consult and when; each specialist’s description says what that specialist is for; the orchestrator’s model reads both and chooses. Both halves are prose, so both are auditable, and both are where routing failures start.

Because the delegation contract is authored in natural language prose, its failure modes mirror ambiguities in writing. An imprecise description leads to routing errors that can be difficult to troubleshoot, especially because each specialist performs flawlessly when tested in isolation. Well-engineered agent teams invest substantial care into refining these descriptive interfaces.

Examine the Council transcript below, captured from a live run executed entirely on a local laptop with no cloud provider. The Moderator queries both the Advocate and the Skeptic (neither of whom can see the other’s workspace) and synthesizes their inputs into its structured three-part verdict:

Trace that output back to the underlying configuration file. The Advocate’s opening statement (noting that “the honest case is thin”) demonstrates the escape hatch in action. Without that explicit valve, a countable contract of exactly three arguments would pressure the model into generating weak or ungrounded rationalizations. Similarly, the final verdict mirrors the exact three-part format specified in the Moderator’s instruction, identifying the single decisive consideration and articulating what evidence would overturn the conclusion. Each of these behaviors is one a line in the Council’s file asks for, and in this run the delegation contract operated as designed.

At the same time, we should evaluate these mechanisms realistically. Both the escape clause and the instruction to “never argue a side yourself” are natural language directives in a system prompt. A written instruction shifts probability distributions in the model; it does not construct an impermeable boundary. In this recorded run, the escape valve operated as intended, and that single observation does not establish that it will fire on the next run, which samples again. The critic loop from module 1.05 adds a second reader: one agent drafts, and a separate agent scores that draft against an explicit standard. That score is the critic model’s judgment, and in the critic loop’s file the comparison of it with the bar is also made by a model, the orchestrator following its instruction for at most three rounds. Where ungrounded arguments cannot be tolerated, your application code reads the returned score, compares it with the threshold itself, and decides what happens when the check fails: withhold the reply, return a failure, or route it to a person.