Add Concurrency option to the Iteration (Agentflow V2) node to run iterations in parallel

[prd-hoang-doan]

Feature Description

Add an optional Concurrency setting to the Iteration node in Agentflow V2 so that the items in the iteration array can be processed in parallel instead of strictly one-at-a-time.

• New numeric input Concurrency on the Iteration node (Additional Parameters), default 1 (current sequential behavior), capped at 20.
• 1 = sequential (fully backward compatible). N = up to N iteration items processed per batch.
• Per-item results, executed data, and flow-state merges are still committed in index order after each batch, so output ordering is identical to sequential mode.

Feature Category

Workflow/Flow Management

Problem Statement

The Iteration node currently executes its sub-flow sequentially — one array item at a time. For fan-out patterns like the Deep Research flow (Planner → Iteration → research SubAgents), each subagent makes its own LLM/tool calls, so total runtime grows linearly with the number of tasks.

When the Planner produces several independent tasks, the user waits for N × (subagent latency) even though the tasks have no dependency on each other and could run at the same time. This makes multi-subagent flows slow and discourages breaking work into more, smaller tasks.

---

My real use case:
Concrete use case (internal deep-research over a Confluence PRD):
A QA-research flow uses Planner → Iteration → Research SubAgent → Summarizer → Condition → Loop:

• The Planner (LLM) reads a PRD and breaks it into 3–6 focused research tasks, saved to $flow.state.subagents.
• The Iteration block spawns one Research SubAgent per task; each subagent searches a Confluence "Feature A" knowledge base (Document Store retriever) and returns grounded findings.
• A Summarizer merges the findings into a QA brief, and a Condition Agent can Loop back to the Planner for up to 3 more rounds.

Because each subagent performs its own retrieval + LLM reasoning (and the Planner can fan out to ~10 tasks, multiplied by up to 3 loop rounds), the iteration dominates the wall-clock. The tasks are independent — each answers a self-contained question from the same knowledge base — yet they still run one after another, so total time grows linearly with the number of tasks (e.g. 6 tasks × ~8–15s each ≈ 1–1.5 min per round, ×3 rounds). The flow "takes a lot of time to finish" purely because work that could run in parallel is serialized.

There is currently no way to tell the Iteration node to process these independent subagents concurrently.

Proposed Solution

Introduce a Concurrency input on the Iteration node and batch the engine's iteration loop:

1. Iteration node (iterationAgentflow)

   • Add an optional Concurrency number input (Additional Parameters), default: 1, clamped to [1, 20].
   • Surface the resolved value on the node output so the engine can read it.

2. Engine (buildAgentflow.ts)

   • Replace the sequential for loop with a bounded-concurrency runner: process items in batches of concurrency using Promise.all, where effective = min(concurrency, itemCount).
   • Preserve correctness:
     • Order: write each item's outcome into an index slot and flatten results in order after each batch (no completion-order shuffling).
     • Executed data / DB writes: collect per-item executed data, append in index order, and persist the parent execution once per batch instead of per item (avoids racing updateExecution writes on the same row).
     • Flow state: merge state back in index order between batches.

3. Guardrails / docs

   • default: 1 keeps existing flows unchanged.
   • Hard cap at 20 to limit provider rate-limit pressure (each parallel item can fan out into its own LLM + tool calls).
   • Document that Concurrency > 1 should be avoided when the iteration body writes to Flow State, since concurrent merges are last-writer-wins (nondeterministic).

Behavior example: with 5 independent tasks and Concurrency = 5, wall-clock drops from ~5× subagent latency to ~1×, while the merged output remains in task order.

Mockups or References

• Reference flow this benefits: Deep Research tutorial — https://docs.flowiseai.com/tutorials/deep-research
• The Iteration node "spawns one subagent per task"; this request lets those independent subagents run concurrently.

Additional Context

No response