The Agent Loop: ReAct, Planning, and Multi-Step Execution Patterns

Updated 2026-09-06 · guide · agents, how-to, architecture

Every agent is, at its core, a loop: think, act, observe, repeat — until the job is done or the loop is stopped. The difference between an agent that feels like magic and one that feels like a slow, expensive autopilot is almost never the model. It's the loop: how the agent plans, what it does when a tool returns something unexpected, when it reflects and changes course, and — critically — how and when it stops. This guide breaks down the single-agent loop into its parts, shows the ReAct pattern that underlies most working agents, and gives you the loop patterns that cut thrash, cost, and wrong answers.

If you've watched an agent work, you've seen the loop in action: it reads a question, makes a plan, calls a tool, looks at the result, decides the next step, calls another tool... and eventually stops and answers. That cycle is the entire engine. The model is the engine's fuel, but the loop is its chassis. And like a chassis, it can be built badly — too many cycles, no stopping condition, no reflection — or well. This guide is about building it well.

The loop in one picture

Every single-agent system runs the same fundamental cycle. Naming the parts makes every other decision in this guide concrete:

1. Think (reason). The agent interprets the current state and decides what to do next. This is where it makes a plan, forms a hypothesis, or picks the next action.
2. Act (call). The agent takes an action — calling a tool, querying a source, or (at the end) producing the final answer. This is the only part that touches the outside world.
3. Observe (read). The agent receives the result of its action: the tool output, the error, the data. This becomes the new state for the next Think step.

Repeat. The cycle is deceptively simple, and the entire craft of agent engineering is in the three details: how it thinks, when it acts, and how it decides the loop is done. Get those right and the agent is reliable; get them wrong and no amount of model quality saves you.

The ReAct pattern: interleaving reason and action

The most influential framing of this loop is ReAct — Reasoning + Acting. The core insight: instead of reasoning to a full plan and then executing it blindly, the agent alternates reasoning and acting, one step at a time, so each observation corrects the next thought.

Thought: I need the current user's account status.
Action: call tool get_account(user_id=42)
Observation: "account=enterprise, status=active"
Thought: Enterprise plan — check quota before proceeding.
Action: call tool check_quota(account=enterprise)
Observation: "quota=8120/10000 tokens remaining"
Thought: Under quota. Proceed with the task.
...

The power of interleaving is that the agent doesn't commit to a plan it can't validate. Each tool call is a small experiment, and each observation updates the reasoning. This is what makes agents robust to real-world messiness — the plan adapts as reality is revealed. It's also exactly why the plan-then-act technique in prompt engineering works so well with agents: a good system prompt gives the agent the discipline to alternate thought and action rather than charging ahead.

Planning: short plans beat long ones

Inside the loop, the agent's planning behavior is a major quality lever. Two patterns dominate, and they sit at different ends of the spectrum:

• Plan-then-execute. The agent restates the goal, sketches the full plan upfront, then executes. Good for tasks with a clear structure and few surprises. The risk: it commits to a plan that reality may contradict — which is why the best versions re-plan when an observation doesn't match the expectation.
• Incremental (ReAct-style). The agent plans one step at a time, deciding the next action based on the latest observation. More robust to surprises, slightly more overhead per step. This is the default for complex, unpredictable tasks.

The practical rule: plan more when the task is well-understood, plan less (act-incrementally) when the path is uncertain. Most real agent work is a mix — a rough plan upfront, then incremental execution with re-planning checkpoints. The failure mode to avoid is the opposite pair: either no plan at all (thrashing, aimless tool calls) or a rigid plan that refuses to adapt (wasted calls on a stale strategy).

Reflection: the step most loops skip

Here's the part that separates reliable agents from lucky ones: reflection — a checkpoint where the agent steps back and evaluates whether what it's doing is actually working. A loop without reflection is just momentum; a loop with reflection is a feedback system.

Where reflection slots in:

• After a failed or surprising observation. When a tool returns an error or an unexpected result, the agent should pause and re-interpret before firing the next call. "This call failed because the API is down" and "this call failed because my arguments were wrong" demand different next actions — reflection is how the agent tells them apart.
• At mid-task checkpoints. For longer tasks, a deliberate "am I still on track toward the original goal?" checkpoint prevents the classic agent failure of confidently completing the wrong thing. This is the single-agent version of the delegation sanity-check that multi-agent systems get from explicit orchestrator gates.
• Before declaring done. A final reflection — "did I actually satisfy the request?" — catches the silent no-op: the run that "succeeded" without producing the needed output. It's the cheapest quality gate in the whole loop.

Reflection costs a few extra reasoning tokens per checkpoint, and it's almost always worth it. The loop that reflects catches its own drift; the loop that doesn't just keeps going.

Tool integration: the act step done right

The Act step is where the agent touches reality, and its quality determines everything downstream. Three rules make the act step reliable:

1. Tool calls should be explicit and well-formed. The agent should name the tool and the exact arguments — no ambiguity for the runtime to guess at. This is the contract that the skill and tool layer defines, and it's what makes the loop's actions auditable.
2. The agent should handle failure gracefully. Every tool call can fail: timeout, auth error, schema change. The loop needs a defined response to each — retry with backoff, try an alternative, or escalate. An agent that treats every error as "task impossible" is as broken as one that blindly retries forever.
3. Observations should be bounded. A tool returning a 50,000-token blob is a context-management problem waiting to happen. The act step should trim, summarize, or structure observations before they feed the next Think — this is exactly the discipline the context engineering guide describes, applied at the loop level.

The act step is also where MCP comes in: in 2026, most agents call tools over MCP servers. The loop doesn't care how the tool is wired — the same think-act-observe cycle runs whether the tool is a local function or a remote MCP server. What the wiring changes is reliability, and that's a tooling concern, not a loop concern.

Stopping conditions: how the loop ends

The least glamorous and most important part of the loop is knowing when to stop. Every agent needs three kinds of stopping conditions, and a loop without them is a cost bomb:

1. Goal-complete detection. The agent recognizes the output satisfies the request and stops, producing the final answer. This is the happy path, and it needs to be explicit — "when X is true, you're done."
2. Max-iteration and budget caps. A hard limit on loop iterations or token spend. The loop will occasionally run away (a repeated failing tool call, a goal that's impossible), and the cap is what turns an hour of burning tokens into a five-minute failure. This is the same budget discipline as the token-cost playbook, applied as a loop-level guardrail.
3. Escalation conditions. When the agent is stuck, out of ideas, or hitting a permission boundary, it should stop and hand off — to a human or a more capable path. An agent that silently declares "done" with a half-result is worse than one that admits it's stuck.

Stopping conditions are also where safety meets the loop: the agent safety guardrails guide's per-run budgets and loop detection are literally stopping conditions enforced from outside the loop. The loop defines its own stop rules; the guardrails enforce the ones the loop might miss.

Common loop anti-patterns

Bottom line

• No plan, all momentum. The agent fires tool calls based on vibes, reacting to each observation with no sense of the goal. Result: thrash, wasted tokens, and often the wrong answer confidently delivered. Make the goal and a rough plan explicit at the start.
• Rigid plan, no adaptation. The opposite failure: the agent commits to a plan and executes it even as observations contradict it. Let the plan be a hypothesis, not a contract — re-plan when reality disagrees.
• Blind retry loops. Same failing call, same arguments, forever. The loop needs a defined failure response — retry with change, or escalate. Blind retries are how token bills explode.
• No stopping condition. No max iterations, no budget cap, no escalation path. This is the run-away-agent scenario — the one that ends in a support ticket and a large invoice.
• Skipping reflection. The agent barrels toward "done" without ever checking whether it's solving the actual problem. A mid-task checkpoint and a final self-check are the cheapest quality insurance in the system.

The agent loop — think, act, observe, repeat — is the whole engine of agent reliability: interleave reasoning with action, plan enough but stay adaptive, reflect at checkpoints, handle tool failures deliberately, and define how the loop stops. Get the loop right and the model's quality shows up in the output; get it wrong and no model saves you. Your single next action: look at your agent's stopping conditions today — if it has no max-iteration or budget cap, add one before you ship anything else.

FAQ