When a Workflow Should Branch, Loop, or Stop

Branching means the workflow takes one of two or more different paths depending on a condition evaluated at runtime. It is the right pattern whenever the correct next step depends on something you cannot know until the workflow is running: a reviewer's decision, an agent's output, a safety check result, or a field value supplied by a user.

In DAVE's Workflow Editor, branching is built by connecting a node to two or more downstream nodes and adding routing rules to the outgoing edges. A routing rule specifies a field, an operator, a value, and a priority. When the upstream node completes, DAVE evaluates the rules in priority order and follows the first edge whose condition is satisfied.

The cleanest way to implement branching is with a dedicated Routing node. The Routing node is logic-only: it evaluates output port criteria and routes execution to the correct next step without creating tasks or invoking agents. Keeping routing logic in a Routing node, rather than embedding it in a functional node like an Agent Interaction or Human Review node, makes the graph easier to read and the branching logic easier to change independently of the step that produced the output.

The three most common branching triggers

• Human Review decisions. The Human Review node produces three possible outcomes: approve, reject, or request changes. Each outcome should route to a different branch. Approval routes forward to the next step. Rejection routes to an End node or a notification step. Request changes routes back to the author or to a revision agent. Connect the Human Review node to three downstream nodes and configure routing rules on each outgoing edge to match the corresponding decision value.
• Agent or safety check verdicts. An Agent Review node or a Safety node returns a structured result, typically a pass or fail verdict. Connect the node to two branches: one for pass (continue forward) and one for fail (route to a Human Review node, a revision loop, or a blocking End node). The Routing node is a natural fit here: place it immediately after the Agent Review or Safety node to evaluate the verdict and dispatch to the correct branch without mixing routing logic into the functional node.
• Field values from user input. A User Interaction node collects input from a user and maps it into workflow fields. A downstream Routing node can evaluate those field values and branch accordingly. For example, a content type field might route blog posts to one agent and product descriptions to another.

One practical rule: if a node has more than one outgoing edge, every edge should have a routing rule. An edge with no rule acts as a default path, which can produce unexpected behavior when multiple edges are present. Be explicit about every branch condition.

A loop is a branch that routes execution back to an earlier node rather than forward to a new one. It is the right pattern when a step needs to repeat until a condition is met: a revision cycle that continues until a reviewer approves, a retry that runs again if an agent returns a low-confidence result, or a data collection step that repeats until a required field is populated.

In DAVE's Workflow Editor, a loop is built by drawing an edge from a downstream node back to an upstream node. There is no special loop node type: a loop is simply a routing decision that points backward in the graph. The Routing node is again the cleanest tool for this: place it after the step whose result determines whether to continue or repeat, add a routing rule for the repeat condition that points back to the earlier node, and add a separate routing rule for the exit condition that points forward.

The revision loop: the most common loop pattern

The revision loop is the pattern you will build most often. It looks like this:

1. An Agent Interaction node drafts content.
2. A Human Review node presents the draft to a reviewer.
3. If the reviewer approves, a Routing node routes forward to the next step.
4. If the reviewer requests changes, the Routing node routes back to the Agent Interaction node (or to a User Interaction node where the author can revise the brief).
5. The loop repeats until the reviewer approves or a maximum iteration count is reached.

The revision loop keeps humans in control of quality without requiring them to manage the process manually. The workflow handles the routing; the reviewer handles the judgment.

Loop exit conditions: always build one

Every loop needs an exit condition that does not depend on the loop's primary success path. Without one, a loop can run indefinitely if the success condition is never met. Common exit conditions include a maximum iteration count (evaluated by a Routing node that counts how many times the loop has executed), a timeout, or a hard-fail branch that routes to a Human Review node when the loop has run more than a defined number of times. Build the exit condition into the graph from the start, not as an afterthought.

A practical note on graph layout: loops create backward edges in the visual graph, which can make the canvas harder to read as the workflow grows. Use the Information node to annotate loop entry and exit points directly on the canvas. Information nodes have no effect on execution but make the graph self-documenting for anyone who edits it later.

Stopping is not failure: it is a deliberate design decision. A workflow should stop when it has reached a defined outcome, when a condition makes further execution unsafe or pointless, or when a human needs to make a decision that the workflow cannot make for them.

In DAVE's Workflow Editor, every terminal path must end at an End node. A workflow can have multiple End nodes, one for each distinct outcome. This is not just a technical requirement: multiple End nodes make the graph self-documenting. A graph with End nodes labeled Published, Rejected, and Escalated communicates the workflow's possible outcomes at a glance.

Three types of stop

• Success stop. The workflow has completed its intended purpose. Content has been approved and published, a report has been delivered, or a task has been completed. Route to an End node labeled with the positive outcome.
• Rejection stop. A reviewer has rejected the content, a safety check has returned a blocking result, or a compliance check has found a non-compliant item. Route to an End node labeled with the rejection outcome. Do not loop indefinitely on a rejection: after a defined number of revision cycles, route to a rejection End node or an escalation step.
• Escalation stop. The workflow has reached a condition it cannot resolve automatically. A loop has exceeded its maximum iteration count, a safety check has returned a HIGH risk verdict, or a required field is missing after multiple attempts. Route to a Human Review node for a human decision, and from there to an appropriate End node based on the reviewer's verdict.

Dangling paths: the silent failure mode

A dangling path is a node with no outgoing edge that is not an End node. At runtime, a workflow instance that reaches a dangling node has nowhere to go and will hang indefinitely. The Workflow Editor does not prevent you from saving a graph with dangling paths, so it is your responsibility to check that every non-terminal node has at least one outgoing edge and that every path through the graph eventually reaches an End node. The node and edge counter in the top-right corner of the canvas helps you audit the graph: if the edge count is significantly lower than you expect relative to the node count, look for unconnected nodes.

The Routing node is the most versatile structural tool in DAVE's Workflow Editor. It is a logic-only node: it evaluates output port criteria and routes execution to the correct next step without creating tasks, invoking agents, or producing any output of its own. Because it has no side effects, you can add, remove, or reconfigure a Routing node without affecting the functional nodes around it.

Three patterns cover the majority of real-world use cases.

Pattern 1: Decision dispatcher

Place a Routing node immediately after any node that produces a decision or verdict (Human Review, Agent Review, Safety). Connect the Routing node to one downstream node per possible outcome. Add a routing rule on each outgoing edge matching the corresponding decision value. The Routing node reads the decision from the workflow context and dispatches to the correct branch. This keeps branching logic out of the functional node and makes it easy to add a new branch (a new outcome) without touching the Human Review or Agent Review node configuration.

Pattern 2: Content type dispatcher

Place a Routing node after a User Interaction node that collects a content type, category, or priority field. Connect the Routing node to one downstream agent or sub-path per content type. Add a routing rule on each outgoing edge matching the corresponding field value. This pattern lets a single workflow entry point serve multiple content types without duplicating the upstream steps.

Pattern 3: Loop controller

Place a Routing node after the step whose result determines whether to repeat or continue. Add two outgoing edges: one with a routing rule for the repeat condition (pointing back to the loop entry node) and one with a routing rule for the exit condition (pointing forward). Add a third edge for the loop overflow condition (pointing to a Human Review node or a rejection End node) so the loop cannot run indefinitely. The Routing node is the only node in the loop that contains branching logic, which makes the loop easy to audit and modify.

Routing rules: field, operator, value, priority

Each routing rule on an edge specifies four things: the field in the workflow context to evaluate, the operator (such as equals, contains, greater than), the value to compare against, and the priority that determines which rule is evaluated first when multiple outgoing edges have rules. DAVE evaluates rules in priority order and follows the first edge whose condition is satisfied. If no rule is satisfied, execution follows the default edge (an edge with no rule). If there is no default edge and no rule is satisfied, the instance will hang at the Routing node, so always ensure at least one edge can be satisfied for every possible input value.

Before you save a new workflow version, run through this checklist in the Workflow Editor. It covers the most common structural mistakes that cause workflow instances to hang, loop indefinitely, or reach an unexpected end state.

• One Start node. Every workflow must have exactly one Start node. The editor does not enforce this at save time, but a workflow with no Start node or more than one cannot execute correctly.
• Every path ends at an End node. Trace every possible execution path through the graph. Each path must terminate at an End node. Use the node and edge counter in the top-right corner of the canvas to spot unconnected nodes.
• Every branch has a routing rule. If a node has more than one outgoing edge, every edge should have an explicit routing rule. Relying on a single default edge when multiple edges are present leads to unpredictable routing.
• Every loop has an exit condition. If the graph contains a backward edge (a loop), confirm there is a routing rule that exits the loop when a maximum iteration count or a hard-fail condition is reached.
• Routing nodes separate logic from function. Branching logic lives in Routing nodes, not in Agent Interaction, Human Review, or Safety nodes. This keeps functional nodes focused on their task and routing logic easy to change independently.
• Node labels are descriptive. Change every default label (for example, "Routing" or "Human Review") to something specific (for example, "Route on Review Decision" or "Senior Editor Approval"). Descriptive labels make the graph self-documenting and reduce the chance of misconnecting nodes during edits.
• Information nodes annotate complexity. Drop an Information node next to any loop entry point, complex branch, or non-obvious routing rule to explain the intent. Information nodes have no effect on execution.
• Save before navigating away. The Workflow Editor does not auto-save. Each click of Save Version creates a new immutable version, so there is no risk of overwriting previous work. Save frequently.