The Four Loops, Clearly Explained

This site uses cookies to understand how visitors find us.<br>You can accept or decline non-essential cookies.

Decline<br>Accept

Menu

manifesto<br>docs<br>blog<br>roadmap<br>registry

GitHub

Discord

install.sh

From how loop engineering is being talked about online, it may seem that<br>there is just one way to do it right. But in reality, loop engineering is<br>just a pattern, and there are a number of ways to implement it, with<br>different levels of ownership on the user vs the orchestrator.

(Interested in more background on loop engineering?<br>Read this post<br>first.)

Each approach to loop engineering is different on two parameters: what<br>starts a run , and what decides the work is done .

In a hand-run AI assistant chat session, you both start runs by writing<br>prompts, and decide when work is done by evaluating whether the output meets<br>your expectations. Loop engineering is the discipline of moving the<br>responsibility for starting runs and deciding you’re done out of your head<br>and into a system that runs without you.

In this article, we show how you can implement four different types of<br>agentic loops using iii.

Background: Workers, Triggers, and Functions

iii consists of three primitives: Workers, Triggers, and Functions.

Workers register functions. Triggers bind events to functions. The engine<br>routes between them.

While in many harnesses loops are a separate concept, in iii you get agentic<br>loops when you register a trigger whose function is another agent turn.<br>Therefore, with iii, every type of agentic loop is a traditional<br>distributed-systems pattern you already know, simply including an LLM turn<br>as part of a run.

The base case

Before the four types of loops, it helps to name the thing they’re all<br>working around. A turn is one pass through the agent: it reads context,<br>triggers functions, and ends when the model ends it.

The turn ending means the model decides it’s done for now and can’t<br>proceed, but not necessarily because the task is done. It could be that it<br>needs more input from a user or a loop to continue.

1. Turn-based: you are the loop

Trigger: a prompt you write.

Ends when: you say so.

Here is the turn-based loop running end to end:

In traditional terms: this is a REPL, a human at an interactive session.<br>You run a command, read the result, decide the next command. No scheduler, no<br>daemon, no shared state between runs, because you are the control loop.

The agent gathers context, acts, and checks its own work inside one turn,<br>then hands it back. You read it, decide what is missing, and write the next<br>prompt. No triggers get registered. Nothing runs later on its own. The loop<br>runs in your head, one exchange at a time.

The composability is still there. Any worker function the harness allows<br>(filesystem, git, database, HTTP) is triggerable inside the turn without<br>extra setup. You control when to continue and when to stop.

Technically, this is the simplest case there is: minimal trigger<br>registration, no evaluator, no schedule, no list. The task ends the same way<br>it started, inside a single turn, because a human is the only checkpoint the<br>work needs.

Use this when requirements are still forming, when every output changes what<br>you would ask for next. Automating the “what’s next” question here is<br>premature. You do not know it yet either. If you find yourself refining the<br>same prompt structure repeatedly, you are prototyping a worker function.<br>Eventually, this prompt can be extracted and registered as a permanent<br>function.

Use iii and Harness to investigate the following task:

[Describe the feature, bug, or idea.]

Work inside one turn:

1. Inspect the repository and gather the relevant context.<br>2. Explain the current behavior and identify ambiguities.<br>3. Propose the smallest sensible implementation.<br>4. If the requirements are sufficiently clear, implement it and run focused verification.<br>5. Review your own changes for regressions, security issues, and unnecessary complexity.

Do not invent requirements or begin a recurring workflow. Stop when you either:<br>- have a verified implementation, or<br>- need a product/technical decision from me.

End with:<br>- what you learned,<br>- what you changed,<br>- verification performed,<br>- unresolved questions,<br>- the best next prompt for me to send.<br>2. Goal-based: the check moves off you

Trigger: a task with success criteria.

Ends when: an evaluator function says to.

Here is the goal-based loop running end to end:

In traditional terms: this is a retry-until-valid control loop. Do work,<br>run a validator, and either accept the result or feed the failure back and<br>try again, up to a budget. Every CI pipeline that retries a flaky step, every<br>job that re-runs until a health check passes, is this pattern. The validator<br>is a function, the attempt counter is shared state, and the loop is the<br>retry.

Here a real trigger appears. Say the goal is a Lighthouse score of 90 on a<br>webpage, five attempts allowed. Instead of you reading the result and<br>deciding, you...