Multi-Agent Orchestration in n8n

If you are building automation that goes beyond a single prompt and response, you need n8n multi agent orchestration: a router workflow that inspects a task, delegates it to specialized worker agents, and merges the results before returning an answer. This pattern is what separates a toy chatbot from a system that can triage support tickets, research a topic across multiple tools, and write a report without a human babysitting every step. This guide walks through the concrete node layout, the sub-workflow structure, memory sharing, and the failure modes you will hit once real traffic shows up.

n8n is a fair fit for this because it treats each agent as a workflow you can version, test, and trigger independently, rather than a single giant prompt with a pile of tool definitions. That separation is the whole point of multi-agent design: each agent gets a narrow job, a small toolset, and a clear contract for what it returns.

Why multi agent instead of one big agent

A single LLM agent with fifteen tools attached tends to degrade in a predictable way. Tool selection accuracy drops as the tool list grows, the system prompt balloons trying to cover every edge case, and debugging becomes guesswork because you cannot tell which part of the giant prompt caused a bad decision.

Splitting the work into agents fixes three things at once:

• Smaller tool surface per agent. A "calendar agent" only needs calendar tools. It cannot accidentally call a billing API because it does not know that tool exists.
• Independent iteration. You can rewrite the prompt for the research agent without touching the summarizer agent, and redeploy just that sub-workflow.
• Cheaper routing. The router agent can run on a smaller, cheaper model since its only job is classification and delegation, while the specialist agents run on a stronger model only when needed.

The tradeoff is coordination overhead: you now have to pass state between workflows, handle partial failures, and avoid infinite delegation loops. n8n gives you the primitives to do that, but you have to wire them deliberately.

The core architecture: router plus workers

The pattern that holds up in production is a router-worker topology, not a flat mesh where every agent can call every other agent. Flat meshes look flexible in a demo and become undebuggable within a month because you lose track of who called whom.

Trigger (Webhook / Chat Trigger)
   |
   v
Router Agent (AI Agent node, small/cheap model)
   |
   |--- decides intent, calls one or more workers via Execute Workflow
   |
   +--> Worker: Research Agent (sub-workflow)
   +--> Worker: Support Agent (sub-workflow)
   +--> Worker: Data Agent (sub-workflow)
   |
   v
Aggregator node -> Response formatting -> Return to caller

In n8n terms:

1. Trigger node: a Webhook node or Chat Trigger node starts the flow. For a chat product, use the Chat Trigger node so you get session handling for free.
2. Router Agent: an AI Agent node configured with a system prompt whose only job is classification and delegation, not execution. Its "tools" are Execute Workflow Tool nodes, one per worker agent, not raw APIs.
3. Worker sub-workflows: each worker is its own n8n workflow, published and callable, with its own AI Agent node, its own memory, and its own real tools (HTTP Request, database nodes, code nodes).
4. Aggregator: a Merge node or a Code node that collects whatever the router returned and normalizes it into one response shape before it goes back out.

Building the router

Add an AI Agent node right after your trigger. Its system prompt should read like a dispatcher's job description, not a general assistant's:

You are a routing agent. You do not answer questions directly.
Given the user request, decide which specialist workflow(s) should
handle it. Available specialists:
- research_agent: web lookups, fact-finding, multi-source summaries
- support_agent: account issues, billing questions, ticket status
- data_agent: querying internal metrics and dashboards

Call one or more specialist tools. If the request needs more than
one, call them in the order needed and combine notes for the final
answer. Never attempt to answer using your own knowledge.

Attach each worker as a tool using the Execute Workflow Tool node type, not a plain Execute Workflow node. The "Tool" variant exposes the sub-workflow to the AI Agent's function-calling interface, complete with a description the model uses to decide when to call it. Give each tool description a tight, unambiguous scope:

Name: research_agent
Description: Use for any question requiring web search, current
events, or synthesizing information from multiple external sources.
Do not use for account-specific or billing questions.

Vague descriptions are the single biggest cause of misrouting. If two tool descriptions overlap, the model will flip a coin, and that coin flip will not be consistent across runs.

Building a worker

Each worker is a normal n8n workflow with its own trigger set to Workflow Input Trigger so it can be called by Execute Workflow Tool. Inside:

1. Workflow Input Trigger defines the expected input schema, for example { task: string, context: object }.
2. AI Agent node with the specialist's own system prompt and its own tools (HTTP Request nodes wrapped as AI Agent Tools, a Postgres node, a Code node for calculations).
3. Set node at the end to shape the output into a consistent envelope, for example { agent: "research_agent", result: string, sources: array }.

That consistent envelope matters more than it looks. If every worker returns a differently shaped object, your aggregator turns into a pile of conditional branches. Standardize on one shape across all workers from day one.

Passing state and shared memory between agents

Two kinds of state show up in multi-agent workflows, and they need different handling.

Conversation memory (what the user has said so far) should live in a memory node attached to the router agent, using n8n's Window Buffer Memory or a Postgres/Redis-backed memory node keyed by session ID. Workers generally should not carry the full conversation history; pass them only the distilled task plus whatever context fields they need. This keeps worker prompts small and keeps you from leaking irrelevant conversation turns into a specialist's context window.

Task state (what has been decided, what tools have already run, what partial results exist) should be passed explicitly as workflow input/output, not implied through shared memory. Explicit data passing is the reason n8n multi agent setups are debuggable: you can open any execution in the UI and see exactly what JSON went into each sub-workflow and what came out.

A minimal shared context object passed to every worker:

{
  "session_id": "sess_8891",
  "task": "Find the current status of order #4521 and summarize delivery delay reasons",
  "context": {
    "user_id": "u_223",
    "prior_agent_notes": []
  }
}

When the router chains two workers, it appends to prior_agent_notes so the second worker sees what the first one found, without re-running conversation history through the model.

Handling errors without collapsing the whole run

Agent workflows fail in ways plain automations do not: a tool call times out, the model hallucinates a tool argument, or a worker returns malformed JSON. Build for these explicitly.

• Wrap every Execute Workflow Tool call path with error output enabled. On the sub-workflow's settings, set "Continue On Fail" for the nodes that call external APIs, and have the last node in each worker always return a valid envelope, even on failure: { agent: "data_agent", result: null, error: "timeout" }. Never let a worker crash silently, because the router agent will just interpret an empty response as "nothing to report" and hallucinate a fallback answer.
• Set a retry policy on HTTP Request nodes (2-3 retries with backoff) inside workers, but not on the AI Agent node itself. Retrying an LLM call because the tool inside it failed doubles your token spend for no benefit; retry the specific failing tool call instead.
• Add a timeout guard. Wrap long-running worker chains with an execution-timeout check (a Wait node plus a comparison, or n8n's workflow-level timeout setting) so one stuck research agent does not hang the whole router run for minutes.
• Log every routing decision. Add a Code node right after the router agent that writes {session_id, chosen_tools, timestamp} to a logging destination (Postgres table, or a lightweight webhook to your observability tool). When routing looks wrong in production, this log is the only way to tell whether the router picked the wrong worker or the worker itself produced a bad answer.

Avoiding infinite delegation loops

A router agent with access to itself as a tool, directly or through a worker that can call back into the router, is a common way to get an accidental infinite loop and a large bill. Two guardrails:

1. Never expose the router workflow as a tool to any worker. Delegation is one-directional: router calls workers, workers do not call the router or each other.
2. Cap the router's tool-call iterations. In the AI Agent node settings, set a max iteration limit (n8n exposes this on the agent node) so the model cannot chain tool calls indefinitely within one execution.

If a task genuinely needs multiple rounds (worker A's output should inform worker B), do that explicitly in the router's prompt as a two-step plan rather than letting the model decide to loop freely.

Testing the workflow before it hits real traffic

Before wiring this to a live webhook, run it through n8n's manual execution mode with representative inputs for each routing category: one clearly research-shaped request, one clearly support-shaped request, one ambiguous request that could match two workers, and one nonsense request that matches none. The ambiguous case tells you whether your tool descriptions need tightening; the nonsense case tells you whether your router has a sane fallback ("I can't help with that" instead of forcing a bad match).

Keep a small fixed set of these test inputs saved as pinned data on the trigger node. Every time you touch the router's system prompt or a worker's tool description, re-run the set manually and diff the routing decisions. This is the closest thing to a regression test you get in a low-code tool, and skipping it is how routing quietly breaks after a "small prompt tweak."

FAQ

Do I need a separate n8n workflow for every agent, or can I keep agents as nodes in one workflow? You can put multiple AI Agent nodes in a single workflow for small setups, but separate sub-workflows scale better because you can version, test, and redeploy one specialist without touching the router, and you get isolated execution logs per agent, which is essential once you have more than two or three specialists.

Which model should the router use versus the workers? The router only classifies intent and picks tools, so a smaller and cheaper model is usually enough. Reserve the stronger model for workers doing actual reasoning, writing, or multi-step tool use, since that is where quality differences actually show up in the output.

How do I stop the router from calling multiple workers when only one is needed? Tighten the tool descriptions so their scopes do not overlap, and add an explicit line in the router's system prompt such as "call the minimum number of specialists needed to answer the request." Overlapping descriptions are the most common cause of unnecessary multi-tool calls.

Can workers call external MCP tools instead of n8n's built-in nodes? Yes. n8n's AI Agent node supports MCP client tools alongside native nodes, so a worker can call an MCP server for something like a codebase search or a database tool without you rebuilding that integration as HTTP Request nodes.

How do I keep costs predictable with multiple agents chained together? Cap max tool-call iterations on the router, keep worker system prompts and injected context as short as possible, and log token usage per execution (n8n's AI Agent node exposes usage metadata) so you can spot a misbehaving worker before it runs up a large bill.

What is the simplest way to test routing accuracy over time? Save a fixed set of pinned test inputs on the trigger node covering each intent category plus an ambiguous and a nonsense case, and re-run them manually after any prompt or tool-description change to confirm routing decisions have not drifted.