Module 5: Multi-Agent Systems: Agents That Delegate Tasks

2. Why one agent isn't enough: separating responsibilities

Next →

Description

By the end of this lesson you'll be able to diagnose, with concrete signals verifiable in n8n's execution panel, which of the four degradation modes a monolithic agent is suffering from; you'll be able to decide where to cut using an explicit rule — one responsibility, one exit criterion — instead of cutting by intuition; and you'll be able to defend, with that same criterion, when you should NOT separate and a single agent is still the right answer.

This matters because the previous lesson left you with an intuition ("my agent has too much on its plate") and an intuition can't be argued in a meeting or verified in a log. If you tell your team "we need to split the agent into three" and they ask why, "because it has too many tools" isn't an answer: it's an impression. Whereas "in the last 40 executions, the agent chose check_refund_eligibility in 6 cases where the customer was talking about a charge, not a return, and the two descriptions overlap on the phrase 'customer isn't happy'" is a diagnosis. This lesson gives you the way to get to that second sentence. And it also gives you the opposite discipline, which matters just as much: separating has a real cost in money and response time — lesson 7 puts numbers on it — so you need to be able to justify every cut, not just wish for it.

Connection to the module: lesson 1 showed you the contrast between a monolithic agent and a team, and gave you the map. This lesson is the diagnosis: exactly why the monolith degrades, and what rule decides the cut. Lesson 3 takes that cut's result — a set of separated responsibilities — and shapes it into an architecture with the orchestrator-worker pattern. You're still not going to connect one agent to another; that's lesson 4. Here you work with paper and with logs.

A desk with too many forms

Go back to the counter person from the previous lesson, but this time look at their desk instead of them. On the desk there are nine forms. Three are for orders, two for charges, two for returns, one for complaints, and one for enrolling someone in the points program. They all look similar: same size, same letterhead, two-word headers that say things like "Review Request" and "Adjustment Request."

Now imagine a customer arrives and says, talking fast: "I got charged for something I didn't buy." The person has to do two things at once: understand the case, and choose the form. If the nine forms were clearly separated — three in a drawer labeled ORDERS, two in another labeled CHARGES — the second task would be trivial. But all nine are together on the table, and two of them say almost the same thing. The person is going to get it right most of the time. And they're going to fail some of the time, not for lack of judgment, but because you put two nearly identical objects next to each other and asked them to tell them apart on the fly.

An AI agent lives exactly that scene on every turn. The difference with the person is that the forms don't arrive one at a time: all the descriptions of all its tools get presented together, in the same context, on every call to the model. And alongside them goes the complete system prompt, with all its rules. The model doesn't read "the relevant part" — it reads everything and chooses. The bigger and more similar to each other that set is, the easier it is for the choice to go wrong.

That's not a defect in the model that a better model fixes. It's a property of how the choice works: the agent semantically compares what the user asked for against the text of every available description. If two texts look alike, the signal gets split between both. If the system prompt has twenty rules, rule number seventeen competes with the other nineteen for the model's attention on that turn. A more capable model improves the average, it doesn't eliminate the phenomenon.

The four degradation modes

When someone says "my agent started failing," they're almost always looking at one of these four. It's worth having a name for each one, because the cut that fixes one doesn't necessarily fix the others.

1. Tool collision

Two or more tools whose descriptions semantically overlap, and the model chooses between them inconsistently.

What it looks like. In the execution panel, the same kind of message triggers different tools on different runs. Or worse: it consistently triggers the wrong tool, because that tool's description happens to resemble how real customers talk more closely.

Example at TuTienda. The agent has these two:

# Tool 1 — Name: check_refund_eligibility
# Description: "Checks whether a customer can get money back
#               for a purchase they weren't happy with."

# Tool 2 — Name: open_dispute
# Description: "Opens a dispute when the customer doesn't recognize or
#               isn't happy with a charge on their card."

Both contain the phrase "isn't happy." One is about returning a product; the other is about a charge the customer doesn't recognize. To a person these are obvious, distinct cases. To a model comparing texts, they're two descriptions with 40% shared vocabulary.

Why the cut fixes it. If check_refund_eligibility lives in the order_specialist and open_dispute lives in the billing_specialist, the model never sees them together. At the moment the billing specialist reasons, check_refund_eligibility doesn't exist in its context — there's nothing to collide with.

Watch out: part of this problem gets solved without separating agents, just by writing better descriptions, which is what you learned in lesson 5 of Module 4. Before splitting an agent over tool collision, try fixing the descriptions first. If that's enough with two or three tools, you don't need a team. If you have nine tools from four different domains, writing mutually exclusive descriptions across all nine becomes an impossible exercise: every time you clarify one, it overlaps with another.

2. Prompt dilution

The system prompt grew to the point where a specific instruction loses strength against the rest of the text.

What it looks like. A rule you wrote and tested weeks ago stops being followed, without anyone deleting it. It's typically an exception rule — "for electronics the deadline is 14 days, not 30" — or a prohibition — "never offer discounts." The agent respects it most of the time and ignores it some of the time, almost always when the conversation ran long or when the customer pushed back.

Example at TuTienda. This is the monolithic agent's system prompt, summarized to its headers:

# support_agent's System Message (~900 words total)
#
#   You are TuTienda's support agent. Warm tone, brief
#   responses.
#
#   ORDERS: use lookup_order with the number the customer gives. If the
#   order has been in transit more than 5 business days, apologize
#   and offer follow-up. Never promise an exact delivery date.
#
#   CHARGES: use lookup_charge. If the customer doesn't recognize the
#   charge, first check the profile with get_customer_profile in case
#   they bought under another name. Only then use open_dispute. Never
#   promise a refund or a resolution deadline.
#
#   RETURNS: the general deadline is 30 days. For the
#   electronics category the deadline is 14 days. Personal hygiene
#   products aren't eligible for return. Always verify with
#   check_refund_eligibility before confirming anything to the customer.
#
#   SALES: if the customer asks about products, use
#   recommend_products. Respect their budget if they mention one.
#   Don't recommend more than three products per response.
#
#   ESCALATION: if the customer asks to talk to a person twice,
#   create a ticket with create_ticket and let them know.
#
#   (…and six more paragraphs of accumulated special cases)

Count the prohibitions: "never promise an exact date," "never promise a refund," "don't recommend more than three products," "hygiene products aren't eligible for return." That's four negative rules scattered across 900 words, each belonging to a different domain. On a turn where the customer is talking about a charge, the three rules from the other domains are occupying context without contributing anything — and the billing rule that actually matters is competing with them.

Why the cut fixes it. The billing_specialist's system prompt is 150 words and contains exactly the billing rules. No return rules, no sales rules. That rule isn't competing with anything anymore.

3. Role contamination

The agent mixes the register, tone, or intent of one domain with another, because a single system prompt asked it to be several people at once.

What it looks like. It's the hardest mode to spot in a log, because there's no tool called wrong — the response is technically correct and still wrong. The classic case: a customer angry about a charge gets, at the end of the response, a product recommendation. The agent didn't pick the wrong tool: the prompt told it to recommend when it can, and nothing told it a customer in a dispute isn't the moment.

Example at TuTienda. With the prompt above, this response is perfectly consistent with the instructions:

"I've already opened the dispute for the $1,200 charge you didn't recognize, the team will review it soon. By the way, I noticed you're interested in headphones — we have three new models you might like."

Nobody wrote an instruction that prevents that. And writing one is harder than it looks, because you'd have to enumerate every forbidden combination of domains: don't sell during a dispute, don't sell during a shipping complaint, don't sell when the customer asked to talk to a person. Every new rule is one more line diluting the prompt — mode 2 getting worse while you try to fix mode 3.

Why the cut fixes it. If sales_specialist is a separate agent, it doesn't run unless someone calls it. The triage_agent isn't going to call it in a dispute case, because its job is to read the customer's intent and that intent wasn't to buy. The prohibition stops being a rule in a prompt and becomes a consequence of the architecture.

4. Blast radius

A single agent with all the tools means any message that manages to influence it can potentially reach every action in the system.

What it looks like. It doesn't look like anything, until it does. It's the silent mode. If a message from the customer — or the content of an email the agent read with a tool, which is worse — manages to push the agent toward an action it shouldn't have taken, the set of actions available for that push is the full set of nine tools. A sales agent that can also open disputes and create tickets has a much bigger blast radius than one that can only recommend products.

Example at TuTienda. The monolithic agent can, in the same turn, read a customer's profile (get_customer_profile), open a dispute (open_dispute), and send an email (send_email). Nothing in the architecture stops those three from being combined into a sequence nobody designed.

Why the cut fixes it. Each specialist only has the tools from its own domain. The sales_specialist can't send emails because it doesn't have that tool connected — not because the prompt forbids it, but because it's physically not on its ai_tool port. That's the difference between a text restriction and a structural restriction, exactly the same distinction you drew in lesson 5 of Module 4 with trust boundaries.

This fourth mode has an entire module dedicated to it later in this guide — the security one — so here we're just naming it as one more design reason to separate. What matters to hold onto now: separation by responsibility is also a separation of permissions, and that's a benefit you get for free when you cut correctly.

Worked example: reading the four modes in a log

Let's diagnose the TuTienda agent with data, not impressions. Suppose you review the last 40 executions in n8n's panel. To do it right, you need one thing turned on in the AI Agent node:

# Node: AI Agent — Name: support_agent
# Options:
#   returnIntermediateSteps = true

Return Intermediate Steps makes the agent's output include, besides the final text, an array with every action it took before responding: which tool it called, with what arguments, and what it got back. Without this you only see the result; with this you see the reasoning broken into steps. It's your main diagnostic instrument throughout this module.

With that turned on, this is what you find in the 40 executions, and what mode each finding indicates:

Finding in the logModeWhat confirms it
6 of 11 messages about charges called check_refund_eligibility instead of open_dispute1 — tool collisionThe two descriptions share "isn't happy"; the choice is split
3 responses confirmed an electronics return 22 days after purchase2 — prompt dilutionThe 14-day rule exists in the prompt and wasn't applied; the general 30-day one was
4 responses to customers with an open dispute ended with a product recommendation3 — role contaminationNo tool called wrong; the problem is the register, not the action
In 1 execution the agent called send_email with a body quoting text from an incoming email4 — blast radiusThe read tool fed a write tool in a sequence nobody designed

What to expect. That table is a defensible diagnosis. With it you can say: "of 40 executions, 13 had a defect attributable to the agent holding four domains at once, and the defects are of three distinct kinds that don't get fixed with the same correction." That's very different from "I think it has too many tools."

Notice something uncomfortable too: all four rows show up in the log, but none of the 40 executions shows up marked as failed in n8n. All of them ran without error. The four degradation modes are invisible to the execution engine, because they aren't technical failures — they're decisions the model made that turned out to be the wrong ones. That's why the diagnosis requires reading conversations, not reading status indicators.

Where to cut: by responsibility, not by task

You already know you need to separate. What's missing is the hard part: where. And it's hard because there's a strong, wrong temptation: cutting by task.

Cutting by task means creating one agent per thing the system does: an agent that looks up orders, an agent that sends emails, an agent that creates tickets. It sounds tidy and it's a mistake, for two reasons. First, because an agent that only calls one tool isn't making any interesting decision — it's a tool with a model layer on top, which costs a call to the model and adds no judgment. Second, because real cases don't arrive split by task: they arrive split by domain. A customer doesn't say "I need an order lookup followed by an email send"; they say "where's my order?"

Cutting by responsibility means something else: grouping everything it takes to close out one type of case from start to finish. The order_specialist isn't "the one that looks up orders" — it's "the one that resolves anything related to an order until it's closed," which includes looking it up, evaluating whether the delay warrants an apology, checking a return, and creating a ticket if it can't resolve it.

The operating rule that helps you decide is this:

A responsibility is a scope with a single exit criterion. If you can write in one sentence "this agent finishes its work when ___," and that sentence doesn't have an "or" inside it, you have a responsibility.

Apply it:

  • "The order_specialist finishes when the customer knows their order's real status, or when a ticket got logged because it couldn't be determined." — That "or" is acceptable: they're two endings of the same case, one successful and one an escape hatch. It's a responsibility.
  • "The support_agent finishes when the customer knows their order's status, or when a dispute was opened, or when they got a product recommendation." — That "or" separates three cases that have nothing to do with each other. They're three responsibilities disguised as one.

The three-question test

Before creating a new agent, answer these three. If any of them is hard, you don't have a well-trimmed responsibility yet:

  1. What's its single exit criterion? One sentence, with no "or" separating domains.
  2. What tools does it need, and only it? If two candidate agents need the same action tool — not a read tool, an action one — check whether they're actually one agent. Sharing a read tool like get_customer_profile is normal; sharing open_dispute is a sign the cut is done wrong.
  3. What does someone have to tell it for it to start working? If the answer is "the customer's full message, as is," it's not a specialist yet — it's another generalist. A specialist receives a bounded assignment. This is the input contract, and you formalize it in lesson 5.

The symptom-to-cut table

Symptom you observeModeFirst fix to tryDoes it justify separating agents?
Two tools from the same domain get confused with each other1Rewrite the descriptions to be mutually exclusiveNo
Tools from different domains get confused with each other1Rewrite descriptions — and if it persists, separateYes, if it persists
An exception rule sometimes gets ignored2Shorten the prompt by removing what doesn't apply to that domainYes, if the prompt can't be shortened without losing domains
The tone or intent of one domain leaks into another3No text fix works wellYes
A sensitive action tool is available in contexts where it shouldn't be4Human review (Module 4, lesson 5) as the first barrierYes, in addition to human review
The agent responds well but takes a long time and calls many toolsnoneReview the prompt and Max IterationsNo — separating would make it slower

That last row matters and we'll come back to it in lesson 7: separating doesn't speed anything up. Quite the opposite. If your problem is latency or cost, delegation is exactly the wrong direction.

When NOT to separate

Three cases where a single agent is still the right answer, and it's worth being able to defend them:

A single domain, even with many tools. An agent that looks up orders, checks shipping status with the carrier, calculates the delay, and creates a follow-up ticket has four tools and one responsibility. Don't split it. All four tools belong to the same exit criterion, and their descriptions can be made mutually exclusive without acrobatics.

Low volume and a one-person team. A multi-agent system is harder to debug: when something goes wrong, you first have to figure out at which level it went wrong. If your agent handles twenty conversations a day and you're the only one maintaining it, the cost of that complexity can outweigh the benefit of precision, even with symptoms of dilution present.

When the work is deterministic. If what you want to encapsulate requires no judgment at all — querying a database, applying a deadline rule with a fixed formula, calculating an amount — that's not an agent, it's a sub-workflow. You already built one in lesson 6 of Module 4, and it's still the right answer: it costs zero calls to the model, it's predictable, and it can be tested with fixed data. Save agents for where something genuinely needs to interpret language or choose between paths.

Worked example: TuTienda's cut

Let's take the monolithic system prompt from above and apply the rule. First, the candidate responsibilities with their exit criterion:

# Responsibility A — orders and product returns
#   Exit criterion: the customer knows their order's real status
#   or the result of their return request (approved / not
#   approved / logged as a ticket).
#   Tools: lookup_order, check_refund_eligibility, create_ticket

# Responsibility B — charges and billing
#   Exit criterion: the charge got explained or a dispute got
#   opened with its reference number.
#   Tools: lookup_charge, open_dispute, get_customer_profile

# Responsibility C — product recommendation
#   Exit criterion: the customer got up to three options that
#   respect their budget and their stated need.
#   Tools: recommend_products, search_knowledge_base

# Responsibility D — understanding what the customer needs and routing
#   Exit criterion: every topic in the message got handled by the
#   right specialist and the customer got a single response.
#   Tools: A, B, and C (the other three agents)

Now check the list against the three questions:

  • Single exit criterion: all four pass. A has an "or" but it separates endings of the same case, not domains.
  • Own tools: create_ticket only shows up in A. get_customer_profile is only in B, though it would be reasonable for A to also check it — if A needs it later, it's a read tool and sharing it doesn't break anything. send_email dropped out of the split entirely: looking at the original prompt, it was only used to confirm actions that each specialist can now report in its own response. A tool that finds no owner in any cut is almost always a tool that wasn't needed.
  • What it needs to start: A needs an order number or a product description. B needs an amount and an approximate date. C needs a need and, if there is one, a budget. D needs the customer's raw message — and it's the only one that needs it, because it's the one that translates customer language into concrete assignments.

Now compare B's prompt against the monolith:

# billing_specialist's System Message (~140 words)
#
#   You are TuTienda's billing specialist. You resolve charges
#   the customer doesn't recognize, amount questions, and dispute
#   requests. You don't handle product returns or shipping status.
#
#   Procedure: use lookup_charge with the amount and the approximate
#   date. If it doesn't show up, check get_customer_profile in case
#   the purchase was made under another name or with another card
#   from the same customer. Only if it still doesn't show up, use
#   open_dispute.
#
#   Never promise a refund or a resolution deadline. You can
#   confirm the dispute got opened and its reference number.
#
#   Always return: what you found, what action you took, and whether the
#   case is closed or pending.

What to expect. A hundred forty words versus nine hundred. Three tools versus nine. A single prohibition ("never promise a refund or a deadline") instead of four scattered ones. When this agent reasons about a charge, there's no return rule and no sales instruction occupying its context. Modes 1, 2, and 3 don't disappear by magic — you can still write one of the three tools' description badly — but the space where they can occur shrank to a fraction.

And notice the prompt's last line: "Always return: what you found, what action you took, and whether the case is closed or pending." That line wasn't in the monolith and it isn't decorative. It's the first sketch of the output contract the specialist owes to whoever called it — lesson 5's whole topic.

Common mistakes

Cutting by task instead of by responsibility (conceptual). What happens: someone creates an email_agent, a database_agent, and a ticket_agent, one per connected system. The result is a system where the orchestrator has to know each case's full sequence — first look up, then evaluate, then send the email — because none of the three specialists knows how to close out a complete case. The orchestrator turns back into the monolith, with the extra cost of three calls to the model. Why it happens: cutting by system is the most visible partition on the canvas, because the nodes are already grouped that way. How to spot it: try writing each agent's exit criterion; if what comes out is "finishes when it sent the email" instead of "finishes when the customer knew their case's status," you cut by task. How to fix it: start from the types of cases that arrive at the system, not from the connected systems; group by "what does the customer need" and let the tools fall wherever they fall.

Separating over symptoms of latency or cost (conceptual). What happens: the agent takes fifteen seconds to respond, someone concludes "it's overloaded" and splits it into three, and now it takes thirty. Why it happens: the word "overloaded" makes you think of a capacity problem, like a saturated machine, when actually the monolith's degradation is one of accuracy, not speed. How to spot it: check intermediateSteps and count how many tools the agent called before responding; if there are many, your problem is the prompt or Max Iterations, not architecture. How to fix it: lesson 7 puts the numbers on the table — every delegation adds at least one full call to the model, in series — and makes clear that separating always adds latency; if your problem is response time, the fix is in the prompt, the model, or the tools, not the team.

Treating the diagnosis as given without reading a single log (practical). What happens: someone reads this lesson, recognizes the four modes, and redesigns the entire system based on "I'm probably hitting mode 2." After the separation, the real problem — which was a tool with a badly written Description — is still there, now spread across two agents. Why it happens: the four modes are recognizable and sound like a diagnosis the moment you read them, without needing evidence. How to spot it: if you can't cite a specific execution number where the defect you claim to have occurred, you don't have a diagnosis. How to fix it: turn on returnIntermediateSteps, review between 20 and 40 real executions, and build the findings table from the worked example before moving a single node; one afternoon's work saves you redesigning twice.

Leaving the orchestrator with domain knowledge "just in case" (practical). What happens: when separating, someone copies the entire old system prompt into the triage_agent "so it has context," and connects the specialists on top of that. Now the system has the monolith's diluted prompt plus the cost of the delegations. Why it happens: removing text from a prompt that worked feels risky, and "more context can't hurt" sounds reasonable. How to spot it: search the orchestrator's prompt for any number, deadline, amount, or policy name; none of those should be there. How to fix it: the orchestrator only needs to know which specialists exist and when to call each one — its prompt should be writable without knowing a single one of TuTienda's business rules.

Exercises

Exercise 1 — Classify the degradation mode. For each of these four findings in a log, say which of the four modes it indicates and why:

(a) The agent confirms a return is approved and two turns later says it isn't, with the same data. (b) A customer reporting they never received their order ends the conversation with a spontaneously offered discount coupon. (c) lookup_charge and lookup_order get called interchangeably when the customer mentions "my purchase." (d) The agent read an incoming email with a tool and in the same turn used send_email to forward part of that content to another address.

See solution

(a) Mode 2, prompt dilution. The deadline rule exists but isn't applied consistently; the inconsistency between turns is the telltale sign of an instruction competing with others for attention. It could also be mode 1 if there are two eligibility tools, so the next step is checking intermediateSteps to see whether the same tool got called both times: if so, it's dilution; if not, it's collision.

(b) Mode 3, role contamination. No tool was called wrong. The agent did something perfectly allowed by its prompt — it was friendly and offered value — in a context where no designer would have wanted it. It's the mode no text fix repairs completely.

(c) Mode 1, tool collision. The word "purchase" is equally compatible with an order and with a charge. Here the first fix isn't separating: it's rewriting both descriptions to be mutually exclusive ("use this tool only when the customer mentions an amount or a card," "use this tool only when the customer mentions an order number or a shipment").

(d) Mode 4, blast radius. A read tool fed a write tool in a sequence nobody designed. It's the silent mode, and it's also the entry point for the security problem Module 7 covers in depth.

Why it works: the four modes are distinguished by where the defect shows up — in the tool choice (1), in a rule being followed (2), in the response's register (3), or in the combination of actions (4). Naming the mode tells you which fix to try first.

Exercise 2 — Apply the exit-criterion rule. A team proposes these five agents for a restaurant reservation system. For each one, write its exit criterion in one sentence and decide whether it's a legitimate responsibility or whether it needs to be merged with another:

(a) booking_agent — creates reservations. (b) availability_agent — checks available tables. (c) cancellation_agent — cancels reservations. (d) menu_agent — answers questions about the menu, allergies, and ingredients. (e) triage_agent — greets the customer and routes.

See solution

(a), (b), and (c) are a single responsibility, not three. Write (b)'s exit criterion: "finishes when it returned the list of available tables". That doesn't close out any customer's case — nobody writes to a restaurant to receive a list of tables. It's a task, not a responsibility. Same with (a) and (c): creating and cancelling are two actions in the same scope, and a customer who wants to change their reservation needs both in the same reasoning pass. The right cut is a reservations_specialist with exit criterion "finishes when the customer's reservation is in the state they asked for: created, modified, cancelled, or logged as impossible due to lack of availability", with all three tools inside.

(d) is indeed a separate responsibility: its exit criterion — "finishes when the customer has the menu, ingredient, or allergy information they asked for" — shares no tools or knowledge with reservations, and the allergy domain has its own rules that you don't want diluted in a reservations prompt.

(e) is a legitimate responsibility, the orchestration one: "finishes when every topic in the message got handled by the right specialist and the customer got a single response".

Result: three agents, not five.

Why it works: the question "does this close out a real customer's case?" separates tasks from responsibilities better than any intuition about how important each action sounds. Checking availability is extremely important and still closes out nothing.

Exercise 3 — Defend not separating. A dental clinic's agent handles a single type of case: scheduling, rescheduling, and cancelling appointments. It has six tools: check_availability, create_appointment, reschedule_appointment, cancel_appointment, get_patient_record, and send_confirmation. The team wants to split it into three agents "because it has too many tools." Write the defense for not separating it, using this lesson's criterion, and say what evidence would change your mind.

See solution

The defense: the six tools belong to a single exit criterion — "finishes when the patient's appointment is in the state they asked for, or it got logged that it wasn't possible". There aren't two domains that could contaminate each other (mode 3), there aren't business rules from different scopes competing in the prompt (mode 2), and the six descriptions can be made mutually exclusive without acrobatics because every action is clearly distinct: check, create, move, cancel, read history, confirm. The number of tools isn't the criterion; the number of responsibilities is, and here it's one. Separating would add latency and cost (lesson 7) in exchange for nothing.

The evidence that would change the decision: concrete findings in the log for modes 1, 2, or 3. For example, if reschedule_appointment and cancel_appointment get systematically confused, the first fix is rewriting their descriptions, not separating. But if a new domain gets added to the clinic — "and it also answers questions about prices and financing plans" — then a second responsibility does show up, with its own rules and its own tone, and the cut is justified.

Why it works: being able to defend a "no" with the same criterion you defend a "yes" with is what separates a design criterion from a fad. Multi-agent is a tool with a cost; you use it when it buys something measurable.

Summary and next step

You now have the diagnosis. A monolithic agent degrades in four distinct ways: tool collision (picks wrong between similar descriptions), prompt dilution (a specific rule loses strength among many), role contamination (mixes one domain's register with another's), and blast radius (every action stays available at all times). All four are invisible to n8n's execution engine, so you diagnose them by reading conversations with returnIntermediateSteps turned on, not by looking at status indicators. And the cut gets made by responsibility — a scope with a single exit criterion — not by task or by connected system.

Before moving on you should be able to: name the four modes and say what evidence confirms each one; write a candidate agent's exit criterion and spot whether it has an "or" that's actually separating domains; and defend why an agent with six tools from a single domain doesn't get separated.

What you still don't have is the shape of the resulting system. You have four trimmed-down responsibilities — three specialists and an orchestrator — but not an architecture: who's in charge, who talks to the customer, who keeps the conversation's memory, and what happens when a specialist can't resolve something. That distribution of roles has a name and a known pattern, and it's what lesson 3 puts together: orchestrator and workers.

Resources

← Previous1. Introduction: agents that delegateNext →3. The orchestrator-worker pattern