What Is an Agent Loop? A Robot, a Sandwich, and the Art of Trying Again

Imagine a little robot named Pip.

You say, “Please make me a jam sandwich.”

Pip looks at the table. There is bread. There is jam. There is a spoon wearing a suspicious amount of peanut butter.

Does Pip announce, “Sandwich complete!”?

No. That would be a speech, not a sandwich.

Pip needs to look, choose a small step, do it, and check what happened. Then Pip can decide what to do next.

That repeating pattern is an agent loop.

The whole idea, in four little words

Look. Choose. Act. Check.

• Look: What is happening right now?
• Choose: What is one useful thing to do next?
• Act: Do that thing.
• Check: What actually happened? Are we finished?

If the job is not finished, go around again—with the new information.

A loop just means something repeats. An agent is a system that can take steps toward a goal, using the tools and permissions it has been given.

Put them together: an agent loop lets a helper act, see the result, and decide what comes next.

Back to the very serious sandwich mission

Pip's first small step is to open the jam jar.

Act: Turn the lid.

Check: The lid did not move.

Here is the interesting bit. Pip should not pretend the jar opened just because opening it was the plan.

And Pip should not keep turning forever until the sun becomes a raisin.

Pip could try a permitted alternative, or say, “Could you help me with this lid?” Asking for help is a useful outcome—not a robot-sized failure.

Once the jar is open, Pip can spread the jam, put the bread together, and check the result against your request.

Two slices? Jam inside? On a plate? Great.

A jar balanced on a loaf? Creative. Not a sandwich.

Where does the AI part fit?

Our kitchen story is pretend. A software agent's tools might read a file, search a page, edit a document, or run a test instead of handling bread.

In an AI agent, a language model can help choose the next step. The surrounding software runs permitted tool calls and returns their results. The model then gets another turn with that information.

Think of three different jobs:

A model suggesting an action is not the same as that action happening. And an action happening is not automatically the same as the goal being met.

“Saved the file” and “saved the correct file with the correct contents” are different claims. The check is where that difference matters.

A tiny adventure: the missing picture

Suppose you ask a software helper to fix a missing picture on a web page.

A useful loop could look like this:

1. Look: Read the page and identify the image path.
2. Choose: Check whether the referenced image exists.
3. Act: Inspect the relevant files.
4. Check: The page requests cat.png, but the file is named cat.jpg.
5. Go again: Update the reference, then check that the page loads the intended picture.
6. Stop: Report the change and the checks actually performed.

If the picture still does not appear, “I edited the page” is not enough. The result should guide the next step.

Notice what makes this a loop: the next action depends on what the previous action revealed. It is not merely doing the same thing repeatedly.

Does every lap make things better?

No. More activity does not automatically mean more progress.

Here is a made-up graph for Pip's sandwich mission. We give Pip one point for each completed milestone: jar open, jam spread, sandwich assembled, and the final request checked.

The flat bit matters. If nothing changes, the helper needs to notice—not celebrate how many times it has tried.

For grown-ups, that suggests useful questions: Did we learn anything? Did the state change? Are we repeating the same failed action? Is another attempt worth its cost?

For everyone else: if the door says PULL, pushing harder is not a strategy.

Give the helper a fence, not the whole planet

A sensible agent design needs more than a repeat button.

• A clear finish line. “Find three pictures of penguins” is easier to check than “make everything amazing.”
• Appropriate permissions. Being able to draft an email should not automatically mean being allowed to send it.
• A stopping budget. Put limits on attempts, time, or spending. A stuck task must not become an endless task.
• A way to ask. Missing information, missing access, or a consequential choice can call for a person.
• Honest checks. Use evidence suited to the goal. Do not turn “the tool returned” into “everything is correct.”

These are design principles, not a promise that every product implements them. A loop does not magically make a system safe or reliable.

In Pip's kitchen: make the sandwich, do not order a truck full of jam, and ask before using the grown-up appliances.

Is an agent loop the same as a script?

Not necessarily—but the boundary is not “scripts are silly, agents are smart.” Scripts can have loops, conditions, and excellent checks too.

The distinction worth watching is how the next action gets chosen. In a fixed workflow, the developer has laid out the routes in advance. In a model-driven agent loop, the model can choose among available actions based on the task and the latest observations. Real systems can mix both approaches.

For a predictable job, a small script may be exactly right. You do not need a philosophical robot to ring a bell at noon.

For a task with unknown obstacles, choosing the next step from fresh evidence can be useful. That flexibility also makes limits and verification important.

The fridge-magnet version

An agent loop is:

Try a useful step. See what happened. Use what you learned. Repeat only while it makes sense.

It is not magic. It is not a guarantee. It is not “keep going forever.”

It is a way to connect a goal, an action, and the real result—again and again, until the helper is finished or needs to stop.

Pip would explain it more simply:

“Look. Try. Check. And don't say sandwich until there's a sandwich.”