What is an agentic loop: definition and example

An agentic loop is the cycle an AI agent repeats — perceive state, act, observe the result, and decide whether to continue or stop — until it meets a goal or reaches a stopping condition. If you’ve seen it written as “agentic loop,” that’s the same thing: the term travels in English, the concept is identical.

Most people who use ChatGPT believe that an agent responds once and that’s it. It doesn’t. An agent loops, and each iteration corrects the previous one. That difference is what separates someone who writes a prompt from someone who builds something that works on its own.

The idea: parking a car through corrections

Think about how you parallel-park in a tight spot. You don’t calculate the perfect angle and turn the wheel once. You check the mirror, turn a little, move forward, look again, correct. Each move depends on what you saw after the previous one. You stop when the car is between the lines.

An AI agent does the same thing with a task. It doesn’t solve the problem in one shot: it executes a small action, sees what happened, and decides the next step with that new information. The word “loop” isn’t decorative. The agent goes back to the start of the cycle again and again, with more context on each iteration, until the task is done.

A bare language model doesn’t do this. You ask it, it answers, that’s it. The loop is exactly what you wrap around it to turn a model that only talks into an agent that acts.

The parts of the loop

An agentic loop has four parts, and all of them are needed to keep it turning. Remove one and it stops being a loop.

Perceiving state. Before deciding anything, the agent reads where things stand. On the first iteration that’s the task and its starting conditions; on subsequent ones, everything it has observed so far. That snapshot is the raw material the agent uses to reason about the next step.

The action. On each iteration, the agent picks an action and executes it. Almost always that means calling a tool: reading a file, running a command, querying an API, or searching a database. This is where tool calling comes in, and it’s worth understanding clearly: the model doesn’t execute anything itself — it says “run this command with these arguments,” and your code is what actually runs it. Many of those tools connect to the agent through MCP, the standard protocol for giving an agent access to external tools.

The observation. After acting, the agent reads the result. The command returned an error, or the test failed on line 42. That observation feeds back into the model’s context, and it’s what makes the next decision different from the previous one.

The decision to continue or stop. With the fresh observation in hand, the agent decides: is the goal already met, or does it need another iteration? The objective (“make the tests pass” or “find the customer’s order and refund it”) is the criterion against which it measures whether it’s done. Without a clear objective, the loop doesn’t know when to stop — that’s worth a longer discussion, and I’ll come back to it at the end. If the goal isn’t met, it goes back to picking an action and the cycle continues. If it is, it stops and delivers the result.

Loop ≠ chain: how it differs from prompt chaining

The most common confusion is mixing up the agentic loop with prompt chaining, and they are different things. A chain of prompts is linear: step 1 feeds step 2, which feeds step 3, and when you reach the end, you’re done. You decide the steps ahead of time. The chain doesn’t go back or repeat; it travels a fixed path and comes out the other side.

A loop has no fixed path. It repeats the same step (perceive, act, observe, decide) as many times as needed, and it’s the agent itself that decides on each iteration whether to continue or stop. A three-step chain always does three steps. A loop might run two iterations or fifteen, depending on what it observes.

The quick way to tell them apart: in a chain, you design the sequence; in a loop, the agent figures it out as it goes. If you want to see real prompt chains built in practice, with and without a library, there are prompt chaining examples that walk through it step by step.

An example: the agent that fixes a failing test

The clearest case for seeing the loop in action is an agent that fixes a broken test. The goal is simple: make the test pass. Here are the iterations:

1. Acts: runs the test.
2. Observes: the test fails, and the output says TypeError: cannot read property 'id' of undefined on line 12.
3. Decides: the goal isn’t met. The agent reads the file and understands that a null check is missing.
4. Acts: edits the code to add that check.
5. Observes: runs the test again. It passes.
6. Decides: goal met. Stops.

The TypeScript skeleton, without the details of each tool, looks like this:

// El bucle agéntico reducido a su esqueleto:
// actuar, observar, y decidir si repetir o parar.
async function agentLoop(objetivo: string) {
  let contexto = objetivo;
  const MAX_VUELTAS = 20; // ajústalo a tu caso
  for (let vuelta = 0; vuelta < MAX_VUELTAS; vuelta++) {
    const accion = await modelo.decidir(contexto);   // el modelo elige la acción
    if (accion.tipo === "terminar") return accion.resultado;

    const observacion = await ejecutar(accion);       // tu código ejecuta la herramienta
    contexto += `\n${observacion}`;                    // el resultado vuelve al contexto
  }
  throw new Error("Se acabaron las vueltas sin cumplir el objetivo"); // parada dura
}

Notice two things. The model never runs the test itself; it only says what to do, and your code (ejecutar) actually runs it. And the loop has an emergency exit: MAX_VUELTAS. Without that limit, an agent that can’t fix the test would keep trying forever.

The stopping condition: the part almost everyone forgets

The stopping condition is what decides when the loop stops turning, and it’s the part I’ve most often seen missing in a first agent. A loop without a clear stopping condition is an infinite loop with a pretty name.

There are several ways to stop, and a serious agent combines more than one:

• Goal met. The reason you want to stop: the test passes or the order is refunded. This is the “good” stop, the one you’re aiming for.
• Iteration limit. A hard cap on iterations. If the agent hasn’t finished in, say, twenty iterations, something is wrong and it’s better to cut than to keep burning tokens.
• Budget or context exhausted. These are two distinct limits, and both call for a clean exit. The first is cost: each iteration consumes tokens and tokens cost money, so a spending cap cuts the loop before it runs away from you. The second is the context window: since each observation accumulates in the context, there comes a point where the request exceeds the model’s maximum and the API rejects it with context_length_exceeded. If you don’t watch for either, the loop doesn’t stop cleanly — it crashes.
• Loop detected. If the agent repeats exactly the same action with the same arguments several times, it’s stuck. Detecting this and stopping prevents it from spinning in circles without making progress.

In a real agent, the good stop is the one you want and the others are safety nets. But if you only implement the first one and the goal is never met, you don’t have an agent: you have a process that never ends. That specific case — why an agent keeps looping and how to force it to stop — is what I break down in how to prevent an agent from entering an infinite loop.

Common mistakes

Thinking the agent responds once

This is the mental model error, and it comes from only using the chat interface. You type, the model responds, and it seems like that’s it. But when that same model works inside an agent, the “response” you see is the end of a loop that may have run ten iterations underneath: it read files, executed commands, corrected its own mistakes, and tried again. If you design thinking of a single response, you aren’t designing an agent.

Building the loop and forgetting how to stop it

An agent without an explicit stopping condition works in the demo and blows up in production. I’ve seen it enough times to be suspicious by default of any agent that has only performed well on a toy case. In the demo the goal is met in two iterations and everything seems magical. The day the agent runs into a problem it can’t solve, it spins indefinitely, burns tokens, and returns nothing. The stopping condition is part of the loop design from line one, not a patch you add once something has already broken.

Defining an agentic loop is easy: perceive, act, observe, and decide whether to repeat. Designing one so it converges — doesn’t get stuck, knows when to stop, and doesn’t burn through the budget going in circles — is something else entirely. When you program with agents, the background work is no longer writing the code, but designing the cycle well: that’s loop engineering, the discipline that covers how you build a loop that reaches its destination. Adding the brakes that stop it when something goes wrong is its own technique: how to build them well is what guardrails in AI agents is about.

Frequently asked questions

Are an agentic loop and prompt chaining the same thing?

No. A chain of prompts is a linear sequence you design ahead of time that ends at the last step. An agentic loop repeats the same cycle as many times as needed, and it’s the agent that decides on each iteration whether to continue or stop. You can use a chain inside a single iteration of the loop, but they are not the same mechanism.

Is a chatbot an agentic loop?

A regular chatbot is not. You write to it, it generates a response from what’s in its context and stops until your next message: it doesn’t execute actions or observe results on its own. It becomes an agentic loop when you give it tools and let it act, observe the result, and decide again without you intervening at each step. What makes it an agent is the loop you put around it, not the model itself.

What makes an agentic loop stop?

It stops for one of several reasons. The good one is that the goal is met: the agent checks that it achieved what it was after and delivers the result. The others are safety nets for when that doesn’t happen: an iteration limit or detecting that the agent is repeating the same action without making progress. A well-built agentic loop always has at least one of these emergency stops, because relying solely on the goal being met is the fastest way to end up with an agent spinning forever.

Are an agentic loop and a multi-agent system the same thing?

No, they are two different dimensions. An agentic loop is how an agent works internally: it perceives, acts, observes, and decides whether to repeat. A multi-agent system is about how many agents there are and how they divide the work — for example, an orchestrator that distributes tasks to several workers. And each of those agents has its own loop running inside. You can have a single agent with a very well-designed loop, or ten coordinated agents each running their own. Multi-agent answers “how many and how they coordinate”; the loop answers “how each one reasons and acts.”