n8n Multi-Agent Architecture: Which Pattern Should You Actually Use?

A decision guide to sub-workflows, AI Agent Tool nodes, and Execute Workflow -- and when each one makes sense.

The Problem

n8n gives you three different ways to build multi-agent systems. The official docs explain each one separately, but they never tell you when to use which -- or what breaks if you pick the wrong one.

One developer documented spending half a day untangling a multi-agent workflow that should have taken 30 minutes. The root cause: they used sub-workflows for something that needed the AI Agent Tool node. This guide gives you the decision framework they wished existed.

The Three Patterns

Here is a plain-English summary of each approach before we get into the details.

Pattern 1 -- Sub-workflows

What it does

The AI Agent node supports sub-nodes that wrap entire workflows as reusable steps. When you add a child workflow as a sub-node to your agent, the agent can call it as part of its tool loop. The child workflow runs synchronously and returns its output back to the parent agent.

When to use it

• You have logic you want to reuse across multiple agents (e.g. a formatting step, a database lookup, a standard API call)
• The child logic is deterministic -- it doesn't need to reason or make decisions
• You want to reduce complexity in your main workflow canvas by extracting repetitive nodes

How to set it up

1. Build the child workflow. Give it a clear trigger (When Executed by Another Workflow) and a clear output.
2. In your parent workflow's AI Agent node, click + Tool.
3. Select Call n8n Workflow from the tool list.
4. Point it at your child workflow. Give the tool a name and description the agent will use to decide when to call it.

The tool description is the agent's only guide to when it should call this workflow. Write it as a clear instruction: 'Use this tool to look up a customer's subscription status by email address.' Vague descriptions lead to the agent calling the wrong tool or skipping it entirely.

What breaks

• If the child workflow errors and Continue On Fail is not enabled, the parent crashes
• Large outputs from child workflows can overflow the agent's context window -- truncate or summarise before returning
• Sub-workflows share execution context with the parent, so very long-running children can block the parent

Pattern 2 -- AI Agent Tool Node

What it does

The AI Agent Tool node lets you attach an entire AI agent as a tool that a root agent can call. This is true multi-agent delegation: the root agent decides when to hand off a task to a sub-agent, the sub-agent reasons independently using its own model and tools, and returns a result.

When to use it

• You want a specialised sub-agent with its own system prompt, model, and tools (e.g. a 'research agent', a 'code review agent', a 'customer data agent')
• The sub-task requires reasoning, not just execution
• You want the root agent to supervise and delegate without managing the sub-task itself

How to set it up

1. Create a new workflow containing an AI Agent node. Configure its model, system prompt, and tools to specialise it for one task.
2. In your root workflow, open the root AI Agent node and click + Tool.
3. Select AI Agent Tool from the tool list.
4. Point it at your specialist workflow. Write a description that tells the root agent exactly what this sub-agent does and when to delegate to it.

// Example root agent system prompt for multi-agent delegation
You are an orchestrator agent. You have access to specialist agents:
 
- research_agent: Use when you need to find current information from the web
- code_agent: Use when you need to write, review, or debug code
- data_agent: Use when you need to query the database or transform data
 
Always delegate to the most appropriate specialist. Do not attempt tasks
yourself that a specialist can handle better.

Each AI Agent Tool call is a full LLM invocation by the sub-agent. Costs add up quickly in complex multi-agent flows. Monitor token usage and set clear task boundaries to prevent the root agent from over-delegating.

What breaks

• If the sub-agent loops or hallucinates, the root agent receives bad output with no visibility into why -- always test sub-agents independently first
• Sub-agents don't share memory with the root agent by default -- if context sharing is needed, pass it explicitly via the tool call input
• Using the same model for root and all sub-agents maximises cost -- consider cheaper models for simple sub-agents

Pattern 3 -- Execute Workflow Node

What it does

The Execute Workflow node triggers a separate workflow directly from inside another workflow. Unlike the Agent Tool pattern, this is not mediated by an AI agent -- it's a direct programmatic call. You can run it synchronously (wait for the result) or asynchronously (fire and forget).

When to use it

• You want to run workflows in parallel -- trigger multiple workflows simultaneously and collect their results
• You need to decouple workflows -- one workflow hands off to another without needing the result immediately
• You are building event-driven pipelines where one workflow triggers a chain of downstream processes
1. Add an Execute Workflow node to your workflow.
2. Set the Source to a specific workflow.
3. Toggle Wait for Completion if you need the result before continuing.
4. Map input data into the called workflow's expected fields.

// Using a Code node to fan out to 3 workflows in parallel
// (Execute Workflow nodes don't natively run in parallel --
//  use a Split In Batches node or HTTP requests to workflow webhooks)
 
// Pattern: trigger workflows via their webhook URLs simultaneously
const results = await Promise.all([
  $http.post(workflow_a_webhook, { data: $input.item }),
  $http.post(workflow_b_webhook, { data: $input.item }),
  $http.post(workflow_c_webhook, { data: $input.item }),
]);
return results;

The Decision Guide

Use this table to pick the right pattern for your situation.

Common Mistakes

Mistake 1: Using Execute Workflow when you need AI Agent Tool

Execute Workflow is a direct call -- the called workflow runs regardless of context. AI Agent Tool is mediated by the agent's reasoning -- the agent decides if and when to call it. If you want the agent to intelligently delegate, use AI Agent Tool. If you just need one workflow to trigger another unconditionally, use Execute Workflow.

Mistake 2: Putting too much logic in a single root agent

A root agent with 8 tools and a 2000-word system prompt will make poor decisions. Break specialised capability into sub-agents using the AI Agent Tool pattern. Keep the root agent focused on orchestration: receiving the request, delegating to the right specialist, and assembling the final response.

Mistake 3: Not testing sub-agents in isolation

Before connecting a sub-agent or sub-workflow to the root, test it with hard-coded inputs in its own workflow. Verify that the outputs are in the format the root agent expects. A sub-agent that returns a poorly structured result will confuse the root agent in unpredictable ways.

Quick Reference

• Sub-workflow as Agent Tool: reusable deterministic logic, called by the agent's tool loop
• AI Agent Tool node: full sub-agent with its own reasoning, model, and tools
• Execute Workflow: direct programmatic trigger, synchronous or async, no AI mediation
• Test sub-agents independently before connecting them to the root
• Write tool descriptions as clear instructions -- the agent's only guide to when to call them
• Monitor token costs in multi-agent flows -- each sub-agent call is a full LLM invocation