AI Agent Loops Explained: 9 Patterns Behind Every LLM Agent

Why AI agent loops matter

Every agent you've used (Claude Code, Cursor, AutoGPT, a customer-support bot, a nightly PR reviewer) is running the same underlying idea: an LLM sitting inside a loop, repeatedly deciding what to do next until a goal is reached or a limit is hit.

The "agent" part isn't a bigger or smarter model. It's the loop wrapped around it. The loop is what decides whether to call a tool, what to do with the result, when to stop, and what triggers the whole thing to start in the first place.

Once you can name the loop a system is running, agent behaviour stops feeling mysterious. It starts feeling like an architecture decision, the same kind you'd make between a queue worker and a cron job. This post walks through the loop types you'll see most often in production, what each one looks like as a diagram, and where each one actually earns its place.

The core loop: every agent's common ancestor

Before the variations, it helps to see the shape they all build on. Strip away the branding and almost every agent framework (LangGraph, the OpenAI Agents SDK, the Claude Agent SDK, smolagents) reduces to the same six lines: call the model, check if it asked for a tool, run the tool if so, feed the result back, repeat, stop when the model is done.

Everything below is a variation on where this loop starts, how long it runs, and what counts as "done."

---

1. The Tool-Calling Loop

The simplest pattern. An agent is handed one task, picks the tools it needs, runs them, and keeps going until there's nothing left to do.

Where it fits: single-session assistants and internal scripts. Think of a Slack bot that looks up an order status, or a CLI tool that refactors one file. No memory across runs, no scheduling. It starts when called and ends when the task is finished.

2. The ReAct Loop (Reason → Act → Observe)

ReAct is the tool-calling loop with the thinking made visible. Instead of jumping straight to a tool, the agent writes out why it's picking that action, then acts, then reasons again over what came back. The pattern was introduced in the ReAct: Synergizing Reasoning and Acting in Language Models paper, and that visible reasoning trace is what makes ReAct agents so debuggable. You can read the "thought" and see exactly where the logic went sideways.

Where it fits: open-ended tasks where the next step depends on what just happened. Research agents, debugging assistants, a support bot working through a multi-turn troubleshooting flow. The tight feedback loop makes ReAct adaptive, at the cost of one model call per step.

3. The Plan-and-Execute Loop

Planning and doing are split into two roles here. A planner (usually the stronger, more expensive model) writes out the full sequence of steps up front. An executor then works through that list, calling tools as it goes. When a step fails or returns something unexpected, control goes back to the planner to rewrite what's left, instead of the executor improvising step by step.

Where it fits: long, multi-step jobs with real dependencies between steps. Migrating a database, orchestrating a multi-stage customer journey, generating a structured report from five data sources. You trade a slower first move for a plan you can inspect, log, and approve before any tool with side effects runs.

4. The Reflection (Reflexion) Loop

A reflection loop adds a self-critique pass after the first draft. Rather than returning the initial answer, the agent (or a second "critic" instance) reviews its own output against the original goal, flags what's weak, and feeds that critique back in for another attempt.

Where it fits: quality-sensitive output where a second pass measurably helps. Code that needs to pass tests, copy that needs to match a brand voice, a SQL query that needs to actually run. Each revision costs an extra model call, so it's worth reserving for output you'd otherwise review by hand anyway.

5. The Heartbeat Loop

A heartbeat loop wakes the agent on a fixed cadence (every minute, every hour). Each beat starts a fresh, stateless session; you inject the relevant context (recent activity, pending items), the agent acts, and then it goes dormant until the next tick.

Where it fits: monitoring-style work where state lives outside the agent's context. Checking queue depth, watching for stale pull requests, polling an inbox. Each beat starts clean, so cost stays predictable and the context window never balloons. The trade-off is that the agent only knows what you explicitly load in at wake time.

6. The Cron (Scheduled) Loop

Same shape as the heartbeat, but triggered by calendar time rather than a fixed interval. "Every weekday at 9am." "The first of the month." It's the agent equivalent of a traditional cron job: same task, same time, every time, until someone changes the schedule.

Where it fits: predictable, recurring jobs that don't need real-time reaction. A daily aging-PR review, a weekly content-ideas digest, a monthly dependency audit. If the trigger is "what time is it," it's a cron loop, not a heartbeat.

7. The Hook (Event-Triggered) Loop

The trigger here isn't time, it's an event. A PR opens. A file changes. A webhook fires. A payment completes. The agent does nothing until that specific signal arrives, runs once for that event, and goes back to waiting.

Where it fits: anything reactive. Auto-reviewing a pull request the moment it's opened, triaging a support ticket the second it's filed, reconciling a record right after a Stripe webhook lands. Latency to first response is the whole point.

8. The Goal-Based Loop

The agent isn't told how many steps to take or when to wake up. You give it a verifiable end state, and it keeps working, turn after turn, until the condition is true (or a safety limit fires). A separate, smaller checker model usually grades "is this actually done," so the agent isn't grading its own homework.

Where it fits: long-horizon work with a clearly testable finish line. "All tests under test/auth pass and lint is clean." "The migration script runs against staging with zero errors." You need hard guardrails (max turns, a cost ceiling, a human checkpoint before anything irreversible) or an unclear goal turns into a runaway loop.

9. The Multi-Agent (Orchestrator–Worker) Loop

At a larger scale, one lead agent plans the work and hands pieces of it off to sub-agents running in parallel, each with its own focused context. The orchestrator collects their results, decides what's missing, and either dispatches more workers or assembles the final answer.

Where it fits: broad research or build tasks that split cleanly into independent threads. Researching several competitors at once, generating and validating output with separate "maker" and "checker" agents, running a large codebase migration across many modules in parallel. It's the most capable pattern here, and the most expensive. Anthropic's multi-agent research-system writeup reports multi-agent setups burning roughly 15x the tokens of a single agent for the same task, so it's worth reserving for jobs where parallelism genuinely pays for itself.

---

Choosing the right loop

The takeaway

These patterns aren't mutually exclusive. Most real systems combine two or three. A cron loop might wake an orchestrator, which fans work out to ReAct-style sub-agents, each running a short reflection pass before returning its result. The skill worth building isn't memorising the names. It's recognising which shape a problem actually needs, before reaching for the most autonomous (and most expensive) option by default.

If you're building anything agentic into a product right now, that's usually the highest-leverage design decision you'll make before writing a single prompt.

For more on how I think about shipping production software like this, see my engineering case studies or read more about my background.