Build a Self-Correcting Loop

A self-correcting loop is a stage that does work, verifies its own result, and routes back to itself to try again until the result passes a check. It is the workflow expression of the pattern the industry now calls an agent loop: give a goal, generate an action, execute it, verify the outcome, and decide whether to iterate.

Goal → Generate → Execute → Verify → Decide
              ↑                          |
              └─────── retry on fail ────┘

In ORQO this is not a new feature — it is what outcome routing has always done. A stage whose failing outcome routes back to itself is the loop. What makes the loop reliable is where the verdict comes from: instead of trusting the agent to declare "done", you compute the outcome deterministically with an exit hook.

Agent self-report vs. deterministic verification

A stage outcome can be set two ways:

Source	How it works	When to use
Agent-emitted	The agent decides which outcome best describes its work.	Soft judgments ("needs_revision") where no objective check exists.
Hook-computed	An exit hook with Sets outcome runs a tool whose return value becomes the outcome.	Objective checks — tests pass, schema validates, build succeeds.

For a loop, prefer hook-computed outcomes. An agent asked "did the tests pass?" can talk itself into "yes"; a tool that actually runs the tests cannot. The hook's return value is written straight to the stage outcome and drives routing — no agent judgment in the path.

Why this matters

"Loops replace prompts" is the idea that you stop hand-tuning one perfect prompt and instead engineer the feedback system around the model. The deterministic exit hook is that feedback system: it is the Verify step, made objective.

Prefer to just ask?

This page shows how to do it manually. The faster, more common way is to describe what you want to the Workflow Assistant — it builds the team, stages, agents, and assignments for you, then you fine-tune by hand using the steps below.

Prerequisites

• A workflow with a stage that does the work (see Add Stages and Set Up Assignments).
• A tool that performs your check and returns a value matching one of your outcomes. Build one with the Tool Builder or bundle it in a Skill. The tool runs in the stage's runtime, so it can execute a command (run the test suite, lint, a schema check) and return, for example, the string "pass" or "fail".

Steps

1. Define the stage outcomes

Open the stage's Routing tab and add the outcomes your check produces — keep them binary:

• pass — the work is correct
• fail — the work needs another attempt

See Outcomes & Routing for the outcome model.

2. Add a verification exit hook

On the same stage, open the Hooks tab and add an exit hook:

1. Select your verification tool (the one that runs the check).
2. Enable Sets outcome — the tool's return value becomes the stage outcome.
3. Enable Blocking — the stage waits for the verdict before routing, and a hook failure stops the run instead of being silently skipped.

The tool's inputs accept {{key}} placeholders pulled from stage data, so the check can read what the agent produced. See Configure Hooks.

3. Route the failing outcome back to the stage

In the Routing tab, map the outcomes:

Outcome	Target	Effect
fail	this same stage	Loops back for another attempt
pass	(none — or the next stage / End Workflow)	Advances when the check passes

Pointing fail at the stage's own name is the loop. pass left unrouted falls through to the next sequential stage.

4. Set the loop guard

Every backward route needs a stop rule. Set Max Stage Visits on the stage (default 5). After that many entries the loop is broken and execution advances regardless — so an unconvergeable check escalates instead of running forever. Pair it with Max Cycles to cap work within a single attempt. Both are documented under Loop Guards.

warning

A loop with no guard can run until it exhausts your run budget. Always set Max Stage Visits when a stage routes back to itself or to an earlier stage.

5. Make the failure feedback land in stage data

A loop only converges if each retry knows why the last attempt failed. Have your verification tool write its diagnostics (the failing test names, the validation errors) to stage data via the hook's output key. The agent re-entering the stage reads that context and fixes the specific problem instead of blindly redoing the same work. Without this, the loop is a blind retry that burns through the guard.

Common patterns

Pattern	Work stage produces	Verification tool checks	fail routes to
Test-fix loop	Code changes	Runs the test suite	Same stage
Lint-fix loop	Generated code	Runs the linter	Same stage
Schema-validation loop	Structured data	Validates against a schema	Same stage
Research-sufficiency loop	Gathered findings	Coverage / citation check	Same stage

Each is the same shape: an agent acts, a deterministic hook judges, and fail loops back under a visit cap.

What's next

• Use Outcome Routing — branching and looping in depth
• Configure Hooks — entry and exit hook setup
• Run a Workflow — watch the loop iterate in the run view

Learn more

• Reference: Outcomes & Routing
• Reference: Hooks
• Reference: Human-in-the-Loop — the same mechanism with a person as the verifier