Orchestrating multiple AI agents in n8n: the supervisor/specialists pattern

The AI Agent article cluster may have brought you here: your agent is running, it has its tools, its memory — and its system prompt is starting to look like a twenty-paragraph internal rulebook. "If the question is about the docs, do this; if it's an existing customer, do that; always answer in this tone, except when…" That's the typical signal that a single agent is hitting saturation. The answer isn't to make the prompt even longer: it's to split into several specialized agents, orchestrated by a supervisor. This article covers how to build that pattern in n8n — and, above all, when not to.

First, the honest warning: one agent is often enough

Let's start with what multi-agent demos forget to mention: in the majority of production cases, a single well-configured AI Agent does the job. A clear system message, 5 to 7 well-described tools, the right memory — and you have a system that's easy to debug, fast and cheap.

Every additional agent in your architecture levies three very real taxes:

• Cost: each delegation triggers extra LLM calls — the specialist's reasoning, then the supervisor's review. A conversation that used to cost one call can now cost five or six.
• Latency: the calls stack up in series. A supervisor that consults two specialists before answering easily triples response time.
• Debugging: when the final answer is wrong, the cause can sit in the supervisor's routing, in a specialist's prompt, in one of its tools, or in the final synthesis. Four floors of suspects instead of one.

Multi-agent setups are only justified by specific symptoms: a system prompt turned into a catch-all of contradictory instructions, more than 7 or 8 tools starting to get confused with each other, or tasks with incompatible requirements ("be exhaustive and technical" for research, "be brief and warm" for the customer reply). Until you see those symptoms, stick to one agent.

What the research says

The idea of making specialized agents cooperate isn't an architect's whim. The work by Wu and coauthors on AutoGen (2023), the reference framework in the field, shows that specialized LLM agents conversing with each other solve certain classes of complex tasks better than a monolithic agent — precisely because each agent keeps a tight role and context.

But the same literature calls for caution: the survey by Guo and coauthors, "Large Language Model based Multi-Agents" (2024), maps the landscape of multi-agent architectures and points at their persistent limits: fragile coordination between agents, cost that explodes with the number of exchanges, and the difficulty of evaluating the overall system. In other words: specialization pays off, orchestration has a price.

The supervisor/specialists pattern in n8n

The principle: a supervisor agent receives the user's request and does only one thing — understand the intent and delegate to the right specialist, exposed as one of its tools. The supervisor has no "business" tool; its tools are the other agents.

n8n offers two mechanisms for wiring an agent as another agent's tool:

1. An agent wired directly as a tool. Under the supervisor's ai_tool connection, you plug in a second agent, with its own model, its own short system prompt and its own tools. Everything lives in the same workflow — handy for prototyping, less so for maintenance.
2. A sub-workflow called as a tool (Call n8n Workflow Tool). The specialist lives in its own workflow, with its AI Agent, its prompt and its tools, and the supervisor calls it through a toolWorkflow. This is the approach we recommend as soon as the system outgrows the prototype: each specialist can be tested, versioned and reused independently, exactly like any other n8n sub-workflow.

In both cases, the golden rule is the same as for any regular tool: all the supervisor sees of a specialist is its name and description. "Documentation specialist: call this tool when the question is about our products, the docs or internal procedures; pass it the rephrased question" — it's that sentence, not the content of the sub-workflow, that decides the routing.

Running example: a customer support assistant with three specialists

Take a concrete case: a support assistant receiving all kinds of customer messages. The natural split:

• Supervisor: a system prompt of ten lines at most. Its only job: classify the request, call the right specialist(s), assemble the final answer. No direct access to any data.
• "Document search" specialist: an agent with a Vector Store as a tool, querying the knowledge base (the classic RAG pattern). Its prompt: search, cite its sources, say "I couldn't find it" rather than invent.
• "Customer data" specialist: a read-only agent over the CRM or Supabase — orders, subscription, ticket history. Its prompt: return structured facts, never prose.
• "Reply writing" specialist: an agent with no tools at all, receiving the raw material from the other two and producing the final answer in the brand's tone.

The benefit is obvious: each specialist's prompt fits in a few non-contradictory lines, each agent has 1 to 3 tools instead of 10, and you can improve the writer without risking breaking the routing. The documentation specialist, for its part, is exactly the building block shipped in our RAG Assistant Pack — it plugs in as-is as a sub-workflow of the supervisor.

The underrated alternative: the sequential pipeline

Before wiring up a supervisor, ask yourself one simple question: do you know the order of the steps in advance? If so, you don't need dynamic routing — a pipeline is enough: several AI Agent nodes chained in the workflow, each with its role (fact extraction → enrichment with customer data → writing), the output of one feeding the input of the next.

When it applies, the pipeline is almost always preferable to the supervisor: no "coordination" LLM calls, predictable latency, and trivial debugging — you see in the execution exactly what each stage produced. Reserve the supervisor for cases where the route genuinely depends on the incoming request; for anything deterministic, chain.

The essential guardrails

A multi-agent system amplifies every risk of a single agent. Four guardrails to put in place from day one:

• Max Iterations everywhere. On the supervisor and on each specialist. Without a cap, a supervisor that keeps re-calling a failing specialist in a loop can burn dozens of calls before giving up. Lower the default on specialists that only need one or two cycles.
• Cost tracking per conversation. Each delegation multiplies LLM calls; the relevant cost is no longer "per call" but "per request handled end to end". Our guide to tracking the cost of AI calls in n8n applies at every level — log each sub-execution's tokens with a shared conversation ID.
• Traceability of sub-executions. When a specialist runs in a sub-workflow, its execution shows up separately in n8n. Without a shared identifier in the logs, reconstructing "who said what to whom" for a given conversation becomes a nightmare. Propagate an ID end to end.
• Prompt injection, multiplied. If the documentation specialist reads external content (web pages, tickets, emails), a malicious instruction slipped into that content can travel up to the supervisor and influence the routing or the final answer. The defenses covered in our article on prompt injection and guardrails must apply at every boundary between agents, not just at the system's entry point.

One last architectural point: in the supervisor pattern, it's usually the supervisor alone that holds the conversation memory; the specialists stay stateless and receive all the necessary context in the request. Giving each specialist its own memory creates diverging versions of the conversation — avoid it.

Evaluate the system, not the agents in isolation

Last trap: testing each specialist separately, confirming each one works, and concluding the system works. Wrong — multi-agent failures happen at the boundaries: a supervisor routing to the wrong specialist, context truncated along the way, a synthesis contradicting what a specialist found. Build a set of realistic end-to-end requests and measure the final answer, as described in our guide to evaluating AI workflows in n8n. Per-agent metrics help you locate a problem — they never prove the whole works.

Where to start

The reasonable path: start with a single agent, push it to its real limits, and only split when the saturation symptoms show up — starting with a pipeline if the order of steps is known, with a two-specialist supervisor otherwise. To avoid starting from scratch, our RAG Assistant Pack ships the documentation specialist ready to wire in as a sub-workflow, and FlowKit's workflows deliver equipped, documented agents that make excellent starting specialists. A ten-line supervisor in front of two battle-tested building blocks: that's how good multi-agent systems begin.