A loop is the smallest repeating structure that lets a system make progress on a goal it cannot finish in one pass. The loop reads where it is, decides what to do next, acts, observes the result, and repeats until something tells it to stop.

In ordinary computing, loops are everywhere — for, while, do-while. In agent work, loops are the same idea, but the "decides what to do next" step is handled by a model instead of by code. That small change is what turns a script into an agent.

This piece is the beginner-level introduction. It assumes no prior agent knowledge.

The shape of a loop

A useful agent loop has the same six stages, regardless of what kind of work it is doing:

1. Intake. What does the agent know about the goal? 2. Context. What does the agent have access to? 3. Inference. What should the agent do next? 4. Action. Do it. 5. Persistence. Record what happened. 6. Termination. Should the loop run again?

The six stages do not always appear as separate code blocks. They often collapse into a single prompt. But they are usually present in some form. If a system feels confusing, it is often because one of these stages is missing, overloaded, or happening in the wrong order.

The piece on What Is an Agent Loop? treats each stage in detail.

Why loops matter in agent work

Without a loop, a model call answers once and ends. With a loop, the same model can keep making progress — one tool call at a time, one observation at a time — until a goal is met.

That difference is what makes agents useful for research, file work, automation, and any task where the answer depends on what the agent has already seen.

The loop also decides when the agent stops. A model without a loop has no notion of stopping — it just produces one response. A model inside a loop has to keep deciding whether to continue or exit. That decision is where most agent failures come from.

Three kinds of agent loops

Triadive distinguishes three kinds of loops that show up in agent work. Each one makes a different trade-off between responsiveness and predictability.

  • Multi-turn loops. The loop runs inside a conversation. The user is the trigger and the terminator. The conversation context is the memory.
  • Cron-driven loops. The loop runs on a schedule. The trigger is the schedule tick. Termination is built into the schedule. The piece on Cron Jobs, Heartbeats, and Scheduled Work treats this in detail.
  • Sub-agent loops. A parent loop delegates part of the work to a child loop. The child returns a result. The parent continues. The piece on Sessions, Sub-Agents, and Child Sessions treats this pattern.

Each kind of loop has the same six stages. What changes is where the trigger comes from and where the state lives.

When a loop is the wrong shape

A loop is not always the right shape. Some work is better expressed as a graph — explicit nodes and typed edges — and some is better expressed as a single pass with no iteration at all.

The signal that a loop is the wrong shape:

  • More than one terminal state. The work has multiple distinct outcomes that need to be distinguishable in audit logs.
  • Branching that exceeds three levels. The decision tree inside the loop is too deep to read comfortably.
  • State that survives across iterations. The work has durable state that does not fit in the loop's local context.

The piece on Loops vs Graphs walks through the threshold in detail. The short version: most agent work starts as a loop. As the work scales, some of it becomes a graph. The graph is not a replacement for the loop; it is a structure around the loop.

Common questions about loops

Does every agent need a loop?

Not necessarily. Simple tasks can be handled in one pass with no loop at all. The question is whether the task requires the agent to observe the result of one action before deciding what to do next. If yes, a loop helps. If no, a loop adds cost without buying clarity.

What is the difference between a loop and recursion?

A loop is a cycle that ends with a termination check. Recursion is a function that calls itself. In agent work, the distinction matters: a loop terminates when a condition is met; a sub-agent that calls itself is recursion, which can fail to terminate.

Why not just ask the model once?

Because many tasks require observation and correction after the first action. A loop lets the agent learn from results and continue intelligently. Single-pass work is fine when the answer is known in advance; looped work is needed when the answer depends on what the agent discovers along the way.

Takeaway

A loop is the smallest repeating structure that lets an agent make progress on a goal it cannot finish in one pass. The loop decides when the agent stops, what the agent remembers, and how the agent recovers from failure. The rest of this manual treats each stage of the loop as its own design problem. Read the next piece in this sequence to go deeper.