From Prompting to Loops

By the Syncfusion DevTutorials team · Last updated

Stop being the person who types every prompt. See the reason, act, observe cycle of one agent, then put a loop around it with four parts: a trigger, an agent, a verifier and a stop rule.

What Loop Engineering Is

Loop engineering = building a system that keeps your coding agent working, so you stop prompting it by hand.

In this lesson, you will learn the four parts every loop needs. You will also see what goes wrong when one is missing.

A coding agent can fix one ticket well. But someone still has to start it, check it and hand it the next ticket.

Today, that someone is you.

For example, you have five tickets. For each one you:

  • ask the agent for a fix
  • ask it to run the tests
  • read the result and pick the next ticket

Nothing moves while you are away.

Simple lesson: if you type every next step, you are the loop.

A Real-World Example

Think about washing dishes.

By hand, you scrub a plate, rinse it and look at it. Then you pick up the next plate. You stand at the sink the whole time.

A dishwasher is different. You press Start. It washes. A sensor checks the water. When the cycle ends, it stops by itself.

You come back only to look at the clean plates.

A loop is a dishwasher for tickets:

  • Start button = the trigger.
  • Washing = the agent doing the work.
  • Sensor = the verifier. It is not the part that washes.
  • End of the cycle = the stop rule.
  • You looking at the plates = your verdict.

Five tickets, prompted by hand

Click the button and watch the chat in the Loop Lab.

  • The blue lines: messages that you had to type.
  • Ticket #2: the first fix is broken, so you go round one more time.
  • The total: every ticket needed you at least three times.

Simple lesson: the agent did the work, but you did the waiting and the starting.

What You Will Learn

In this lesson, you will learn:

  1. Where loop engineering sits next to prompt, context and harness engineering.
  2. The reason, act, observe cycle inside one agent run.
  3. The four parts every loop needs.
  4. What goes wrong without a verifier.
  5. What goes wrong without a stop rule.
  6. The two shapes of loop: goal loops and cadence loops.
  7. Three jobs a loop never does for you.

About the Loop Lab

  • The Loop Lab sits at the bottom of every page in this course.
  • It holds a small starter project with a backlog of 20 tickets.
  • It runs a simulated loop. The loop follows fixed rules, so it gives the same result every time. That is how your loops can be checked.
  • Nothing is downloaded, and nothing leaves your browser.

The Ladder: Four Kinds of Engineering

There are four kinds of engineering for AI. Each one wraps the one inside it.

Each layer wraps the one inside it. Loop engineering runs your harness by itself, on a schedule or until a goal is met.

  1. Prompt engineering shapes one request.
  2. Context engineering shapes what the model can see.
  3. Harness engineering builds the place where one agent works: rules, tests and hooks.
  4. Loop engineering runs that harness by itself, again and again.

A harness makes one agent run go well. A loop makes many runs happen without you.

That is why a loop needs a harness first. A loop around a bad harness only makes bad work faster.

Simple lesson: fix how one run works first. Then repeat it with a loop.

Inside One Agent Run

Reason, Act, Observe

One agent run is a small cycle of three steps:

  1. Reason. It decides what to try next.
  2. Act. It uses a tool. It edits a file or runs a command.
  3. Observe. It reads the result. The result guides the next Reason.

Watch the agent work on ticket #2, the one with a broken first fix:

Press Play, or use Next to go one step at a time.

  • Frame 3: the tests fail. That is not the end. It is useful news.
  • Frame 4: the agent tries again, and the tests pass.
  • Frame 5: ticket #2 is done. In a loop, the next run starts by itself.
  • The "What this shows" panel: which step of the cycle is happening.

What the Cycle Cannot Do

On its own, the agent stops after one ticket. It waits for someone to bring the next one.

By hand, that someone is you. In a loop, the loop does it.

Simple lesson: the cycle lives inside one run. Loop engineering is about what happens between runs.

The Four Parts of a Loop

Loop = a system that does your part of the job.

It does four jobs for you:

  • finds the next ticket
  • hands it to the agent
  • checks the result
  • decides what happens next

Every loop has four parts. You will see them in every tool.

Trigger, agent, verifier, stop rule. The dot is one turn of the loop.

Part 1: The Trigger

Trigger = what starts the loop.

There are three kinds:

  • A schedule. For example, every morning at 9.
  • An event. For example, when the build fails.
  • A goal. For example, keep going until pnpm test passes for every ticket.

Part 2: The Agent

Agent = the part that does one ticket per turn.

Inside, it runs the reason, act, observe cycle you just watched. In this course we also call it the maker, because it makes the change.

Part 3: The Verifier

Verifier = the part that checks the agent's work. It is not the agent. In this course we also call it the checker.

This matters, because an agent that grades its own work almost always says "done".

Part 4: The Stop Rule

Stop rule = the rule that decides: go round again, or stop.

For example:

  • stop when the goal is met
  • stop after 15 turns, whatever happens
  • stop trying a ticket that fails the same way 3 times, and ask a person

See the Four Parts Work

Here is a real loop file, then the loop running on five tickets, one turn per frame:

Step through all five frames.

  • Frame 1: the loop file. Each part is a few lines.
  • Frame 3: the verifier rejects the broken fix to #2. The ticket goes round again.
  • Frame 4: the second try passes.
  • Frame 5: the goal is met. The stop rule ends the loop. Nobody pressed Stop.

The same five tickets, run by a loop

Click the button to run the same loop in the Loop Lab. Then open the Compare tab.

Which of Your Jobs Does the Loop Take?

Go back to the chat you typed by hand for ticket #2. Each of your messages has a loop part waiting to replace it:

  • "Fix #2": the trigger starts the work and hands out the ticket.
  • "Run the tests" and "It still fails": the verifier checks every fix and sends a broken one back.
  • "Mark it done, pick the next": the stop rule decides what happens next.
  • "Read the diff": this one stays with you. It is your verdict.
  • Frame 5: by hand, 16 messages. With a loop, one press of Run.

A loop does not make the work smaller.

  • The agent still does every turn.
  • It still uses tokens, the small pieces of text a model reads and writes.
  • The loop moves the work off you. That is the whole point.

Loops in Each Tool

Each tool can run a loop. The ideas are the same. Only the names change.

The tab starts on the tool you picked at the top of this page. Each row has a badge:

  • feature: it is in the tool's official docs.
  • rolling out: it is in the docs, but not everyone has it yet.
  • pattern: you build it from other parts, because there is no single command.

Simple lesson: a loop is four parts: a trigger, an agent, a verifier and a stop rule.

Take One Part Away

The fastest way to see why a part matters is to remove it.

Step through all three frames.

  • Frame 1: no verifier. Ticket #2 is marked done, but its tests fail.
  • Frame 2: no stop rule. A flaky ticket is tried again and again.
  • Frame 3: the stop rule is back. The stuck ticket goes to a person, and the rest get done.

No Verifier: A Chain of Calls

Without a verifier, a loop is just a chain of calls. Each call says "done". Nothing checks it.

No verifier: just a chain of calls

Click the button and look for the red self-graded label on ticket #2.

  • The scorecard: 1 false "done".
  • Who finds it: nobody, until a user hits the bug.

No Stop Rule: A Runaway

Without a stop rule, a loop is a runaway. If one ticket can never pass, the loop keeps trying it.

A common cause is a flaky test.

Flaky test = a test that fails sometimes, for reasons that have nothing to do with your change. For example, it waits for a timer that is sometimes too slow.

No stop rule: a runaway loop

Click the button and watch ticket #6 fail the same way, turn after turn.

Important: a real loop has no lab to pull the plug.

  • It may run at night and at weekends.
  • A runaway loop can spend a month's budget before anyone looks.
  • Never start a loop without a stop rule.

Simple lesson: no verifier means "done" is only a claim. No stop rule means the loop may never end.

Two Shapes of Loop

Goal Loops and Cadence Loops

Goal loop = runs once, until a goal is true.

Cadence loop = runs again and again, on a schedule.

Goal loopCadence loop
StartsOnce, when you start itAgain and again, on a schedule
EndsWhen a checkable goal is trueWhen this run's work is done, until next time
ExampleFix these 5 tickets until pnpm test passesEvery morning at 9, look at new CI failures

A Goal a Program Can Check

A goal loop needs a goal that a program can check. Otherwise it never knows it is finished.

Goals a program can check:

  • pnpm test passes for every ticket
  • dotnet build passes

Goals that are a feeling:

  • make the board feel faster
  • make it good

Simple lesson: a goal loop needs a finish line a program can see. A cadence loop needs a schedule.

Three Jobs That Stay With You

A loop saves your time. It does not take away your job. Three jobs stay with you.

Checking the Result

"Done" is a claim, not proof. The verifier only checks what its rules tell it to check.

You still decide if the work is right. And only a check counts as evidence. "The agent says it ran the tests" is not evidence.

Comprehension Debt

A loop can ship code that nobody has read. Each unread change makes the project a bit harder to understand.

Comprehension debt = the growing gap between the code and what your team understands about it.

Cognitive Surrender

When a loop works well for a week, it gets easy to accept everything without looking.

Cognitive surrender = the habit of accepting the loop's results without reading them. It feels comfortable, and it is how bad changes slip through.

Simple lesson: the loop produces evidence. You produce the verdict.

Your First Loop

Lab Exercise: Give the Loop All Four Parts

The loop file in the lab has a trigger and an agent. Two parts are missing.

Give the loop all four parts

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

  1. Add a checker: with a rubric: that runs the tests.
  2. Add a stop: with max_iterations: and same_failure:.
  3. Press Check my loop.

The check runs your loop on 3 versions of the work. Each version puts the tickets in a different order.

Your loop passes when every version:

  • has 0 false "done"
  • stops because of a rule, not because of the lab's safety limit

Stuck? Read the Loop linter under the editor. It names each missing part.

Here is the shape of a checker. Each line under rubric: starts with two more spaces and a dash:

checker:
  rubric:
    - run pnpm test

Simple lesson: a loop is safe to leave alone only when it has all four parts.

TL;DR

  1. Loop engineering = building a system that keeps your agent working, so you stop prompting it by hand.
  2. Agent run = a small cycle:

    • reason
    • act
    • observe
  3. Loop = a system that runs the agent again and again, without you.
  4. Trigger = what starts the loop: a schedule, an event or a goal.
  5. Agent (maker) = does one ticket per turn.
  6. Verifier (checker) = checks the agent's work. It is not the agent.
  7. Stop rule = decides: go again, or stop.
  8. No verifier = a chain of calls. "Done" is only a claim.
  9. No stop rule = a runaway.
  10. Goal loop = runs until a checkable goal is true. Cadence loop = runs on a schedule.
  11. Your job = read the evidence and give the verdict.

Common mistakes

MistakeWrong ideaCorrect ideaWhat goes wrong
No verifier"The agent ran the tests, so it is checked."A separate checker, with its own rules, gives the verdict.Broken fixes are marked done.
No stop rule"It will stop when the work is done."Always set a turn limit and a same-failure rule.A flaky test is tried all night.
A goal that is a feeling"Make the board faster" is a fine goal.Name a check: a command, a file or a test.The loop never knows it has finished.
A loop with no harness"The loop will fix my messy project."Build the harness first. The loop repeats it.The loop makes bad work faster.
Trusting the loop blindly"It worked last week."Read the evidence for each result.Comprehension debt grows, and bugs slip through.

Check Your Understanding

Exercises

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

What to Remember

  • Loop engineering means you build a system that prompts the agent for you.
  • One agent run is a cycle: reason, act, observe. A loop starts that cycle again and again.
  • Every loop has four parts: a trigger, an agent, a verifier and a stop rule.
  • No verifier: a chain of calls. No stop rule: a runaway.
  • A goal loop stops when a checkable goal is true. A cadence loop runs on a schedule.
  • The loop produces evidence. You produce the verdict.

Further Reading

Next: State. A loop with no memory does the same ticket twice, and you give it one.