AI Agent with Sub-Agent Tools Fails - Workflow Stops Despite Retry Configuration

My Core Agent (AI Agent node) has retryOnFail: true, maxTries: 2 configured, but when sub-agents (BrowserAgent, OpsManager) fail, the entire workflow stops immediately.​

Setup:

  • Core Agent (AI Agent node) with BrowserAgent and OpsManager as tools

  • Main agent has retry enabled but sub-agent failures bypass it completely

The Problem:

When a sub-agent fails, the error propagates directly to the parent agent and kills the workflow, ignoring the retry settings on the Core Agent node.

Questions:

  1. Why don’t retry settings on the main AI Agent apply when sub-agents fail ?

  2. Is there a way to make sub-agent errors not propagate as hard failures to the parent agent ?​

  3. Should sub-agents return errors as data (e.g., {"success": false, "error": "..."}) instead of throwing exceptions ?​

Currently the workflow terminates on first sub-agent error despite having retry configured on the main agent. Any workarounds?

I am praying to god that sub agents never fail

1 Like

Hey @Mohammed_Rifad This is expected n8n behavior. Here’s the key insight:

retryOnFail applies to the node itself failing, not to tools/sub-agents returning errors, you can also check that in the docs.

When a sub-agent (tool) throws an exception:

  • It’s not considered a “node failure” in the retry sense

  • The error propagates up as tool execution result (failure)

  • The parent agent receives the error and may halt

There are a couple of routes you can take, in the sub-agent you can maybe handle the error and return it as data to the main agent or maybe configure the node in the sub-agent to Continue with the last valid data if that is applicable, docs.

Hope that helps.

I did try all of these still same issue, I even tried as subworkflow but it failed

I think this is how the AI Agent node version 3 behaves,

I tried the AI Agent node version 2, and the agent was able to read the Tool error without stopping the workflow:

The tools do not have On Error setting, or a Never Error option like the HTTP Request tool does:

So, this seems like a limitation to me :confused: