AI Agent should not stop when a tool returns no output or fails

The idea is:

Add a failure-handling and empty-result fallback mechanism to the AI Agent node when calling tools.

Right now, if a tool returns no output or fails during execution, the AI Agent stops immediately instead of continuing the reasoning process. In practice, this means the agent cannot recover from common real-world scenarios such as an empty database result, an API returning no items, or a tool workflow throwing an error.

I would like the AI Agent node to support explicit controls for this behavior, for example:

  • A fallback output when a tool returns no result, such as No results found.
  • An option to continue reasoning even if a tool returns nothing.
  • An option to continue reasoning even if a tool fails, while passing the error message back into the agent context.
  • A configurable mode per tool or per AI Agent node, such as stop, continue with fallback, or continue with error context.

This should be handled by the AI Agent node itself, not pushed entirely onto users through defensive boilerplate inside every tool workflow.

My use case:

I am using the AI Agent node in production workflows where tool outputs are not guaranteed to be present on every run.

Typical cases include:

  • A search tool returns zero matches.
  • A database query returns no rows.
  • An HTTP Request tool returns an empty response body.
  • A tool sub-workflow fails because of a timeout, a third-party API issue, or a temporary credential problem.

These are normal runtime conditions in real-world systems. They should not always cause the entire agent to stop.

What I need is for the AI Agent to handle these outcomes as part of the reasoning loop. If one tool returns nothing or fails, the agent should be able to understand that result, decide what to do next, and continue when appropriate instead of crashing immediately.

In my case, this became serious enough that I had to downgrade to AI Agent node version 2.2 to stop the issue. With version 3.x, the agent stops immediately when a tool returns no output or fails. After moving back to 2.2, the same workflow became stable again, which makes this look like a regression rather than an intentional behavior change.

I think it would be beneficial to add this because:

This is a major reliability issue for anyone trying to use AI Agent in real production workflows.

At the moment, one empty or failed tool call can break the whole agent flow. That makes the node fragile and hard to trust in business use cases where external systems are inherently unpredictable.

The current behavior also creates unnecessary overhead for builders. The only workaround is to wrap every tool in custom error handling and force it to always return some structured output, even when that behavior should really be supported by the AI Agent layer itself.

Adding fallback handling would make AI Agent workflows more resilient, easier to maintain, and much more suitable for real-world automation.

I would consider this urgent because the current behavior is not just inconvenient. It breaks the core expectation of an agent, which is to reason through imperfect tool outcomes instead of stopping at the first failure.

Any resources to support this?

I have seen errors like this during AI Agent execution when a tool does not properly return output:

An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'

This points to the current gap in how tool failures or empty outputs are handled in the agent loop.

A related community discussion is here:

Open AI: Bad request - please check your parameters No tool output found for function call

The key issue is not just the raw error itself, but the lack of a built-in recovery strategy inside the AI Agent node when tool execution does not produce a usable response. [page:1]

Are you willing to work on this?

Yes, I am happy to help validate the expected behavior, share reproducible examples, and test potential fixes from a real production workflow perspective.

@nguyenthieutoan this is what I did so far. Add into system prompt to continue on fail or error while tool calling. This is actually a double edge sword. If you continue, you may risk burning up all your credits. If you don’t, it will become a workflow error.

Sounds similar to this

@kjooleng Thanks for sharing your workaround. I agree it’s a double-edged sword - you either burn credits on retries or the workflow crashes.

But here’s what I’m trying to figure out: is this behavior actually intended or is it a bug in AI Agent V3?

Because I had to downgrade to version 2.2 to get around this issue. In V3, the agent stops immediately when a tool returns nothing or fails. In 2.2, it seems to handle these cases more gracefully.

If this is the new expected behavior in V3, then we really need the fallback controls I mentioned in the original post. If it’s a regression, then it should be reported as a bug, not a feature request.

Do you know if the n8n team has commented on whether this stopping behavior is intentional?

Based on your description, this sounds like a regression to me. Since you have solid proof, filing a bug report is the way to go

So, how to downgrade? This maybe what I’m looking for

Easy to downgrade - just copy the AI Agent node in your workflow, paste it into a text editor (Notepad, VS Code, whatever), find the “typeVersion” field and change it from 3.1 to 2.2, then copy the edited JSON and paste it back into n8n to replace the old node.

The workflow will now use AI Agent v2.2 instead.

The problem still exists :face_with_head_bandage:, is there a way to downgrade N8N Cloud version?

Update: I connected OpenRouterChat and used Gemini 2.5 Flash, and the agent worked. I tried using OpenAI models through OpenRouter, but the same problem persists. However, Sub-agents work fine with OpenAIChat.

1 Like

That’s a useful data point @Ali4 - Gemini 2.5 Flash working while OpenAI models fail on the same tool call through OpenRouter suggests this might be model-specific tool call handling rather than a core agent node issue. OpenAI’s tool use response format is stricter about how it expects the tool result to be structured, and if the tool returns nothing, some model versions treat that as a malformed response and stop. Gemini tends to be more tolerant of empty or partial tool returns. This is exactly the kind of evidence worth noting in a feature request to n8n - it points to needing a “tool failure” handling config at the agent level rather than relying on the model’s behavior.