[FEATURE] Improving the Loop Node - Agentflow V2

[toi500]

The current state of the loop node is not at its best potential. Even though this node gives you the option to loop back to any previous node connected in its branch, the reality is that it only works when looping back to the LLM or Agent Node.

So we have several alternatives here:

1. Make it as basic as the v1 one (current state) and limit the options that don't work, as I explained above.

2. Implement custom logic to loop back node by node (very time consuming and not very realistic, I guess).

3. Finding a middle ground between 1 and 2, allowing users to insert variables into the loop node as the value to override in the target node. Here is a very basic example to make this understandable:

   • User wants to search about FLOWISE.
   • The Brave search is executed and returns some data.
   • A quality agent checks if the search is good enough.
   • If not, it routes to the refine agent. The refine agent will propose new search terms.

   And here is the new thing:

   • We would be able to, in the loop node, select the output of the Refine Search Terms agent {{agentAgentflow_0}}, forward that data back to the tool node again and OVERRIDE the tool node input (for this example, {{question}}).

If we do this right, this would provide Agentflow V2 a whole new dimension, IMHO.

FINAL NOTE: This sort of mapping data manually btw nodes is something that we do in n8n with no problem.

FINAL NOTE 2: Being able to update flow state in the loop node would do the job too.

[HenryHengZJ]

I also have been thinking about this, additionally have a fallback option if the loop exhausted, maybe can use the last execution message or custom error message.

For starter, can you give me a couple of flows that can see the flaws and some notes around whats the ideal scenario looks like

[toi500]

@HenryHengZJ 100% agree on the fallback for exhaustion. Here is my high level thinking on how we could implement this:

1. For targeting an LLM or Agent node, by default, it should continue to work as it does right now.

2. Input overrides:

   • When a user selects a Loop Back To target node, ideally, the UI should dynamically fetch that current node's configurable inputs.
   • The user can then map a variable to override a specific input for the next iteration of the loop.

3. Fallback on max loops:

   • A) Integrated reply node functionality. Add a text field directly inside the Loop Node for a fallback message if the loop exhausts.
   • B) Dedicated output. Add a new output anchor on the node that can be linked to any other node. This opens up extremely powerful new capabilities, like creating a fallback path that could trigger another tool, a different agent, or even an Execute Flow node to try a completely different strategy if the primary loop fails. Agentflow is extremely stable when well-configured, I have had flows running in a loop for 4-5 minutes without any error, so this advanced branching would be well-supported.

---

Example

Here is a flow demonstrating the current issue:

1. User query "Black Holes"
2. The Search does not pass the quality control -> The Refine Node proposes "Black Hole Physics"

FLAW:

3. The Loop Node has no ability to forward back this new search term, so I had to do it manually.

FALLBACK:

4. Imagining that we could pass the refined term to the tool node in each loop, we would still need a fallback in case the quality check node has not passed after max loops.

loop node Agents.json

---

Applicable Nodes

The above example applies to many other nodes, enabling all kinds of iterative flows. For example, with Condition Nodes (both rule-based and llm-driven), a flow could check if a long-running task is complete, if not, it waits and then loops back to re-check the status with updated information.

This pattern would be useful for most functional nodes:

• Tool Node: Re-running any tool with dynamically adjusted inputs.
• Retriever Node: Iteratively refining a query to progressively improve retrieval results from any knowledge base.
• HTTP Node: Re-running an API call with modified parameters.
• Condition & Condition Agent Nodes: Re-evaluating a decision point (either rule-based or llm-driven) with updated data.
• Custom Function Node: Re-executing custom code with different parameters.
• Execute Flow Node: Re-running an entire sub-flow with a new input.
• Iteration Node: Looping back to process a completely new/modified list of items.
• Etc.

IMHO, this ability to override variables/inputs mid-run would enable flows to become self-correcting and super adaptive. It would not just be an improved loop mechanism, but would add a whole new dimension of automation for V2.

[toi500]

I haven't heard back from the maintainer, so I've gone ahead and implemented the fallback for the loop node. You can find the changes here main...toi500:Flowise:exhausted-output-loop-node

[HenryHengZJ]

@toi500 your implementation looks good, here's my thoughts and implementation: #4957

of course you are free to use your changes, curious to listen your feedback as well