Summary

A review loop runs a review node, routes failures back to an earlier generation step, and only advances when the review passes. This guide shows how to wire that pattern using Human Review and Agent Review nodes, output ports, and routing rules.

The steps

1
Plan your loop: identify the review node and the regeneration step
Before touching the canvas, decide two things: which node performs the review, and which node the instance should return to when the review fails.
DAVE provides two review node types:
- Human Review (amber eye icon): Creates a task for a human reviewer. The reviewer can approve, reject, or request changes. The workflow branches based on the decision. Use this when a person needs to make the quality judgment.
- Agent Review (pink bot icon): An AI-powered automated quality check. An agent evaluates content against defined criteria and returns a pass or fail result. Use this for high-volume or consistent criteria that do not require human judgment.
The regeneration step is the node the instance returns to when the review fails. This is typically an Agent Interaction node that rewrites or revises the content, but it can be any node that produces a new version of the output for the review node to evaluate again.
The loop structure is: Regeneration node → Review node → branch on result → either advance (pass) or return to Regeneration node (fail).
Do this
- Decide whether the review is human (Human Review node) or automated (Agent Review node).
- Identify the node the instance should return to on failure. This is your regeneration step.
- Sketch the loop on paper or in a notes document before opening the editor: Regeneration → Review → Routing → (pass path) → next stage, (fail path) → back to Regeneration.
Example
You are building a content approval workflow. An Agent Interaction node drafts a blog post. A Human Review node lets an editor approve or reject it. If rejected, the instance should return to the Agent Interaction node so the agent can revise the draft. If approved, the instance advances to publishing. The loop is: Agent Interaction (Draft Post) → Human Review (Editor Approval) → branch → approved goes forward, rejected returns to Agent Interaction.
Best practice
- Keep the regeneration step as close to the review node as possible in the graph. A tight loop (one or two nodes between regeneration and review) is easier to reason about and debug than a loop that spans half the workflow.
- If the regeneration step needs to know why the review failed (the reviewer's comments, the agent's rejection reason), ensure those values are captured as workflow fields before the instance routes back. The regeneration agent can then reference them in its revision prompt.
2
Place the nodes on the canvas
Open the Workflow Editor for your workflow. You need at minimum: a Start node, a Regeneration node (typically Agent Interaction), a Review node (Human Review or Agent Review), and an End node. You may also want a Routing node to make the branching logic explicit and separate from the review node itself.
Drag each node from the Node Palette on the left onto the canvas. Drop them in a vertical sequence that represents the forward (pass) path: Start at the top, then Regeneration, then Review, then End. Leave space below the Review node for the routing logic, and space to the left or right for the back-edge that returns to the Regeneration node.
Rename each node in the Properties Panel to describe its purpose. Change "Agent Interaction" to "Draft Content", "Human Review" to "Editor Approval", and so on. Self-documenting node names make the loop logic readable at a glance.
Do this
- Drag a Start node onto the canvas and place it at the top.
- Drag your Regeneration node (Agent Interaction or other) below the Start node.
- Drag the Review node (Human Review or Agent Review) below the Regeneration node.
- Drag an End node for the pass outcome below or to the right of the Review node.
- Optionally drag a Routing node between the Review node and the branch destinations to make the branching logic explicit.
- Rename all nodes in the Properties Panel to describe their purpose.
Example
Canvas layout from top to bottom: Start → Draft Content (Agent Interaction) → Editor Approval (Human Review) → Routing node → two branches: "Approved" path goes to End, "Rejected" path returns left and up to Draft Content.
Best practice
- Use an Information node next to the loop to annotate the pattern. Drop one beside the back-edge and label it "Revision loop: returns to Draft Content on rejection". Information nodes do not affect execution but make the graph self-documenting for future editors.
- Position the Regeneration node with enough vertical space above the Review node that the back-edge (which will curve upward) is visually clear and does not overlap other nodes.
3
Connect the forward path with edges
Wire the forward (pass) path first. This is the sequence the instance follows when the review succeeds. Connect edges in order from the source handle (bottom circle) of each node to the target handle (top circle) of the next.
Forward path connections:
1. Start → Regeneration node
2. Regeneration node → Review node
3. Review node → Routing node (if using one), or directly to End (if branching from the Review node's own ports)
4. Routing node → End (pass branch)
To create each edge: hover over the bottom handle of the upstream node until it highlights, then click and drag to the top handle of the downstream node and release. The edge appears as an animated line.
Do this
- Connect Start to the Regeneration node.
- Connect the Regeneration node to the Review node.
- Connect the Review node to the Routing node (or directly to End if not using a Routing node).
- Connect the Routing node to the End node for the pass branch.
- Verify each edge appears as an animated line in the correct direction.
Example
You drag from the bottom of Start to the top of Draft Content. Then from the bottom of Draft Content to the top of Editor Approval. Then from the bottom of Editor Approval to the top of the Routing node. Then from the bottom of the Routing node to the top of End (this will be the approved branch, configured in the next step).
Best practice
- Build the forward path completely before adding the back-edge. A complete forward path is easier to verify visually, and the back-edge is easier to add once the forward structure is clear.
- If the Review node has multiple output ports (one per decision outcome), connect from the appropriate port for the pass outcome. The Properties Panel's Input/Output Ports section shows the available ports for the selected node.
4
Add the back-edge to close the loop
The back-edge is what makes the loop. It connects the fail branch of the Review node (or the Routing node downstream of it) back to the Regeneration node. When the instance follows this edge, it re-enters the Regeneration node, produces a new output, and returns to the Review node for another evaluation.
To add the back-edge:
1. Hover over the source handle (bottom) of the Review node or the Routing node on the fail branch.
2. Click and drag toward the target handle (top) of the Regeneration node.
3. Release over the target handle to create the edge.
Because the Regeneration node is above the Review node on the canvas, this edge will curve upward and to the side. The canvas renders it as a curved animated line. This is expected: the visual curve represents the loop.
After adding the back-edge, configure its routing rule (see Step 5) so the instance only follows it when the review fails. Without a routing rule, the instance may follow the back-edge unconditionally, creating an infinite loop.
Do this
- Hover over the bottom handle of the Review node (fail port) or the Routing node (fail branch output).
- Click and drag to the top handle of the Regeneration node.
- Release to create the back-edge. Confirm it appears as a curved animated line connecting back upward.
- Proceed immediately to Step 5 to configure the routing rule on this edge. Do not save without configuring the routing rule.
Example
You drag from the bottom of the Routing node's fail output port to the top of Draft Content. A curved line arcs upward and to the left, connecting back to the Regeneration node. The canvas now shows a visible loop: Draft Content → Editor Approval → Routing → (approved) End, (rejected) → back to Draft Content.
Best practice
- Add the back-edge last, after the forward path is complete and verified. This keeps the graph readable during construction.
- If your canvas becomes cluttered with the back-edge overlapping other nodes, reposition the Regeneration node or the Review node to give the curved edge a clear path. The canvas is free-form: node positions are for readability only.
5
Configure routing rules on the branch edges
Routing rules determine which edge the instance follows when a node has multiple outgoing connections. Without routing rules, the instance behavior at a multi-output node is undefined. For a review loop, you need at minimum two routing rules: one for the pass outcome (advance to the next stage) and one for the fail outcome (return to the Regeneration node).
Routing rules are configured in two places depending on your graph design:
- On a Routing node: Select the Routing node and open the Routing Configuration section in the Properties Panel. Configure the branch criteria for each output port.
- On an edge: Select the edge and configure its routing rule. Each rule specifies a field, an operator, a value, and a priority.
For a Human Review node, the review decision is captured as a workflow field. The reviewer's choice (approve, reject, or request changes) determines which branch the instance follows. Configure the pass routing rule to match the approved decision value, and the fail routing rule to match the rejected or changes-requested decision values.
For an Agent Review node, the agent's evaluation returns a pass or fail result. Configure the routing rules to branch on that result field.
Priority determines which rule is evaluated first when multiple rules could match. Assign a lower priority number to the rule you want evaluated first.
Do this
- Select the Routing node (or the Review node if branching directly from it) and open the Properties Panel.
- In the Routing Configuration or Input/Output Ports section, configure the pass branch: set the field, operator, and value to match the approved or pass outcome.
- Configure the fail branch: set the field, operator, and value to match the rejected, changes-requested, or fail outcome.
- Set priorities so the pass rule and fail rule are evaluated in the correct order.
- Select each outgoing edge and confirm its source port matches the port name configured in the routing rule.
Example
On the Routing node downstream of Editor Approval, you configure two branches. The pass branch matches the Human Review decision field equal to the approved value, with priority 1, and its edge leads to End. The fail branch matches the decision field equal to the rejected or changes-requested value, with priority 2, and its edge leads back to Draft Content. When the reviewer approves, the instance follows the pass branch. When the reviewer rejects or requests changes, the instance follows the fail branch and loops back.
Best practice
- Use a Routing node to hold the branching logic rather than putting routing rules directly on the Review node's output edges. This keeps the review node focused on the review task and makes the branching logic visible and editable in one place.
- Test each branch explicitly during development. Run a test instance, approve the review, and confirm the instance advances to End. Run another test instance, reject the review, and confirm the instance returns to the Regeneration node and re-enters the loop.
6
Save a version and run a loop test
When the graph is complete and routing rules are configured, click Save Version in the top-right corner of the editor. This creates a new immutable version of the workflow graph. Previous versions are preserved.
Run a test instance and exercise both paths:
1. Test the pass path: Progress the instance to the Review node. Approve (for Human Review) or allow the agent to pass (for Agent Review). Confirm the instance advances to End.
2. Test the fail path: Run a second test instance. Progress to the Review node. Reject or request changes (for Human Review) or allow the agent to fail (for Agent Review). Confirm the instance returns to the Regeneration node. Then progress through the Regeneration node again and return to the Review node. Approve on the second attempt. Confirm the instance advances to End.
If the instance does not loop back as expected, check the routing rules on the fail branch edge and the Routing node configuration. Confirm the field name and value in the routing rule match the actual field and value produced by the Review node at runtime.
Do this
- Click Save Version in the top-right corner. Confirm the version is saved.
- Start a test instance and run it to the Review node.
- Approve the review. Confirm the instance reaches End.
- Start a second test instance. Reject the review. Confirm the instance returns to the Regeneration node.
- Progress through the Regeneration node again. Return to the Review node. Approve. Confirm the instance reaches End.
- If either path fails, review the routing rule configuration and save a corrected version.
Example
First test: you run the instance, the agent drafts content, the editor approves in the Task Inbox, the instance advances to End. Pass path confirmed. Second test: you run the instance, the agent drafts content, the editor rejects with a comment, the instance returns to Draft Content, the agent revises using the rejection comment in its context, the editor approves on the second attempt, the instance reaches End. Loop confirmed.
Best practice
- Test with a real rejection comment if using Human Review. Confirm that the rejection reason is available to the Regeneration agent as a workflow field. If it is not, add a field mapping before the back-edge so the agent can reference it in its revision prompt.
- Save a version after each successful test. This gives you a clean restore point and a version history that documents the evolution of the loop design.

What a review loop is and when to use it

A review loop is a workflow pattern where a review step can send the instance backward to an earlier node when the review fails, rather than always advancing forward. The instance cycles through the regeneration and review steps until the review passes, then continues to the next stage.

This pattern is appropriate when:

Quality is non-negotiable: The output must meet a defined standard before the workflow can proceed. A single review pass is not sufficient because the first attempt may not meet the bar.
Revision is automated or low-cost: The regeneration step (typically an AI agent) can produce a revised output quickly. If revision requires significant human effort, a loop may not be the right pattern: a linear review-and-edit flow may be more appropriate.
The review criteria are consistent: The same criteria apply on every iteration. If the criteria change between attempts, the loop may never converge.

Common use cases for review loops include: AI-generated content that must pass editorial review before publication, documents that must meet compliance criteria before filing, agent outputs that must pass an automated quality check before being sent to a customer, and proposals that require approval before proceeding to the next stage.

A review loop is not appropriate when the review is exploratory (the reviewer does not know what they are looking for until they see it), when the regeneration step is expensive or slow, or when the number of iterations is unbounded and there is no exit condition other than eventual approval.

Human Review and Agent Review: choosing the right node

DAVE provides two review node types. The choice between them determines who or what makes the quality judgment on each iteration of the loop.

Human Review (amber eye icon)

The Human Review node creates a task for a human reviewer. The reviewer opens the task in their Task Inbox, evaluates the content, and selects a decision: approve, reject, or request changes. The workflow branches based on that decision. The reviewer can also leave comments that become part of the workflow context.

Use Human Review when:

The quality criteria require human judgment, taste, or domain expertise that an AI agent cannot reliably replicate.
The output will be seen by customers, executives, or regulators, and a human must be accountable for the approval.
The review criteria are subjective or context-dependent in ways that are difficult to specify as rules.

Agent Review (pink bot icon)

The Agent Review node invokes an AI agent to evaluate the content against defined criteria and return a pass or fail result. No human task is created. The evaluation runs automatically when the instance reaches the node.

Use Agent Review when:

The quality criteria are explicit, consistent, and can be expressed as instructions to an AI agent.
The volume of instances is high enough that human review on every iteration would be a bottleneck.
Speed matters and the criteria do not require human accountability.

Combining both in one loop

You can use both node types in the same loop. A common pattern is to run an Agent Review first (fast, automated, catches obvious failures) and only route to Human Review when the Agent Review passes (ensuring the human reviewer only sees outputs that have already cleared the automated bar). This reduces the human reviewer's workload without removing the human quality gate.

How routing rules and output ports control the loop

The loop depends on routing rules to determine which branch the instance follows after the review node. Without correctly configured routing rules, the instance will not loop correctly.

Every node except Start and End has an Input/Output Ports section in the Properties Panel. This section defines the named output ports from which edges can originate, and the routing criteria that determine which port is used for a given outcome.

The Routing node (purple GitFork icon) is a logic-only node designed specifically for conditional branching. It evaluates output port criteria and routes execution without creating tasks or invoking agents. Using a Routing node to hold the branching logic for a review loop has two advantages:

The review node stays focused on the review task. Its configuration is not cluttered with branching logic.
The branching logic is visible and editable in one place. If the criteria change, you edit the Routing node without touching the review node.

Each routing rule on a Routing node specifies:

Field: The workflow field whose value is being evaluated.
Operator: The comparison to apply (for example, equals, contains, or similar).
Value: The value to compare against.
Priority: The order in which rules are evaluated when multiple rules could match. Lower numbers are evaluated first.

For a review loop, configure one routing rule for the pass outcome (pointing forward to the next stage) and one for the fail outcome (pointing back to the Regeneration node). Assign priorities so the rules are evaluated in the correct order.

Design considerations: convergence, exit conditions, and context

A review loop that is not carefully designed can run indefinitely, confuse reviewers, or fail to improve between iterations. Three design considerations reduce these risks.

Convergence: does the loop make progress?

Each iteration of the loop should produce a meaningfully different output. If the Regeneration agent does not receive information about why the previous attempt failed, it will produce the same output again, and the loop will not converge. Ensure the rejection reason, the reviewer's comments, or the agent's failure criteria are captured as workflow fields and passed to the Regeneration agent as context on each iteration.

Exit conditions beyond approval

Consider what happens if the review never passes. A loop with no exit condition other than approval can run indefinitely. Options for adding a secondary exit condition include:

A Routing node that counts iterations (if the workflow tracks attempt number as a field) and routes to a different End node (for example, "Escalate" or "Abandon") after a defined number of failures.
A Human Review node that can escalate rather than simply reject, routing to a different path when escalation is chosen.

The Workflow Editor does not enforce a maximum iteration count automatically. Exit condition design is the workflow author's responsibility.

Reviewer context on each iteration

If using Human Review, the reviewer should see not just the current output but also the history of previous attempts and rejection reasons. Ensure the workflow fields passed to the Human Review node's task context include the revision history, not just the latest output. A reviewer who cannot see why previous attempts failed is less able to give useful feedback on the current attempt.

Frequently asked questions

Can I loop more than once?

Yes. The loop runs as many times as needed until the review passes or an alternative exit condition is triggered. Each iteration follows the same path: Regeneration node, then Review node, then routing. There is no built-in limit on the number of iterations.

Can I have two review nodes in the same loop?

Yes. You can chain an Agent Review node and a Human Review node in sequence within the same loop. The instance passes through both on each iteration. If either fails, the instance routes back to the Regeneration node. Configure routing rules after each review node to handle the fail branch.

What roles can configure the loop in the editor?

Only the Admin and Curate roles can open the Workflow Editor, add nodes, connect edges, and save versions. DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by your administrator. Users with the Use role can complete review tasks in their Task Inbox during a running instance but cannot edit the workflow graph.

Can the Regeneration node be something other than an Agent Interaction node?

Yes. The Regeneration node is whatever node produces the output that the review node evaluates. It could be a User Interaction node (asking a human to revise their submission), an API Call node (fetching a revised record from an external system), or another Agent Interaction node. The loop pattern works with any node type that produces an output for the review node to evaluate.

How do I pass the reviewer's comments back to the agent?

The Human Review node captures the reviewer's decision and comments as workflow fields. Ensure these fields are included in the context passed to the Regeneration agent. Configure the agent's prompt to reference the rejection reason field so the agent knows what to revise on the next iteration.