Stop Rules

By the Syncfusion DevTutorials team · Last updated October 22, 2026

Goal conditions, iteration caps and no-progress detection. Watch a runaway loop burn its budget on a flaky test, then write the three rules that make every loop end.

What Stop Rules Do

A stop rule decides, after every turn, if the loop goes again or stops (see From Prompting to Loops).

In this lesson, you will write the three stop rules every loop needs.

A loop that never stops is not a loop. It is a bill.

Each rule catches a different problem:

• A goal a program can check ends the run when the job is done.
• An iteration cap ends the run when anything else goes wrong.
• A same-failure rule spots one ticket that is stuck.

Simple lesson: a loop is only safe to leave alone when it knows how to end.

A Real-World Example

Think about the lock screen on a phone.

You type your PIN. If it is right, the phone opens. A machine checked it, so there is no doubt.

If you are wrong, you may try again. But after a few tries, the phone makes you wait.

And if someone types the same wrong PIN again and again, they are not getting closer.

Now map this to a loop:

• The phone opens = the goal condition.
• Only a few tries = the iteration cap.
• The same wrong PIN again = no progress.

Click the button. You saw a runaway in From Prompting to Loops. This time, look at what it costs.

• The checker: it never calls #6 done. Good.
• The loop: it never stops trying #6. Bad.
• The scorecard: most of the tokens went on one ticket that could never pass.

Simple lesson: a checker stops a false "done". Only a stop rule stops the loop.

What You Will Learn

In this lesson, you will learn:

1. Why a goal must be something a program can check.
2. How to pick an iteration cap.
3. How to spot "no progress" with a failure line.
4. When to stop the loop and when to escalate a ticket.
5. How to read a run and tell which rule needs fixing.

Rule 1: A Goal a Program Can Check

Goal Condition

Goal condition = a check that tells the loop the job is done. A program must be able to answer it with yes or no.

Goals a program can check:

• pnpm test passes for every ticket
• src/lib/export.ts exists and its test passes

Goals that are a feeling:

• make it work
• make the board feel faster

What a Feeling Does to a Loop

Click the button. Every ticket gets fixed. Then the loop keeps going, because nothing can say "it works now".

Here is the same idea, step by step:

• Frame 1: the work is done, but every turn after that finds nothing to do.
• Frame 2: a cap ends the run. But a cap is not a goal. You still cannot tell if the job is done.

Goals in Each Tool

Real tools have goal loops too.

Simple lesson: if a program cannot check your goal, your loop cannot finish.

Rule 2: An Iteration Cap

What a Cap Is

Iteration cap = the most turns one run may take. In the loop file it is max_iterations.

When the loop reaches the cap, it stops. No matter what.

The cap is your backup. A good run should end on its goal, long before the cap.

Picking a Cap

Too low, and good work is cut off. Too high, and a runaway costs a lot before it stops.

A simple way to pick one:

1. Give each ticket one turn.
2. Give each ticket one more turn, for a broken first fix.
3. Add the same_failure turns, for one stuck ticket.

Example:

• 6 tickets: 6 turns
• one retry each: 6 more turns
• same_failure: 3: 3 more turns
• cap: 15

In short: cap = 2 × tickets + same_failure.

Simple lesson: set the cap from the work: about twice the tickets, plus room for one stuck ticket.

Rule 3: No-Progress Detection

Failure Lines

A loop makes no progress when it tries again and gets the same result. A flaky test is the classic case.

To spot it, the loop compares failure lines. A failure line is the short message that says what failed:

FAIL src/lib/sort.test.ts > sorts by due date (timeout after 5000 ms)

same_failure = how many times in a row one ticket may fail with the same line. With same_failure: 3, the third same failure means "stop trying this ticket".

Stop, or Escalate?

When no progress is found, the loop has two choices:

• Stop the whole loop. Safe, but the other tickets wait.
• Escalate the stuck ticket. Send it to a person with its evidence, then move on.

Escalate = hand a ticket to a person instead of trying again. In the loop file, escalate: triage-inbox names where it goes.

Watch both choices on the same work:

Step through all three frames.

• Frame 1: no escalate target. One stuck ticket stops everything.
• Frame 2: #6 goes to the inbox. The rest are fixed, and the goal is met.
• Frame 3: what the person finds: why it was sent, and the failure line.

Simple lesson: escalate a stuck ticket, so one problem does not block the whole run.

All Three Rules Together

Same Work, Different Rules

Each rule catches a different problem. Watch the same four tickets with three different stop settings:

• Frame 1: all three rules. The goal ends the run. The cap is never needed.
• Frame 2: no same_failure. #6 eats the turns, and the cap ends the run with work undone.
• Frame 3: a cap of 4. Good work is cut off.

In the Loop File

Put together, the three rules look like this:

trigger:
  goal: "pnpm test passes for every ticket in this run"
stop:
  max_iterations: 15
  same_failure: 3
escalate: triage-inbox

Simple lesson: the goal ends a good run. The cap ends a bad one. same_failure stops one stuck ticket from ruining both.

Write the Stop Rules

Lab Exercise: A Goal, a Cap and a Same-Failure Rule

This loop has a goal that is a feeling, and no stop rule.

Click the button to open the loop file in the lab.

1. Replace make it work with a goal a program can check. Use your test command.
2. Add a stop: block with max_iterations: and same_failure:.
3. Press Check my loop.

Your loop passes when, on all 3 versions:

• the run ends because the goal is met
• flaky ticket #6 lands in the inbox

Simple lesson: a safe loop has all three rules, and an inbox for what it cannot fix.

TL;DR

1. Stop rules = the checks after every turn: go again, or stop.
2. Goal condition = a yes-or-no check a program can run, such as pnpm test passing.
3. Iteration cap = max_iterations, the most turns one run may take.
4. Picking a cap = 2 × tickets + same_failure.
5. No progress = the same failure line again and again.
6. same_failure = how many same failures in a row before the loop gives up on a ticket.
7. Escalate = send the stuck ticket to a person with its evidence, then move on.
8. Reading a run = find the rule that fired, then fix the rule that was missing.

Common mistakes

Check Your Understanding

Exercises

Press Check when you are ready. Use Show Hint if you get stuck.

What to Remember

• Every loop needs three stop rules: a goal, a cap, and a same-failure rule.
• A goal must be something a program can check. "Make it work" never ends.
• Set the cap from the work: 2 × tickets + same_failure.
• same_failure: 3 spots a stuck ticket, such as a flaky test.
• Escalate a stuck ticket to a person, and keep going with the rest.

Further Reading

• Loop Engineering and Autonomous Agent Systems, by Rick Hightower: "no stop condition means a runaway".
• Loop Engineering, by Addy Osmani: /goal and how its condition is checked.
• Loop engineering: designing loops you can walk away from, by CodeRabbit: designing loops that end safely.

Next: Triggers. A goal loop runs once and misses tomorrow's failures, so you turn it into a daily loop.