n8n Multi-Agent Orchestration: One Orchestrator, Many Sub-Agents (2026)

You built one n8n AI Agent, it worked, so you kept adding tools. Now it has a dozen tools, a 600-word system prompt, and it picks the wrong tool at least once every few runs. n8n multi-agent orchestration replaces that monolith with a coordinator agent that routes each job to a small, specialized sub-agent, one that does exactly one thing and runs on exactly the right model.

The symptoms are predictable. Your flagship Claude Sonnet run costs the same whether the task is a five-word data lookup or a full research report. One broken API key kills the whole workflow. Debugging means sifting through a single giant execution trace. The fix is structural, and n8n ships the exact nodes for it today.

What is multi-agent orchestration in n8n?#

Multi-agent orchestration in n8n is a hierarchical setup where one coordinator AI Agent receives a task and decides which specialized sub-agent should handle it, rather than trying to do everything itself. n8n's own documentation calls this a multi-agent system (MAS) with a supervisor pattern: a main agent coordinates two or more specialized sub-agents, each focused on a narrow domain.

The coordinator sits at the top. It holds no domain-specific tools itself. Its only job is to look at incoming work and route it correctly. Sub-agents sit below, each with a short tool list, a tight system prompt, and a model chosen for their specific workload.

Why does one giant agent with many tools get worse?#

A monolith agent degrades in three ways as you add tools, and n8n's multi-agent guide names all three. Tool selection gets harder as the list grows, so the model makes more routing mistakes. Every task runs on the same model, so you pay flagship prices for trivial steps. And when one tool fails, the whole agent stops.

There is no cost lever inside a monolith. You cannot put a cheap model on simple subtasks because there are no subtasks. Everything shares one model and one context window.

Orchestration isolates failures and opens the model-matching cost lever.

That isolation point matters more than it looks. When a single agent goes down because a third-party API returned a 500 error, every task in that queue stops. With an orchestrated setup, only the one sub-agent that calls that API is affected. The coordinator can still route work to the other sub-agents while you fix the broken one.

How do you attach a sub-agent in n8n?#

You have two nodes for this, and they behave differently. The Call n8n Workflow Tool sub-node attaches an entire n8n workflow to the coordinator as a callable tool. The AI Agent Tool sub-node attaches one AI Agent directly to another as a tool. Both nodes sit in the coordinator's tool lane.

The coordinator picks which sub-agent to call based on the Description field you write on each tool. That description is the routing mechanism. "Use this tool when the user asks for web research or document retrieval" is actionable. "Use this tool for research" is too vague and will cause mis-routing.

The Execute Sub-workflow node is a common point of confusion. It is a regular workflow node, not an AI tool sub-node. It runs because you wired it to run. The Call n8n Workflow Tool runs only when the coordinator AI decides to call it. One is deterministic; the other is AI-driven. Use Execute Sub-workflow when the sequence is fixed; use Call n8n Workflow Tool when you want the agent to decide.

When should you split into sub-agents instead of using one agent?#

Split into sub-agents when one agent has around 5 or more tools, when your tasks span very different difficulty levels, or when you want a cheap model on the simple work. Keep one agent when the task is simple, stays in one domain, and needs fewer than 5 tools. Orchestrating a genuinely simple workflow just adds maintenance overhead.

Use this check before you add any orchestration layer.

A weekend refactor from one overloaded agent to a routed system.

The n8n multi-agent guide puts it plainly: "a generalist agent that processes a simple data validation task uses the same costly model as complex multi-step reasoning." If your tasks never differ in complexity, one agent is fine. If they do, you are leaving money on the table.

How much does orchestration actually save?#

The saving comes entirely from model-matching, and you can check the arithmetic yourself. Assume a workload of 1,000 runs. Each run involves roughly 4 model calls (a coordinator routing call plus a sub-agent loop), averaging about 1,200 input and 200 output tokens per call. That gives approximately 4.8 million input tokens and 0.8 million output tokens per 1,000 runs.

Using Claude list prices as of mid-2026 (June 2026):

Arithmetic check: monolith = 4.8 x 3 + 0.8 x 15 = $14.40 + $12.00 = $26.40. Orchestrated = 4.8 x 1 + 0.8 x 5 = $4.80 + $4.00 = $8.80. The ratio is 26.40 / 8.80 = 3.0, so roughly 3x. The saving is not from making fewer calls. It is from running those calls on a cheaper model, which only the orchestrated design allows.

n8n Community edition is free to self-host, so the $0 platform cost stays constant across both setups. n8n Cloud Starter is €20/mo if you prefer managed hosting. Orchestration changes your model bill, not your n8n bill.

June 2026 Claude prices on a 4.8M in / 0.8M out token workload.

Where do builders get multi-agent wrong?#

The most expensive mistake is putting Sonnet or Opus on every sub-agent. If you split the monolith and assign a flagship model to all three sub-agents, you can pay more than the original monolith because each sub-agent has its own isolated context overhead. The win only appears when you downshift the simple sub-agents to Haiku.

The second mistake is splitting a trivial task. If your agent does one thing well with three tools, adding an orchestration layer creates more workflows to maintain, more places for a vague Description to send work to the wrong sub-agent, and zero cost benefit. One agent is the right call for any workflow where every task is similar in complexity and fits under five tools.

The third mistake is vague tool Descriptions. The coordinator routes on the Description field. "Handles research" does not tell the model when to choose this tool over another. "Use this tool when the user asks for web search results, URL scraping, or retrieving content from uploaded documents" does. Splitting reduces each agent's tool count so each routing decision is simpler. It does not eliminate routing errors on its own.

The fourth mistake is skipping per-agent iteration caps. For more on keeping the whole multi-call loop cost-bounded, see the Claude API cost control guide for agent workflows.

How do you refactor your monolith this weekend?#

Start by reading the n8n AI Agent tools guide to confirm what each tool actually does before you move it. Then open your current agent and list every tool. Group tools by domain: research tools together, data tools together, writing tools together. Any group with two or more related tools is a sub-agent candidate.

Build a small sub-workflow for each group. Attach only that group's tools and write a tight system prompt focused on that one domain. Pick the cheapest model that handles the job correctly. For a comparison of Haiku vs. Sonnet on real n8n agent tasks, see Claude, GPT, Gemini in n8n tested for cost and speed.

Wire each sub-workflow into your coordinator using Call n8n Workflow Tool or AI Agent Tool. Write precise Descriptions. Set Max Iterations caps on everything. Run 10 to 20 real inputs through both the old monolith and the new orchestrated setup, compare the token counts in n8n's execution log, and confirm the per-run cost is lower before switching production traffic over.

For a deeper look at the single-agent build you are refactoring away from, see the comparison of building the same AI Agent in n8n, Make, and LangChain. To give any sub-agent access to external tools over a standardized protocol, the n8n MCP agent guide covers that wiring.

One coordinator, several small sub-agents, a cheap model on the simple work. One failure no longer stops everything, debugging means reading a short isolated execution, and your model bill reflects what each task actually required.