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, orcontinue 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.