Skip to content

Loops

A loop node runs a section of your workflow once for each item in a list. Instead of building ten near-identical branches, you build the body once and point the loop at a list of ten things.

Anything you’d otherwise copy-paste:

  • Summarize each of 50 documents.
  • Generate a product description for every row in a spreadsheet.
  • Call an API once per customer and collect the results.

You give the loop a list to iterate over — usually a reference to an earlier node’s output, like {{ fetch_rows.items }}. Inside the loop body, each pass can read:

  • {{ loop.item }} — the current item.
  • {{ loop.index }} — its position in the list.

The loop collects every iteration’s result into a list, in the original order of the input — not the order they happened to finish.

A loop can run sequentially (one item, then the next) or with some concurrency (several items in flight at once). Parallel is much faster for independent work like “summarize each document”; sequential is the right choice when each step depends on the one before, or when you’re calling something that doesn’t like being hammered.

  • Sequential: the loop stops at the first failed item.
  • Parallel: each item succeeds or fails on its own; the loop only fails overall if every item failed. The results tell you which items worked and which didn’t (e.g. “47 of 50, 3 failed”), so one bad row doesn’t sink the whole batch.
  • Keep the loop body small — do the per-item work, return a clean result, and assemble the final output in a template or Python node after the loop.
  • Pair loops with agents when each item needs real investigation, or with plain LLM nodes when each item is a single, well-defined call.