1. Introduction: agents that delegate

Description

By the end of this lesson you'll be able to explain why a serious 2026 system gets built with several coordinated agents instead of one that tries to know everything, recognize the three concrete signals that your agent has already crossed the line of what it can hold on its own, and you'll have the complete map of this module's eight lessons — including the distinction, which is the heart of everything that follows, between actually delegating and simulating a delegation with manual logic.

This matters because the agent you left built in Module 4 works. It checks the CRM, checks the knowledge base, sends emails, creates tickets, knows when to ask a person for permission. And precisely because of that, it's going to start failing: every time it resolves a new case, someone on the team adds one more tool and one more paragraph to the system prompt. At three tools the agent is precise. At nine, it starts picking the wrong tool, mixing the sales tone with the support tone, and forgetting the rule you wrote two weeks ago because it got buried among twenty others. Nobody broke anything — you just asked a single piece to hold four different responsibilities. This module is the answer to that, and it's also the point where job postings stop talking about "automating with AI" and start talking about "multi-step agent flows."

Connection to the module: this is Module 5's first lesson, and it's pure map. You're not going to connect anything yet. Lesson 2 is going to precisely diagnose why the monolithic agent degrades; lesson 3 gives you the design pattern; lesson 4 — this module's central lesson — shows you the actual wiring: an AI Agent node connected to another AI Agent node's ai_tool port. Everything you're bringing from Module 4 still applies: a tool's contract (lesson 5 of that module) is literally the foundation of the agent-to-agent contract you're going to write in lesson 5 of this one, and the sub-workflow exposed as a tool (lesson 6) is the second delegation mechanism you're going to compare against.

The store that grew and didn't hire anyone else

Think of a neighborhood business that started with a single person at the counter. At first it works perfectly: someone comes in, asks a price, gets it; someone else comes in, wants to return something, it gets handled. One person, every case, zero friction — because the amount of things you need to know fits comfortably in one person's head.

Now the business grew. The same person staffs the counter, handles billing, negotiates with suppliers, resolves complaints, and also tries to sell the new product. It still "works": nobody leaves unattended. But strange things start happening. They explain the return policy to someone who only wanted to know the store hours. They offer the month's promotion to a customer who's angry about a wrong charge. They grab the wrong form because there are five similar forms on the counter. And when you ask them to change a rule — "from now on, electronics returns get 14 days" — you have to trust they'll remember that, specifically that, in the middle of everything else you asked of them.

Nobody would say the solution is hiring a smarter person. The solution is obvious: split the counter from the register, and the register from the complaints desk. Each person with a clear scope, with their own forms on their own desk, and someone up front who listens to what the customer needs and routes them to the right place. That's not "more people for the sake of it" — it's that the work turned into a kind that a single head doesn't hold well, no matter how good that head is.

An AI agent is in exactly that position. The model doesn't "get tired," but it does have a finite attention budget: everything you put in the system prompt and every one of its tool descriptions compete with each other in the same context, on every turn. When you give it four responsibilities and nine tools, you're not giving it more capability — you're giving it more things to get confused between. And unlike the person at the counter, the agent isn't going to tell you "hey, this doesn't fit anymore." It's simply going to start making silent mistakes, in specific cases, and you're going to find out from an angry customer.

The way out is the same as in the business: instead of an omnipotent agent, a team of agents. One that greets the customer and decides what the case is about. Others that each resolve one scope, with their own tools and their own way of responding. And real delegation between them: the first one doesn't "guess" the second one's answer, it asks for it.

Worked example: the same message, two architectures

Let's run a real message from a TuTienda customer against two configurations. The model is the same in both, the available tools are the same in total, and the memory is the same. The only thing that changes is how the work is split up.

Customer's message: "Hi, there's a $1,200 charge on my card I don't recognize, and while I'm at it I wanted to know if order #4521 has shipped yet. Thanks."

Notice this is a perfectly normal and perfectly awkward message: it carries two topics from different domains — one financial and sensitive, the other logistical and trivial — in a single sentence, the way real people talk.

Configuration A — a single agent carrying everything

# Node: AI Agent — Name: support_agent (the Module 4 monolith)
#
# System Message (summarized — the real one is ~900 words):
#   You are TuTienda's support agent. You can resolve questions about
#   orders, charges, returns, and also recommend products.
#   For orders use lookup_order. For charges use lookup_charge and,
#   if the customer doesn't recognize the charge, use open_dispute — but
#   never promise a refund. For returns check the policy:
#   30 days general, 14 days electronics... (6 more paragraphs follow)
#
# Tools connected to the ai_tool port (9):
#   lookup_order, lookup_charge, open_dispute, create_ticket,
#   send_email, check_refund_eligibility, search_knowledge_base,
#   get_customer_profile, recommend_products

What to expect — Configuration A. The agent reads the message and has to resolve, in a single reasoning turn, three things at once: what topics are present, in what order to handle them, and which of nine tools applies to each. In most runs it does fine. But in a non-negligible fraction of cases one of these three things happens:

• It handles only the second topic (the order) because it's the easiest to resolve with a single tool, and the unrecognized charge — the thing the customer actually cares about — goes unanswered.
• It calls check_refund_eligibility instead of open_dispute, because both descriptions talk about "customer who isn't happy with a charge" and the model picks between them by semantic similarity.
• It closes with a product recommendation, because the system prompt also told it to recommend, and nothing in that prompt tells it a customer with a disputed charge isn't the moment for that.

None of those three outcomes trigger an error in n8n. The execution shows up green. The problem only shows up when you read the conversation.

Configuration B — a team with delegation

# Node: AI Agent — Name: triage_agent (the orchestrator)
#
# System Message (summarized):
#   You are TuTienda's first line of support. Your only job is to
#   understand what the customer needs and delegate it to the right specialist.
#   You don't check systems or resolve cases directly.
#   If a message carries more than one topic, delegate each topic separately.
#
# Tools connected to the ai_tool port (3, and all of them are agents):
#   order_specialist    — orders, shipping, status, and deliveries
#   billing_specialist  — charges, disputes, and billing
#   sales_specialist     — recommendations and product questions

# Node: AI Agent Tool — Name: billing_specialist
#
# Tool Description (this is what the triage_agent reads to decide):
#   Resolves any case related to charges, unrecognized charges,
#   disputes, and billing. Use it when the customer mentions a
#   charged amount, a card, or an invoice.
#   Do NOT use it for order status or product returns.
#
# System Message (this agent's own, ~150 words):
#   You are TuTienda's billing specialist...
#
# Own tools (3): lookup_charge, open_dispute, get_customer_profile

What to expect — Configuration B. The triage_agent reads the same message. Its decision is much smaller: it doesn't have to choose between nine tools or remember the return policy, because none of that is in its context. It only has to answer one question: what is this about, and who do I hand it to? It recognizes two topics and delegates twice — first to billing_specialist with the charge issue, then to order_specialist with the order number. Each specialist reasons within its own scope, with its own three tools and its own short system prompt, and returns a result. The triage_agent receives both responses and composes a single message for the customer:

"I checked both things. About the $1,200 charge: it isn't tied to any purchase of yours in the last 60 days, so I opened dispute #D-8842 and the billing team reviews it within 48 business hours. About order #4521: it left the distribution center yesterday and arrives between tomorrow and the day after."

Notice what changed and what didn't. The model is the same. The nine tools still exist, just split up. What changed is that no individual decision is big. Triage picks between three well-separated options; each specialist picks between three tools from the same domain. That's the entire trick, and it's the reason a team of agents gets things right more often than a single agent that knows the same things but has to hold it all together at once.

And notice one more thing, which is going to be lesson 4's thread: in Configuration B, nobody wrote a Switch that said "if the message contains the word 'charge', go to the billing branch." The triage_agent decided to delegate because it read the descriptions of its three agent-tools and chose. That's a decision made by the model, not a condition someone drew in advance.

This module's map

The seven lessons that follow take that example apart piece by piece:

Lesson	What it resolves
2	The diagnosis: exactly what degrades in a monolithic agent and what criterion separates responsibilities
3	The orchestrator-worker pattern: who coordinates, who executes, and when this pattern applies and when it doesn't
4	The actual wiring: connecting an AI Agent node as another agent's tool, with native agentic loops
5	The contract between agents: role, handoff, what goes in, what comes out, and what happens when a specialist can't resolve something
6	Stopping conditions: how to avoid two agents delegating work to each other forever
7	The price of all this: every delegation is another call to the model — how much it costs, how long it takes, and when it's not worth it
8	Mini-project: a triage → specialist system working start to finish, with its handoffs verified

The order isn't arbitrary. Lessons 2 and 3 are about judgment: when to separate and how to split the work. Lesson 4 is about mechanics: the node and the connection. Lessons 5 and 6 are about discipline: without a contract, agents pass garbage to each other; without stopping conditions, they pass garbage to each other forever. Lesson 7 is the honest counterweight — multi-agent isn't free, and there are cases where it's the wrong call. And lesson 8 assembles it all.

By the end of this module you're going to have the concrete capability the module promises: design a system where an orchestrator agent delegates to specialist agents, with clear handoffs and contracts, controlling stopping conditions, cost, and latency. That sentence, almost word for word, is what job postings describe as "designing multi-step agent flows."

Native delegation versus simulated delegation

There's a distinction worth making clear from the start, because it's the reason this module exists and it's where the most Spanish-language material went stale.

For years, the only way to put together "something like a team of agents" in n8n was to simulate it. The pattern was this: a first AI node classified the message and returned a label — "billing", "orders", "sales" — a Switch node read that label and routed the flow down one of three branches, and each branch had another AI node with its own prompt. It worked, in the sense that it produced responses. But look closely at what it actually was:

# The OLD (simulated) pattern — NOT what you're going to build
Chat Trigger
  → AI (classifier that returns a text label)
  → Switch (3 fixed branches, hand-written)
      ├── "billing" branch → AI with a billing prompt
      ├── "orders" branch  → AI with an orders prompt
      └── "sales" branch   → AI with a sales prompt
  → (and here someone had to manually figure out how to merge everything back)

Three things about that diagram aren't delegation:

1. The path is fixed in advance. The three branches exist before the first message arrives. If the customer brings a case that doesn't fit any of them, there's nothing to be done; and if they bring two topics at once, like the example above, the Switch takes exactly one branch by definition.
2. There's no way back. Once the flow entered the billing branch, there's no natural way for the result to return to whoever decided, so that they can decide whether something else is needed. Every return trip has to be programmed with extra nodes.
3. There's no agentic loop between the pieces. The classifier can't ask for a clarification, receive it, and decide again. It emits a label and that's the end of its involvement.

The native delegation you're going to build in lesson 4 doesn't have those three limitations, because the specialist isn't a branch: it's a tool. And a tool, as you learned in Module 4, gets called when the model decides, with arguments the model builds, as many times as the model considers necessary, and its result comes back to the agent that called it so it can keep reasoning with that information in hand. When that tool is itself a complete agent — with its own model, its own prompt, and its own tools — what you have is an agentic loop inside another agentic loop. That's what n8n 2.0 allows natively, and it's what material written before this capability existed simply couldn't teach.

If at any point in this module you catch yourself drawing a Switch to split work between agents, stop: that's the old pattern, and lesson 4 is going to give you the version that actually scales.

One honest clarification before moving on: this does not mean IF and Switch are banned in n8n or that they're bad nodes. They're excellent for deterministic logic — "if the ticket is from a premium customer, notify the VIP channel" — where you, not the model, must decide the path. What this module is saying is more precise: don't use deterministic logic to make a decision that depends on understanding natural language. That decision belongs to the model, and the mechanism for handing it over is a tool.

Common mistakes

Believing "multi-agent" means "more agents is better" (conceptual). What happens: someone reads this module, goes back to their workflow, and splits an agent that worked fine into five specialized agents, one per tool it had. The system gets slower, more expensive, and on top of that less accurate, because now there are five information handoffs where before there were zero. Why it happens: the phrase "multi-agent architecture" sounds like an improvement all by itself, and it's easy to confuse a design pattern with a goal. How to spot it: count how many tools your original agent had and how many distinct responsibilities it covered; if it was three tools from the same domain and a single responsibility, you didn't have a problem delegation solves. How to fix it: wait for lesson 2, which gives you the concrete signs of saturation, and lesson 7, which puts numbers on the table — delegating costs calls to the model, and that cost needs to buy you something real.

Thinking the orchestrator "is the one who knows" and the specialists just execute (conceptual). What happens: someone writes a triage_agent with an 800-word system prompt that explains the return policy, billing rules, and the product catalog, and then connects specialists with two-line prompts. The result is the monolith again, just with extra steps. Why it happens: it's intuitive to think of the orchestrator as "the boss" and assume the boss has to know more than everyone else. How to spot it: if your orchestrator's system prompt mentions a specific business rule — a deadline, an amount, a policy — that rule is in the wrong agent. How to fix it: the orchestrator knows who does what, not how each thing gets done; domain knowledge lives in the specialist that uses it, and that split is exactly what you're going to formalize in lesson 5.

Starting to build the mini-project's system before Module 4 is finished (practical). What happens: you get to lesson 4 eager to connect agents to each other, but the base agent you're bringing doesn't have either real tools connected or contracts written down, so when the specialist fails you can't tell whether the problem is the delegation or the tool underneath. Why it happens: delegation is the eye-catching part of the module and gives the sense that you can skip straight to it. How to spot it: if you can't point, in your workflow, to at least two tools with their Description written out and their $fromAI() with a description per parameter, you're still missing Module 4. How to fix it: a multi-agent system inherits every problem its tools have, multiplied by the number of agents — solve the tools layer first and this module gets much simpler.

Exercises

Exercise 1 — Count your agent's responsibilities. Take the system prompt of the agent you built in Module 4 (or this lesson's Configuration A) and underline every sentence that starts a distinct responsibility: "resolves order questions," "recommends products," "applies the return policy." Count how many there are. Then count how many tools it has connected. Write down both numbers.

See solution

For this lesson's Configuration A: four responsibilities (orders, charges, returns, product recommendation) and nine tools. There's no magic threshold — lesson 2 gives you the real signals — but two numbers like these already tell you something: every time the agent reasons, it has to hold four different mental frames and choose between nine options, all in the same context.

If your own agent came out "one responsibility, three tools," you're in the comfortable zone and this module serves as a design for when it grows, not an urgent repair. If it came out "four and nine" or more, you're already in lesson 2's territory.

Why it works: the exercise turns a vague intuition ("my agent is getting complicated") into two numbers you can re-measure after separating, and compare.

Exercise 2 — Split the message. This message arrives in TuTienda's chat: "hi, I want to return the headphones I bought last month because I didn't like them, and while I'm at it, do you have something similar but with noise cancellation? my budget is up to $800." With Configuration B's team (order_specialist, billing_specialist, sales_specialist), who would the triage_agent delegate to, in what order, and what would happen to each?

See solution

Two delegations. First to order_specialist, which is who handles product returns — the message talks about returning something bought a month ago, and there's a deadline rule that needs checking there. Then to sales_specialist, with the recommendation request and the $800 budget.

The order matters for a practical reason: the first delegation's response can change the meaning of the second. If the headphones turn out to be past the return window (they're electronics, 14 days), the recommendation for a replacement product gets framed differently — "we can't accept the return, but if you want to switch devices, here's what we have" — than if the return does go through.

What the triage_agent does NOT do is resolve either thing on its own. It doesn't check the deadline, it doesn't look at the catalog. Its final response is the composition of what the two specialists sent back.

Why it works: the exercise shows that "delegating" isn't "picking a branch." The same message can trigger two delegations, in an order the model decides, with the second one informed by the first one's result — something a Switch can't do by construction.

Exercise 3 — Spot the old pattern. Someone shares this workflow with you and tells you it's "a multi-agent system":

Chat Trigger
  → Basic LLM Chain (classifies and returns "support" | "sales")
  → Switch (2 branches based on the returned text)
      ├── "support" branch → AI Agent with support tools
      └── "sales" branch    → AI Agent with sales tools

Name at least two concrete things this design can't do that native delegation can.

See solution

Three valid answers, two is enough:

1. It can't handle a message with two topics. The Switch takes one branch and only one. A customer asking about a charge and an order in the same message is going to end up with half their case unanswered.
2. It can't decide again with new information. If the support agent discovers halfway through that the case is actually a sales one, there's no way for the flow to go back to the classifier: it already went through the Switch, and that node doesn't execute twice on the same path.
3. It can't compose a single response. Each branch ends in its own agent, and merging two results into one message to the customer requires extra hand-written nodes, with their own logic for "what do I do if a branch didn't run."

Why it works: all three limitations come from the same root — the path is decided before the case is known. In native delegation the specialist is a tool, and a tool can get called zero, one, or several times, in whatever order the reasoning requires, with the result always returning to whoever called it.

Summary and next step

What you saw in this lesson is the complete framework before the first wire: a monolithic agent degrades not because the model is bad, but because you asked it to hold several responsibilities and many tools in the same context; the way out is a team where each agent makes small decisions within a clear scope; and the difference between actually delegating and simulating it with a Switch is that in native delegation the specialist is a tool the model chooses to call, whose result comes back to whoever called it.

Before moving on to lesson 2 you should be able to: explain in one sentence why Configuration B gets things right more often than Configuration A even though they share the same model and the same nine tools; name the three things a Switch can't do that a delegation can; and say how many responsibilities and how many tools your own agent has today.

What you don't have yet is the precise criterion. "Four responsibilities and nine tools" sounds like a lot, but a lot compared to what? What exactly degrades, and at what concrete signal is it worth separating? That's lesson 2: the monolithic agent's diagnosis, and the rule for cutting in the right place.

Resources

• What agents do — n8n Docs — n8n's official definition of an agent, the foundation this module builds the idea of an agent calling another agent on.
• AI Agent node — n8n Docs — reference for the root node and its ai_tool port, which in lesson 4 you're going to use to connect a complete agent instead of a simple tool.
• How tools work — n8n Docs — how the model picks a tool from its description; the same mechanism that decides which specialist to delegate to.
• Building Effective AI Agents — Anthropic — the article that popularized orchestrator-worker vocabulary and the warning against adding multi-agent complexity without a measurable reason.
• Switch node — n8n Docs — the old pattern's node; worth knowing well so you know exactly where it does apply (deterministic logic) and where it doesn't (deciding with natural language).