Loop Over Items

When to reach for this

Reach for loop-over-items WHENEVER the input could plausibly be (or is) an array:

Input is an array. "Words" (plural), "tickets", "items", "documents", "messages" — all signals to surface a loop in clarification.
Per-item work is uniform. Each item gets the same treatment. If items get different treatments based on classification, that classification is a step ABOVE the loop, not inside it.
Assembly happens INSIDE the loop. This is the most important sub-decision: each iteration should emit a complete unit (e.g. a finished dictionary entry per word), not a fragment that needs position-aware reduction outside the loop.
The number of items is bounded. Loops over thousands of items belong to a different system (batch processing). Pipelines are for interactive-or-near-interactive flows.

Critical heuristic: if you find yourself writing code OUTSIDE the loop that matches output_A[i] with output_B[i] by index, your loop's child blocks are too narrow — move the assembly INSIDE the loop and emit complete units.

Apply the same logic to each element of an array.

Flow: "Batch Vocabulary Glosser"
├── Block: "Find Words" (llm)
│     Output: { words: string[] }
└── Loop over "words":
      └── Block: "Gloss Word" (llm)
            Output: { word, reading, meaning }

When to use: the same prompt needs to run once per item — glossing each word, scoring each candidate, validating each row.

Common mistake: unrolling a loop into N hardcoded blocks. If you don't know how many items there will be at design time, you need a loop. Even when you do know, a loop scales without re-editing the flow.

When to reach for this

On this page