Loop Engineering: Designing the Agent Loop That Knows When to Stop

Around any AI model sits a set of supporting parts, and one of the most important is the agent loop. This piece zooms in on that loop and on how to engineer it so the agent behaves predictably, stays affordable and knows when to quit.

From one call to a cycle

A plain chatbot usually follows a single straight path:

User → LLM → Response

An agent has a harder job. Finishing one task can take several steps, with the model looking at what happened after each one:

User
 ↓
Understand the task
 ↓
Decide what to do
 ↓
Use a tool
 ↓
Observe the result
 ↓
Decide what to do next
 ↓
Use another tool
 ↓
Evaluate the result
 ↓
Finish

That repetition is the thing loop engineering deals with.

An agent loop is the cycle in which an AI agent keeps doing the following:

1. Take in information.
2. Pick what to do.
3. Carry out an action.
4. Look at the outcome.
5. Judge whether another action is needed.
6. Stop, eventually.

In simplified form the cycle looks like this:

┌───────────┐
        │  Observe  │
        └─────┬─────┘
              ↓
        ┌───────────┐
        │   Decide  │
        └─────┬─────┘
              ↓
        ┌───────────┐
        │    Act    │
        └─────┬─────┘
              ↓
        ┌───────────┐
        │  Observe  │
        │   Result  │
        └─────┬─────┘
              ↓
         Finished?
          /     \
        No       Yes
        ↓         ↓
     Decide     Stop

What matters is that one model call doesn't have to produce the final answer. The agent can act, learn from what comes back, and carry on.

A small example: weather in Bristol

Say a user asks, "What is the weather in Bristol and should I take an umbrella?" An agent could handle it in a handful of moves. It receives the question and works out that it needs current conditions. It then calls a weather API, which returns this:

Temperature: 16°C
Condition: Heavy rain

With that in hand, the agent has what it needs and replies that it's raining in Bristol, so an umbrella is a sensible idea. Even this tiny request took more than one operation.

Simple tasks exist too. A question like "What is 15 × 20?" needs a single operation. A heavier request is "Research three UK universities offering an MSc in Data Science and compare their tuition fees and entry requirements." That one might call for a sequence like this:

Search University A
      ↓
Read information
      ↓
Search University B
      ↓
Read information
      ↓
Search University C
      ↓
Read information
      ↓
Compare results
      ↓
Generate answer

No single reply from a language model can reliably cover all of that. The loop lets the agent split a large task into small actions.

Modelling the agent as a state machine

The agent's situation can be captured as a state. Let s_t be the state at time t. At each tick the agent is handed an observation o_t, picks an action a_t, and the world shifts into its next state:

In that expression, s_t is the current state, o_t the current observation, a_t the action, f the state-transition function and s_{t+1} the next state. The choice of action can be written compactly as well:

Here the Greek letter pi stands for the decision policy. In an LLM-based agent, the model forms part of that policy. A snapshot might look like this:

State:
"We need the current weather."


Observation:
"Weather tool is available."
Action:
"Call weather(location='Bristol')"

And after the tool answers:

New observation:
"16°C, heavy rain"


Next action:
"Generate final response"

Seeing the agent this way, as a system that changes state, is more useful than thinking of it as a chatbot with extra steps.

Knowing when to stop

The hardest question in loop design may be how an agent decides it's finished. Picture an agent stuck doing this:

Call search
 ↓
Get result
 ↓
Call search again
 ↓
Get result
 ↓
Call search again
 ↓
...

With no exit rule it could go on forever. A production agent therefore needs termination conditions. Several are common.

The first is the happy path, where the task is done:

Task completed → STOP

The second is a step budget, for example a maximum of five:

Maximum steps = 5

If the agent hits five steps without finishing, it halts:

STOP

The third is repeated tool failure, which should end the run or hand it to someone else:

Tool failed repeatedly → STOP / ESCALATE

The fourth is a risky action, where a person has to approve before anything happens:

High-risk action → STOP → Ask human

Cost, latency and reliability

Treat every step as something that costs money. Suppose the price per step is as follows:

A normal run of 10 steps then costs roughly this:

A bug that causes 1000 steps changes the total drastically:

For one request, that may already be unwelcome.

Multiply by thousands of users and the problem is plain. Loop engineering is therefore about cost, latency and reliability as much as about functionality.

Handling failure

Real systems break. Imagine the weather call returns this:

Error: API unavailable

A badly designed agent just fails. A better loop reacts to the error:

Tool call
   ↓
Error
   ↓
Retry?
 ┌─┴─┐
Yes  No
 ↓    ↓
Retry Escalate

Retries need limits as well. After two failures, for instance, the system can stop instead of sending the same doomed request again and again.

Where loops show up

Agent loops appear in many fields. Here are five typical cycles.

Research:

Search → Read → Compare → Search again → Summarise

Coding:

Read code → Modify code → Run tests → Observe errors → Fix → Test again

Data analysis:

Inspect data → Run analysis → Observe result → Create visualisation → Explain

Customer support:

Understand issue → Search knowledge base → Check customer data → Respond

Computer use:

Observe screen → Decide action → Click/type → Observe new screen → Continue

The common thread is simple: act, observe the result, then decide what comes next.

Uncontrolled versus controlled loops

Compare two designs. The first one hands the model a tool and lets it run:

LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
...

Nothing in it controls anything. The second design adds checkpoints around each step:

Task
 ↓
Observe
 ↓
Decide
 ↓
Validate action
 ↓
Execute
 ↓
Observe result
 ↓
Evaluate
 ↓
 ┌───────────────┐
 │ Goal complete?│
 └───────┬───────┘
      Yes│    No
         ↓      ↓
       Stop   Continue

The second design introduces control, and that's the heart of loop engineering.

Measuring a loop

Success shouldn't be judged only by whether an answer eventually appears. Some useful measurements are shown here:

Other numbers worth tracking are:

• how long a task takes (latency)
• tokens consumed
• what each finished task costs
• how often calls get retried
• the share of tasks completed
• how often a human has to step in

Together, these show whether an agent is genuinely getting better.

The step-count trade-off

Extra steps let an agent tackle harder problems. They also bring higher cost, longer waits, more chances for mistakes, more tool failures and less predictable behaviour. So the aim isn't to keep the agent running for as many steps as possible. The aim is to complete the task in the smallest number of steps that still works reliably.

What a dependable loop needs

Loop engineering means designing and controlling the repeating execution cycle of an AI agent. The basic pattern runs as follows:

It repeats until the task is done or the system decides to halt. A dependable agent needs these ingredients:

• well-defined actions
• iteration that someone controls
• explicit stopping conditions
• handling for errors
• caps on retries
• managed state
• limits on spend
• ongoing evaluation

Autonomy doesn't mean unlimited execution. A good agent knows what to do next and also when to stop.

A strong model and a clever loop can still go wrong if the agent is fed the wrong information. That leads to the next question: what should an agent actually receive at each step? The answer belongs to context engineering, which is about giving agents the right information at the right time.