3. The orchestrator-worker pattern

Description

By the end of this lesson you'll be able to split up a multi-agent system's roles with an explicit criterion — what the orchestrator owns, what each worker owns, and what neither of them should own — you'll be able to tell the orchestrator-worker pattern apart from two other ways of splitting up work that look similar and get confused with it (the fixed chain and the single-hop router), and you'll be able to decide which of the three fits a concrete case before touching the canvas.

This matters because the previous lesson left you with four trimmed-down responsibilities on paper, and a list of responsibilities still isn't a system. What's missing is what decides whether the system works or turns into a mess: who owns the conversation with the customer, who keeps the memory, who decides a case is closed, and what happens when a specialist runs into something that isn't theirs. If those four questions don't have a clear answer before you start connecting nodes, what you're going to build is a monolith split into several pieces — the worst of both worlds: the team's complexity without the specialist's precision. And this, on top of it, is what you'll be asked to explain in an interview: nobody asks "do you know how to connect one agent to another?"; they ask "how did you structure the system, and why?"

Connection to the module: lesson 2 gave you the criterion for cutting by responsibility and left you with four loose pieces — order_specialist, billing_specialist, sales_specialist, and triage_agent. This lesson shapes them into an architecture: the split of roles, who owns what, and which pattern fits. It's still design on paper: the actual connection between one agent and another is lesson 4. What you define here is what you're going to wire there, and each handoff's exact contract is lesson 5.

The triage person at a clinic

At the entrance of a clinic's emergency room there's someone whose job isn't to cure anyone. They listen to what each person who arrives brings, ask two or three questions, and decide where to send them: orthopedics, cardiology, observation. They don't set a cast, don't read an EKG, don't prescribe anything. If you ask them what they know about medicine, the honest answer is: enough to recognize what each case is about, and nothing more.

Notice three things about that person, because all three are going to become design rules.

First: they're the only one who talks to whoever arrives. The patient explains the problem to them, in their own language, disorganized, with two symptoms mixed together and an underlying worry they didn't mention. They translate that into a concrete assignment for the specialist: "male, 40, chest pain for 2 hours, no history." The cardiologist doesn't receive the patient's full account — they receive the assignment.

Second: the deep knowledge isn't in them. It's in each specialist. And that's on purpose: if you asked the triage person to also know cardiology, orthopedics, and pediatrics, they'd stop being good at the one thing they need to be good at, which is quickly recognizing what each case is about.

Third: the case comes back. The cardiologist doesn't discharge the patient on their own or decide the case is over. They issue a result — "heart attack ruled out, it's muscular" — and that result returns to the care flow, where someone decides whether that's enough or whether another service is needed. That return trip is what lets a patient with two problems get a single coherent response at the end, instead of two contradictory discharges.

That's the complete orchestrator-worker pattern: someone who receives, translates, and routes; specialists who resolve within their scope and return a result; and a final composition that pulls everything together into a single response.

Anatomy of the pattern: who owns what

The word doing all the work here is owning. Not "can do" — owning. In a well-split system, everything has exactly one owner, and the most common failures are cases where two pieces think they own the same thing, or where something has no owner.

The orchestrator

The orchestrator — in our case, the triage_agent — owns four things:

1. The conversation with the customer. It's the only one that receives the raw message and the only one that emits the text the customer reads. Everything a specialist produces passes through it before going out. This isn't formalism: it's what guarantees the customer gets a single voice, a single tone, and a single response even if the case touched three domains.

2. The session memory. The memory node — what you built in Module 3, with its session ID per customer — connects to the orchestrator's ai_memory port, and only there. Specialists carry no memory of the conversation. Every call to a specialist is, from its point of view, a new, self-contained assignment. This is counterintuitive at first and it's one of the pattern's most important decisions; we'll come back to it in a moment.

3. The decision of who to delegate to and when. Including the decision to delegate more than once, or not to delegate at all. If the customer writes "hi," the orchestrator responds "hi, how can I help you?" without bothering anyone.

4. The decision that the case is closed. The specialist says "this is what I found." The orchestrator decides whether that's enough to answer the customer or whether something's missing. That decision doesn't belong to the worker.

And there are two things the orchestrator does not own, which is where most of the failures happen:

• It doesn't own domain knowledge. No deadlines, amounts, policies, or database field names. If its system prompt mentions "14 days" or "$800," that knowledge is in the wrong agent.
• It doesn't own action tools over systems. The orchestrator doesn't send emails, doesn't open disputes, doesn't write to the database. Its tools are the specialists. One reasonable exception: it can have some very generic read tool — identifying the customer by phone number, for example — if that's what it needs in order to route. But the moment you connect a tool that acts, you've started rebuilding the monolith.

The worker

Each specialist — order_specialist, billing_specialist, sales_specialist — owns three things:

1. Its complete domain. All the knowledge needed to close out cases in its scope: the rules, the deadlines, the exceptions, the vocabulary. It's in its system prompt, which is short precisely because it only covers one domain.

2. Its tools. The ones it needs, and only those. A specialist that needs a tool that clearly belongs to another one is a sign the lesson 2 cut was done wrong.

3. Its own agentic loop. And this is what makes it an agent and not a function: it can call a tool, look at the result, decide it needs another one, call it, and only then produce its result. That internal reasoning is its own, and the orchestrator doesn't direct it.

And three things the worker does not own:

• It doesn't talk to the customer. Its output is a result for the orchestrator, not a message for a person. Writing a specialist's prompt in customer-service tone — "respond warmly and in a friendly voice" — is a subtle but costly mistake: it produces text meant to be read, which the orchestrator then has to reinterpret or forward as-is, and when there were two specialists the customer gets two greetings and two sign-offs stitched together.
• It doesn't decide whether the case is over. It reports its status — resolved, unresolved, this other thing is needed — and the orchestrator decides.
• It doesn't delegate to other specialists. At least not by default. A worker that can call another worker opens the door to circular delegation, which is lesson 6's whole problem. The simple starting rule: workers are the tree's leaves.

The ownership table

Why memory lives only in the orchestrator

It's worth stopping here, because it's the decision most people get wrong at first.

The temptation is to give every specialist memory, with the argument that "this way it remembers the customer." It sounds good and produces three concrete problems.

Duplicated history. If the orchestrator has the conversation and the specialist does too, the same information travels to the model twice on every turn: once in the orchestrator's context and once in the specialist's. You pay for the same tokens twice and gain nothing — lesson 7 puts the number on it.

Histories that fall out of sync. The billing specialist only runs when it's called. If in a ten-turn conversation it got called twice, its memory has two entries from a ten-turn conversation. That partial memory is worse than none: the specialist thinks it has context and actually has fragments without the intermediate turns that gave them meaning.

Ambiguity about who's the source of truth. If the orchestrator believes the customer already gave their order number and the specialist doesn't have it in its history, neither one is wrong, and the system has no way to resolve it.

The right alternative is simple: the orchestrator owns the history and passes the specialist what it needs, already digested. If the customer gave their order number three turns ago, the orchestrator includes it in the assignment. The specialist works without memory, with everything it needs right in the assignment itself. That also makes it reproducible: you can test an isolated specialist by sending it an assignment and see exactly what it returns, without depending on a conversation's state.

There's one legitimate exception, and it's the only one: a specialist that by its very nature keeps its own long thread with the customer — think of an "onboarding" agent guiding a seven-step process over several days. There it does make sense to give it its own memory with its own session ID. But it's the exception, and it's worth being able to justify it.

Worked example: TuTienda's system, drawn and executed

Here's how lesson 2's split looks now, shaped into an architecture:

                        ┌──────────────────────┐
   Chat Trigger ──────► │  triage_agent        │ ◄── Postgres Chat Memory
                        │  (orchestrator)      │     (session ID = customer_id)
                        │                      │
                        │  Chat Model: fast    │
                        └──────────┬───────────┘
                                   │ ai_tool
              ┌────────────────────┼────────────────────┐
              ▼                    ▼                    ▼
    ┌───────────────────┐ ┌──────────────────┐ ┌──────────────────┐
    │ order_specialist  │ │ billing_specialist│ │ sales_specialist │
    │ (worker)          │ │ (worker)          │ │ (worker)         │
    │                   │ │                   │ │                  │
    │ Chat Model: strong│ │ Chat Model: strong│ │ Chat Model: mid  │
    │ no memory         │ │ no memory         │ │ no memory        │
    └─────────┬─────────┘ └─────────┬────────┘ └────────┬─────────┘
              │ ai_tool             │ ai_tool           │ ai_tool
      ┌───────┼───────┐      ┌──────┼──────┐      ┌─────┴──────┐
      ▼       ▼       ▼      ▼      ▼      ▼      ▼            ▼
  lookup_  check_  create_  lookup_ open_ get_  recommend_  search_
  order    refund_ ticket   charge  disp. cust. products    knowledge_
           elig.                    ute   prof.             base

Three things to read in that drawing:

• Memory hangs off the orchestrator and nobody else.
• Each worker has its own model connected. They don't have to be the same one — the orchestrator makes a simple decision and can run on a faster, cheaper model; the billing specialist makes expensive decisions and deserves the most capable model. This model split is one of lesson 7's cost levers.
• The action tools are all at the second level. The orchestrator doesn't have any.

Now for the trace of a real execution. The customer writes lesson 1's message — the unrecognized charge plus the order — and this is what shows up in the orchestrator's intermediateSteps:

# triage_agent's execution trace (with returnIntermediateSteps = true)

step 1  → orchestrator's model call
          decides: there are two topics, I'll delegate the first one

step 2  → tool: billing_specialist
          input:  { "task": "Customer reports a $1,200 charge they don't
                     recognize. Customer ID: C-9931. Verify the charge and,
                     if it doesn't match any purchase, open a dispute." }

          ─── inside billing_specialist (its own loop) ───
          step 2.1 → specialist's model call
          step 2.2 → tool: lookup_charge  ($1,200, last 60 days)
                     result: no matches
          step 2.3 → tool: get_customer_profile (C-9931)
                     result: a single card on file, no aliases
          step 2.4 → tool: open_dispute
                     result: { "dispute_id": "D-8842", "sla_hours": 48 }
          step 2.5 → specialist's model call
          ──────────────────────────────────────────────────────

          output: { "status": "resolved",
                    "summary": "$1,200 charge doesn't match any
                                purchase on file. Dispute D-8842 opened,
                                review within 48 business hours.",
                    "needs_human": false }

step 3  → orchestrator's model call
          decides: the second topic is still missing, I'll delegate

step 4  → tool: order_specialist
          input:  { "task": "Check the status of order #4521 for customer
                     C-9931 and report the estimated delivery date." }

          ─── inside order_specialist ───
          step 4.1 → specialist's model call
          step 4.2 → tool: lookup_order (4521)
                     result: { "status": "in_transit",
                                  "shipped_at": "2026-07-21",
                                  "eta": "2026-07-23" }
          step 4.3 → specialist's model call
          ───────────────────────────────────

          output: { "status": "resolved",
                    "summary": "Order 4521 shipped on 07/21, estimated
                                delivery 07/22-23.",
                    "needs_human": false }

step 5  → orchestrator's model call
          decides: both topics are covered, I'll compose and close

What to expect. Look at the numbers in that trace, because they're lesson 7 previewed: the orchestrator made three calls to the model (steps 1, 3, and 5), the billing specialist made two (2.1 and 2.5), and the order one made two (4.1 and 4.3). Seven calls to the model and four calls to real tools, to answer one message. A monolithic agent would have made maybe three calls to the model and the same four to tools. You're paying a bit more than double in model calls in exchange for precision and a bounded blast radius. That's the pattern's deal, and you should make it with your eyes open.

Also look at the structure of steps 2 and 4: inside each one there's a complete loop. The billing specialist called three tools in sequence, and the third one — opening the dispute — depended on the first two's results. Nobody programmed that sequence. It's the specialist's agentic loop running inside the orchestrator's agentic loop. That's what no Switch can produce, and it's exactly what you're going to wire in lesson 4.

And look at the status field in both outputs. That word — "resolved" — is what lets the orchestrator decide in step 5 that the case is closed. If it had said "needs_more_info", step 5 would have been another delegation or a question to the customer. That field is the output contract, and lesson 5 formalizes it.

Three ways to split up work, and which is which

"Multi-agent" doesn't mean one single thing. There are at least three ways to split work across several AI pieces, they get confused easily, and picking the wrong one produces systems that only half-work. It's worth being able to name them.

Form 1 — The fixed chain (pipeline)

Several pieces in sequence, where one's output is the next's input, and you decided the order in advance.

Message ─► extract data ─► classify ─► draft response ─► send

When it applies. When the order of the steps is always the same and doesn't depend on the case. Processing incoming invoices: you always have to extract the fields, always have to validate them, always have to log them. There's nothing to decide about the path.

When it doesn't. As soon as the case determines the path. And watch out for this, because it's the most common trap: a fixed chain usually doesn't even need agents. If the order is decided and each step is a transformation, what you need is AI nodes chained together — the procedural AI from Guide 6 — or a deterministic sub-workflow, which cost less and are much more predictable.

Form 2 — The single-hop router

One piece classifies and sends the case to exactly one destination. The case doesn't come back.

Message ─► classify ─┬─► destination A (and it ends there)
                      ├─► destination B (and it ends there)
                      └─► destination C (and it ends there)

When it applies. When every case belongs to exactly one domain, there's nothing to compose at the end, and the destination can close the case on its own. The typical example isn't a chat: it's an incoming ticket system where tickets get split into different queues. Every ticket goes to a queue and that's where the router's work ends.

When it doesn't. When the same message can touch two domains, or when a single final response is needed, or when the destination might discover halfway through that the case wasn't its own. All three are the norm in customer support.

An important note so you don't get confused: a router can also be implemented natively, with specialists as tools. The difference from the next pattern isn't how it's wired, it's the policy: in a router the orchestrator delegates once and forwards what it received; in orchestrator-worker it can delegate several times, evaluate the results, and compose. Lesson 1's Switch is a bad implementation of a router — fixed and with no return trip — but the router itself is a legitimate pattern.

Form 3 — Orchestrator-worker

One piece coordinates, dynamically decides who to call — zero, one, or several times — receives each result, and composes the final response.

Message ─► orchestrator ⇄ worker A
                        ⇄ worker B      ─► single response
                        ⇄ worker C

The double-headed arrows are what sets it apart: every call comes back.

When it applies. When the number and order of delegations depend on the case, when a single composed response is needed, or when one result can change the next decision. Customer support over chat is the textbook case.

When it doesn't. When the work is deterministic (use a chain or a sub-workflow), when volume is so high that per-conversation cost outweighs precision, or when there's a single domain.

The decision table

Read it top to bottom with your case in hand and the answer shows up on its own. If you answered "no" to the first four, you don't need this module for that case — you need Guide 6.

When the pattern doesn't apply

Three situations where orchestrator-worker is the wrong answer, even if you have several responsibilities:

When the responsibilities never overlap. If TuTienda had a customer support agent and an internal agent that builds reports for the finance team, those two don't form a team: they're two different systems that happen to live in the same n8n instance. Putting an orchestrator on top of them adds a call to the model to choose between two things that never show up in the same message. Two separate workflows, each with its own trigger, is simpler and cheaper.

When the "orchestrator" has nothing to decide. If the input channel already tells you what it's about — a web form with a "reason: billing / orders / sales" field the customer picked — then the routing already happened, and the customer did it. Putting an agent in to re-decide something that's already decided is paying for a model call for nothing. There a Switch on the form field is the right choice — and yes, this is the case where Switch is the good answer, because the data is structured and the decision is deterministic.

When there's a hard latency constraint. A voice agent handling a phone call has a very short time budget before silence becomes awkward. Every delegation adds a full round trip to the model, in series. If your budget is two seconds, you probably only have room for one agent with good tools. Module 6, when you get to voice agents, picks this tension back up.

Common mistakes

Giving workers memory "so they have context" (conceptual). What happens: someone connects a memory node to each specialist's ai_memory port, with the same session ID as the orchestrator. The system starts behaving strangely: the billing specialist answers things about an order, or repeats information already given to the customer, or contradicts the orchestrator. Why it happens: it looks like a free benefit, and the word "memory" invites the thought that more is always better. How to spot it: check how many turns the specialist's memory has compared to the orchestrator's; if the specialist got called twice in a ten-turn conversation, its history has holes it has no way of knowing exist. How to fix it: remove memory from the workers and pass them the context they need inside the assignment — if the order number was mentioned three turns ago, it's the orchestrator's responsibility to include it, and that's precisely the job it exists for.

Writing the worker's prompt as if it were talking to the customer (conceptual). What happens: the specialist returns "Hi there! I'm happy to look into that for you. I already opened your dispute, is there anything else I can help with?", and the orchestrator has to decide what to do with that text: if it forwards it as-is, the customer gets two greetings when there were two delegations; if it rewrites it, the system paid tokens generating courtesy text that gets thrown away. Why it happens: every agent example you see is an agent talking to people, and the reflex is to write every prompt that way. How to spot it: read a specialist's raw output in the log; if it has a greeting, a sign-off, or a question aimed at the customer, it's written for the wrong recipient. How to fix it: the worker's prompt should explicitly ask for a result, not a message — "return what you found, what action you took, and whether the case is closed" — and lesson 5 takes it one step further with a structured output.

Connecting action tools to the orchestrator "because they're simple cases" (practical). What happens: the triage_agent ends up with create_ticket connected directly, on the grounds that creating a ticket is trivial and doesn't warrant delegating. Six weeks later it also has send_email and lookup_order, because each one seemed trivial at the time, and the orchestrator turned back into the monolith. Why it happens: each individual exception is reasonable; the problem is cumulative and doesn't show up at the moment you make it. How to spot it: count how many of the orchestrator's tools are NOT agents; the right number is zero, or at most one read tool it needs in order to route. How to fix it: if creating a ticket is a legitimate system action, it belongs to the specialist whose domain uses it — and if it doesn't belong to any of them, that's a sign a responsibility is missing from your cut.

Confusing a router with orchestrator-worker and complaining about what the router doesn't do (practical). What happens: someone builds a system where the orchestrator delegates once and returns exactly what it received, and then gets frustrated because messages with two topics get half-answered. Why it happens: the two patterns' wiring is identical — specialists as tools — what changes is the policy written into the orchestrator's system prompt. How to spot it: check whether the orchestrator's prompt explicitly says it can delegate more than once and must compose a single response; if it doesn't say that, you have a router. How to fix it: add that explicit instruction — "if the message carries more than one topic, delegate each one separately and compose a single response at the end" — and verify in the trace that two tool calls show up in the same turn.

Exercises

Exercise 1 — Assign ownership. For each of these eight elements, say whether it belongs to the orchestrator, a worker, or neither:

(a) The conversation's session ID. (b) The rule "personal hygiene products aren't eligible for return." (c) The payments API credential. (d) The decision to respond to the customer without delegating anything. (e) The text "is there anything else I can help you with?" (f) The open_dispute tool. (g) The decision that a second delegation is needed. (h) The deterministic calculation of whether a purchase date is within the deadline.

Exercise 2 — Pick the pattern. For each of these four systems, say which of the three forms applies (fixed chain, router, orchestrator-worker) and why:

(a) A system that receives scanned invoices by email, extracts vendor, amount, and date, validates against the vendor catalog, and logs the invoice in a spreadsheet. (b) A customer support chat where messages often carry more than one topic and a single response is needed. (c) An internal inbox where employee requests arrive that need to go to the right queue: human resources, IT, or accounting. Each queue has a human team resolving them. (d) A research assistant that, given a question, decides which sources to check, reads the results, decides whether more searching is needed, and finally writes a report.

Exercise 3 — Rewrite a worker's prompt. This is a specialist's current system prompt. It has three problems with the pattern. Find them and rewrite it.

# order_specialist's System Message (version with problems)
#
#   You are TuTienda's support agent. Greet the customer warmly
#   and speak in a friendly voice. You resolve order and return
#   questions. If the customer also asks about a charge, use lookup_charge
#   to help them. Remember what the customer told you in earlier
#   messages. Always end by asking if they need anything else.

# order_specialist's System Message (corrected)
#
#   You are TuTienda's orders and returns specialist.
#   You resolve shipping status, delays, and return requests.
#   You don't handle charges or billing: if the assignment you
#   receive belongs to that domain, don't use any tool and
#   report it as out of your scope.
#
#   You work with the assignment you receive; you don't have a history
#   of the conversation. If you're missing a piece of data to resolve
#   something, don't make it up: report it as missing.
#
#   Return deadlines: 30 days general, 14 days for the
#   electronics category, no returns for personal hygiene items.
#
#   Always return: what you found, what action you took, whether the case
#   is closed or pending, and what data is missing if it's pending.
#   Don't write greetings or sign-offs: your output is read by another
#   agent, not the customer.

Summary and next step

You now have the architecture. The orchestrator owns the conversation, the session memory, the decision of who to delegate to, and the decision that a case is closed — and it doesn't own domain knowledge or action tools. Every worker owns its complete domain, its tools, and its own agentic loop — and it doesn't talk to the customer, doesn't decide whether the case is over, and doesn't delegate to other workers. Memory lives in one single place, the orchestrator, and what the worker needs travels inside the assignment. And you saw that orchestrator-worker is one of three ways to split up work, with a four-question table to know which one fits.

Before moving on you should be able to: say who owns the session ID and why; explain why a worker shouldn't have its own memory, with at least two of the three problems that causes; tell a router apart from an orchestrator-worker even when they're wired the same way; and spot, in a worker's prompt, the phrases that reveal it was written for the wrong recipient.

What you still don't have is the wire. Everything in this lesson is design: a drawing with arrows and an ownership table. The concrete question — how, physically, do you connect an AI Agent node to another AI Agent node's ai_tool port in n8n 2.0, what parameters that connection has, and what it looks like in the execution trace — is lesson 4's whole topic. It's this module's central lesson.

Resources

• AI Agent node — n8n Docs — reference for the root node and its ai_languageModel, ai_memory, and ai_tool ports; the physical foundation of the split you designed here.
• Memory sub-nodes — n8n Docs — the catalog of memory nodes and their session ID; useful for confirming where to connect the orchestrator's memory.
• Building Effective AI Agents — Anthropic — the article that defines orchestrator-worker, routing, and chaining as distinct patterns, with the criteria for when to use each one.
• What agents do — n8n Docs — the distinction between an agent (decides) and a chain (fixed sequence), which is the same boundary between Form 1 and Form 3 in this lesson.
• Switch node — n8n Docs — for the legitimate case mentioned here: routing on a structured field the customer already picked, where the decision is deterministic and no model is needed.