Designing dynamic fan-out

[PLACEHOLDER — outline only, not full prose yet.]

Fan out over multiple services deliberately hardcodes identify-upstreams’s list — ["github", "npm"], fixed at authoring time — to keep that tutorial’s focus on the fan-out mechanics themselves, not list-generation. This guide is the other half: inferring a genuinely runtime-determined list, the way a real pipeline actually would. samples/pipelines/fan-out-multi-service-triage.yaml in the VectorStep repo is a complete, working example of everything below — this guide is the walkthrough of why it’s built that way.

Planned sections

1. Replace the hardcoded list with an inferring step. An LLM step (identify-services in the sample) reads the alert and returns a list it actually determined, not one the pipeline author already knew — the real version of identify-upstreams from the tutorial. What changes in the prompt to get a reliably-formatted list back, and why the field should be named something like services rather than items (the naming gotcha already documented on the reference page).
2. Consolidating without knowing the branch count in advance. The tutorial’s consolidate step references check-upstreams/0 and check-upstreams/1 directly — a shortcut that only works because the list is fixed at two. A genuinely dynamic list can’t be enumerated by index at authoring time; this section covers using the list-producing step’s own next_step_context as the brief a downstream agent reasons from instead, the pattern the sample’s remediation-decision step actually uses.
3. Sizing max_items for a real distribution, not a round number. What actually happens when the cap is hit (the step fails outright, not a silent truncation to the first N), and how to think about the cap as a cost/blast-radius control — every branch is a real LLM call — rather than an arbitrary safety limit.
4. Choosing on_empty deliberately. Whether “the inferring step found nothing” should mean skip (nothing to do, not an error — e.g. no services identified as affected) or abort (an empty result is itself alarming for this particular pipeline) depends on what emptiness actually means for the specific thing being fanned out over; the tutorial’s fixed list never exercises this choice at all.
5. Testing a variable-count fan-out. You can’t manually eyeball every possible branch count the way the tutorial’s fixed two branches allow — what to actually check (the join arithmetic, a genuinely empty case, a single-item case, and a large one against max_items) before trusting this in production.

Where next

• Parallel groups & fan-out — the full reference this guide is the deeper companion to.
• Fan out over multiple services — the hands-on tutorial with the hardcoded stand-in this guide replaces.
• samples/pipelines/fan-out-multi-service-triage.yaml — the complete, real worked example referenced throughout.