How the pipeline branches and loops

How AgentSDE decides which phase runs next when a design is more than a straight line. This is the execution model behind branches, parallel work, and loops · one level below the flow graph how-to, so you can predict the path a run will take before you pin the design.

#The default path is top to bottom

With no wiring, a design runs its phases in order · the first phase, then the next, down the list, exactly as how a run executes describes. That linear order is the fallback, not a rule the engine is attached to. The moment a design has a flow graph with edges, order stops coming from the list and starts coming from the edges you drew.

An edge is a directed connection · “when this phase reaches this outcome, go there next”. The graph is just the set of those edges, and a run is one walk across it.

#An outcome picks the edge

Every phase ends in one of three outcomes, and the engine chooses the next phase from that outcome alone:

• Completed · the phase succeeded.
• Needs input · the phase is holding for a human answer or approval, and the run pauses here.
• Failed · the phase errored past its retries.

Each outgoing edge is tagged for either success or failure. When a phase completes, the engine follows a success edge; when it fails, it follows a failure edge. Given the same outcome, the same edge is taken every time · the walk is deterministic, so a design’s behaviour is a property you can read off the graph rather than a surprise you discover at runtime.

Phase runs

Completedsuccess edge → Next

Failedfailure edge → Fix

#A failure can route instead of halt

Without a failure edge, a failed phase falls back to its own on failure rule from advanced settings · retry to the limit then halt, skip the phase and continue, or halt the run outright.

A failure edge changes that: instead of ending the run, the failure hands control to another phase. Wire the red lane to a recovery phase · a Rollback, a Fix the build, a Notify · and a failure becomes a branch in the design rather than a dead end. The failing attempt still stays in the run’s history, so routing onward never erases the record of what went wrong.

#Parallel fan-out and joins

A phase with more than one outgoing edge branches, and how it branches depends on the node’s mode:

• Parallel fan-out · every downstream phase starts, and several phases run at once.
• Conditional · the node acts as a switch and follows only the one edge whose condition matches.

Where several edges arrive at a single phase, that phase is a join, and the join decides when the downstream work may start:

• Wait for all · the phase holds until every inbound branch has arrived, then runs once.
• First wins · the phase starts as soon as the first branch arrives.

A join is the guarantee that a phase depending on parallel work does not begin early · the engine will not advance past a “wait for all” join until its inputs are in.

#Loops are capped, so a design cannot spin forever

There are two distinct ways to repeat work, and it helps to keep them apart:

Both are hard caps. A loop-back edge does not create an open-ended cycle · after its capped number of passes the flow continues forward instead of looping again. The canvas will not let you draw an uncapped cycle in the first place, so no design can loop endlessly. This is the guarantee worth internalising: every repeat in a design has a ceiling, and the run always makes forward progress once that ceiling is reached.

#A phase can start from an event

Not every phase waits for a predecessor. A phase can be event-started · its only inbound wiring is a trigger, so it begins from an outside signal rather than from the phase before it. The signal can be an external integration event (for example a pull request merged, or a build failed) or a lifecycle hook fired relative to another phase. How work reaches a phase this way is covered in how work starts.

An event-started phase sits outside the main sequence. It is how a design handles “reply when a review requests changes” or “fix the build when CI fails” without bolting that path onto the linear pipeline · the branch exists in the graph but only runs when its event actually fires.

#What the graph guarantees

Read together, the model gives you a handful of guarantees you can lean on:

• One live version runs. Agents always execute the single pinned version of a design, so editing a draft never disturbs a run in flight (see phase designer).
• The walk is deterministic. Given a phase’s outcome, the engine always takes the same edge, so the path a run follows is predictable from the graph.
• Loops are bounded. Both max iterations and the loop-back cap are hard limits, and the flow continues forward once a cap is reached · nothing spins forever.
• Joins hold their inputs. A “wait for all” join does not release the downstream phase until every branch it depends on has arrived.
• Unreachable phases never run. A phase with no inbound edge and no trigger has no way to be reached, so it simply does not execute · it is inert until you wire it in.

#Where to go next