n8n AI Agent Tool vs Sub-Workflow: When to Use Each

I spent a couple of years around restaurant kitchens before I wrote software for a living, and the mental model I keep coming back to for multi-agent workflows is the pass. The expediter doesn't cook. They read the ticket, decide who it belongs to, call it out, and check the plate before it leaves. Grill, sauté and garde manger each own one thing and do it well.

That's exactly what a manager agent should be, and it's exactly what most n8n multi-agent builds get wrong. People give the manager tools and sub-agents, then wonder why it sometimes does the work itself instead of delegating. An expediter who starts plating is a slow expediter.

The second thing kitchens get right: every station is its own station. You can pull a cook off grill, replace them, and service continues. That's an execution boundary, and it's the thing the two n8n options actually differ on.

The AI Agent Tool (n8n-nodes-langchain.toolaiagent) is a sub-node you connect to the tool port of a root AI Agent. From the manager's point of view it looks like any other tool: a name and a Descriptionthat tells the model when to reach for it. Underneath, it's a complete agent with its own Prompt (User Message), its own chat model, and its own tools hanging off it.

The settings that matter once you go past the demo:

• System Message— the specialist's actual job description. This is where the value is. If your sub-agent's system message could be swapped with the manager's without anything breaking, you didn't need a sub-agent.
• Max Iterations— bounds the sub-agent's loop. Leave this at a low number. A runaway specialist inside a manager's turn is the worst kind of runaway, because the manager is still holding the execution open while it spins.
• Require Specific Output Format — attaches an output parser so the manager receives structured data instead of prose. Turn this on for anything the manager has to branch on.
• Return Intermediate Steps— surfaces the sub-agent's reasoning in the output. Useful while you're building, and a token tax you should switch off once you ship.
• Enable Fallback Model and Batch Processing — a backup model for provider failures, and a size plus delay control for rate limits. Both matter more than they sound like they do when a manager fans out to several specialists in one turn.

You can nest these into multiple layers, so a specialist can supervise its own specialists. You can. In two years of shipping these I've never been glad I went past two levels — at three, a single execution log has to explain three layers of delegation at once, and reading it stops being possible.

The Call n8n Sub-Workflow tool (n8n-nodes-langchain.toolworkflow) points the agent at another workflow in your instance. You pick it by ID from the database, or paste workflow JSON inline. The target workflow needs a Workflow Input Schema defined on its trigger — without it, the parent has no idea what fields to offer, and this is the part people forget before they start blaming the agent.

Inputs get filled one of three ways: a fixed value, an expression reading the current workflow's data, or $fromAI(), which lets the model decide the value at call time. You can mix them in the same node — pin the tenant ID with an expression, let the model choose the search query. That mix is the feature; it means the model never gets to pick which customer's data it touches.

The thing you actually bought is the execution. A sub-workflow call produces its own execution record. You can open it, see exactly what went in and out, re-run it against a fixed input while the parent sits untouched, and let a completely different workflow call the same specialist tomorrow. That's not a nicer debugging experience, it's a different architecture.

Same job, different trade-offs:

• Execution record— AI Agent Tool: none of its own, it's part of the parent's run. Sub-workflow: its own execution, listed separately.
• Reuse across workflows — AI Agent Tool: none, it exists only inside this parent. Sub-workflow: any workflow can call it.
• Retry a failed specialist alone — AI Agent Tool: you re-run the whole parent. Sub-workflow: re-run just that execution.
• Setup cost — AI Agent Tool: drop the node on the canvas, write a description and a system message. Sub-workflow: build a second workflow, define an input schema, keep IDs in sync between dev and prod.
• Visibility — AI Agent Tool: the entire hierarchy is on one canvas, which is genuinely great for handing a build to someone else. Sub-workflow: you follow references between workflows.
• Blast radius of an edit — AI Agent Tool: contained to this workflow. Sub-workflow: you just changed something four other workflows call, which cuts both ways.

My rule: build it as an AI Agent Tool first. Promote it to a sub-workflow the day a second workflow wants it, or the day you find yourself scrolling a parent execution to figure out what one specialist did. Both of those are concrete events, not judgement calls, which is why the rule survives contact with a real backlog.

This one has cost me more debugging hours than every other n8n quirk combined, and it applies to both nodes because both are sub-nodes.

Root nodes in n8n process input items one at a time — 40 items in, the node runs 40 times, and an expression resolves per item. Sub-nodes don't. A sub-node resolves every expression against the first input item, every single call. n8n documents this plainly with a five-name example: given five names, {{ $json.name }} returns the first name five times.

// 40 leads in. Sub-agent parameter set to:
{{ $json.company }}

// What the specialist sees on all 40 calls:
"Acme Corp"   // ...the first item. Forty times.

It never errors. The workflow goes green. Your enrichment agent researched one company forty times and wrote forty rows. If you've read my post on control flow and agent failures, this is the same family of problem: the failure is silent, so nothing in your monitoring fires.

Two fixes, and they're not interchangeable:

• Loop at the root level. Put a Loop Over Items node before the manager agent so each record becomes its own agent run. Slower, correct, and you get one execution boundary per record — which is usually what you wanted anyway.
• Let the model fill the parameter with $fromAI(). The value comes from the model's tool call, not from the input item, so the first-item rule never applies. Right answer when the manager is genuinely choosing the value; wrong answer for anything you need pinned, like a tenant ID.

A plain tool — an HTTP request, a Postgres query — costs one call and returns a value. A sub-agent is a different animal. It runs its own agent loop, carrying its own system message and its own tool definitions through every iteration, and when it finishes, the manager pays again: that entire output lands in the manager's next turn as a tool result.

A manager supervising three specialists is four agent loops, not one agent with three tools. Every layer of nesting multiplies rather than adds. That's the number to hold in your head when someone shows you a canvas with nine agents on it.

So the honest test before splitting: do the specialists need different tools, different models, or genuinely different instructions? If all three answers are no, you don't have a multi-agent system. You have one agent with extra billing. A cheaper model on the specialists is the other easy win — research and extraction rarely need your manager's model. I go deeper on where the spend actually goes in AI agent cost optimization.

Multi-agent is a structure for problems you already understand. Adding it to a workflow that's failing for other reasons just gives the failure more places to hide. Three things I want in place first:

• Tracing.If you can't already see which tool call burned the tokens in a single-agent run, a hierarchy will not clarify it. Start with agent observability.
• A memory decision.Sub-agents don't share the manager's conversation memory — each one gets what you pass it and nothing else. That's a feature, but it means shared state has to live somewhere deliberate. My take on the storage side is in Postgres vs Redis for agent memory.
• An eval, even a small one. Twenty saved inputs and an expected outcome is enough to tell you whether splitting made quality better or just made the canvas prettier. I wrote up the setup in n8n AI agent evaluations.

And if you're running this at volume, note that sub-workflow executions are still executions — they land in the same queue and count against the same workers. Fanning out to four specialists per record multiplies your execution count too, not just your token bill. That's a queue mode conversation before it's a prompt conversation.

For the record, the reference material here is worth reading directly: n8n's docs on the AI Agent Tool node and the Call n8n Sub-Workflow tool both spell out the first-item behaviour that costs everyone a day.