Getting Started with Agent Loops: Turn, Goal, Time & Proactive

🔄 Agent Systems — 14 min read

Getting Started with Agent Loops

Under the hood, every AI agent is a loop. What makes one agent a toy and another a workhorse is how that loop is driven — by turns, by a goal, by the clock, or by the world changing around it. This guide walks through all four, with a flow diagram for each and one architecture that ties them together.

4 loop patterns

6 flow diagrams

1 unified architecture

Guardrails included

New to this? Read this first. An AI agent is a large language model (an LLM — the kind of AI behind ChatGPT or Claude) that has been given a loop and a set of tools — things it can actually do, like search the web, run code, or send an email. So instead of only chatting back, it can take real actions on its own, step by step, until a job is finished. This guide is about how that loop runs.

One note: the /goal, /loop and /schedule labels you'll see are real commands from AI coding tools like Claude Code — handy examples, not universal syntax.

If you strip an AI agent down to its core, there is no magic — just a loop. The model looks at what's going on, decides what to do, does it, checks the result, and goes around again — the same way a person works through a task: look → think → do → check → repeat. Everything interesting about agents comes from one question: what starts the loop, and what stops it? Answer that four different ways and you get the four loop patterns every agent builder should know.

The anatomy of an agent loop

Before the four flavours, here is the engine they all share — the classic reason → act → observe cycle (often called the ReAct loop, short for Reason + Act):

Diagram 1 · The core agent loop

Every agent runs this loop. The four patterns below differ only in what triggers step 1 and what step 4 checks.

1. Turn-based loops

The simplest and most common: the loop advances one turn at a time, and it is bounded. A turn is one full reason–act–observe pass. The loop stops when the task is done or when it hits a hard cap on the number of turns (max_iterations). This is what a chat agent or a ReAct agent does between your messages.

Diagram 2 · Turn-based loop

Bounded and predictable. The max_iterations guard is what stops a stuck agent from looping forever.

Use it when the work fits in one bounded session and a human (or a caller) is waiting for the result — chat assistants, one-shot tasks, tool-using Q&A. Always set a turn cap.

2. Goal-based loops /goal

Here the stop condition isn't a turn count — it's a goal. The agent keeps iterating and, each pass, checks its own progress against a clear definition of "done" (the success criterion). It only stops when the goal is met — or a budget of time or money runs out (each AI call costs a little, and it adds up). This is what powers "keep going until the tests pass" or "rewrite the summary until it scores high enough on a quality check."

Diagram 3 · Goal-based loop

The evaluate step is the whole trick — a weak success criterion means the loop never stops (or stops too early). Pair it with a budget cap.

Use it when quality matters more than speed and "done" is measurable — code that must pass tests, content that must meet a checklist of standards, a search that must find an answer. The evaluator — whatever decides "is the goal met yet?" — is your most important design choice.

3. Time-based loops /loop · /schedule

These loops aren't triggered by a person at all — they're triggered by the clock. Either on a fixed interval (/loop 5m — "every 5 minutes") or on a cron schedule (a calendar-style timetable — /schedule, e.g. "9am every weekday"). The agent wakes, does its work, then sleeps until the next tick.

Diagram 4 · Time-based loop

The loop lives across time, not within one session. Cadence is a cost/freshness trade-off — poll too often and you burn budget; too rarely and you miss things.

Use it when work should happen on a rhythm regardless of activity — a daily digest, a health check every few minutes, a nightly batch. Note the two flavours: /loop is a local, live interval; /schedule is a persistent cron that runs even when you're away.

4. Proactive loops

The most advanced pattern. Here the trigger isn't a person or a clock — it's the world changing. The agent continuously watches some signal (a to-do queue, a code repository, an inbox, a dashboard number) and decides for itself when something is worth acting on. It initiates. That autonomy is exactly what makes proactive loops powerful and what makes guardrails non-negotiable.

Diagram 5 · Proactive loop

The agent decides whether to act, not just how. Without a tight "worth acting on?" filter and a human-approval step, proactive agents get noisy or dangerous fast.

Use it when value comes from reacting quickly to change — sorting incoming alerts, watching code changes, spotting something unusual. In practice a proactive loop usually sits on top of a time-based one (it re-checks on a schedule) and kicks off goal-based tasks when it fires.

Choosing the right loop

Pattern	Triggered by	Stops when	Best for	Main risk
Turn-based	A message / caller	Done or turn cap hit	Chat, one-shot tasks	Stuck loop (cap it)
Goal-based	A goal being set	Goal met or budget out	Quality-critical work	Weak success criterion
Time-based	The clock	Cancelled / never	Rhythms, digests, checks	Wrong cadence / cost
Proactive	The world changing	Cancelled / never	Reacting to events	Noise & runaway actions

Putting it together: one agent, all four loops

Real systems don't pick one — they nest them (put one loop inside another). A proactive monitor runs on a time-based schedule; when it fires, it starts a goal-based task; and that task runs as a turn-based agent loop, all wrapped in guardrails (safety limits). Here is that architecture end to end:

Diagram 6 · Unified agent-loop architecture

Four loops, nested: a schedule or a monitor fires, the dispatcher starts a goal loop, the goal loop drives a turn-based agent loop — all inside a guardrail frame that caps spend and can require human sign-off.

The guardrails you can't skip

🛑 A hard stop

Every loop needs a ceiling — a maximum number of turns, a spending limit, or a time limit. A loop with no ceiling is a runaway bill (or a crash) waiting to happen.

🎯 A real stop condition

Goal loops live or die on the check that decides "done." If "done" isn't measurable, the loop either never ends or ends wrong. Define success before you start.

👁 Observability

Log every turn's reasoning, action, and result. You cannot debug — or trust — a loop you can't see inside.

✋ Human-in-the-loop

For any action that writes, sends, deletes, or spends, gate it behind approval — especially in time-based and proactive loops that run unattended.

Ready to build agents, not just chatbots?

Agent loops are the backbone of Agentic AI — one of the highest-demand skills in AI hiring. Follow the free Agentic AI roadmap to go from loops to production multi-agent systems.

Open the Agentic AI Roadmap →

Create your free account

Getting Started with Agent Loops