Hi everyone, I’m Nguyen Thieu Toan, Founder & CEO at GenStaff and an n8n Verified Creator.
I build and review a lot of production n8n workflows using AI Agent nodes (multi-tenant, customer-facing, and internal copilots), so reliability across multiple LLM providers is a constant concern.
This feature request is based on real incidents we’ve seen in production when providers hit 429 or become unstable.
The idea is:
Add support for multiple fallback LLM nodes in the AI Agent node, instead of allowing only one fallback node.
Right now, AI Agent supports only a single fallback. This is too limited for real production use, especially when LLM providers often run into temporary issues such as 429 rate limits, timeouts, overloaded services, or partial outages.
The feature should allow users to define an ordered fallback list, so when the primary model fails, the AI Agent automatically tries the next configured model until one succeeds or the list is exhausted.
For example:
- Primary model: Gemini
- Fallback 1: OpenAI
- Fallback 2: Claude
- Fallback 3: another backup provider or self-hosted model
My use case:
I use AI Agent workflows in production-like environments where reliability is critical.
In practice, providers can fail unpredictably. Gemini, for example, can sometimes return repeated 429 errors or temporary instability. If the AI Agent only supports one fallback node, that still leaves a high chance of total failure when the second provider also has issues.
For customer-facing automations, internal copilots, or business workflows, a single fallback is not enough. We need a multi-step fallback strategy to maintain service continuity and reduce workflow failures.
Without this, users have to build complex workaround logic outside the AI Agent node just to achieve a more resilient production setup.
I think it would be beneficial to add this because:
This would make the AI Agent much more production-ready.
Today, allowing only one fallback creates a reliability bottleneck. If both the main model and the single fallback fail, the workflow has no built-in recovery path.
Supporting a fallback list would improve:
- Production stability
- Resilience against provider outages and 429 errors
- Flexibility across multiple LLM vendors
- Simpler workflow design with less external error-handling logic
- Better support for serious business and enterprise use cases
This is especially important because LLM provider reliability can vary a lot over time, and production systems need more than one backup option.
Any resources to support this?
The current n8n Community feature request composer is clearly structured around idea, use case, benefits, resources, and contribution intent, so this request fits the intended submission format for feature requests [page:1].
From an engineering perspective, multi-level fallback is a common resilience pattern when working with third-party APIs that can fail temporarily due to rate limits, overload, or service instability.
In the LLM space, this becomes even more important because model providers often have intermittent reliability issues, making a single fallback insufficient for robust production usage.
Are you willing to work on this?
Yes, I am willing to help define expected behavior, share real production use cases, test the feature, and provide feedback on fallback priority and failure-handling logic.
