Catalog / Single agent

ReAct loop

One agent alternates between reasoning and acting. Each tool result enters its context and shapes the next thought, until it can answer.

Reference task used across all patterns: "My order arrived damaged. Can I get a refund?"

Topology

ActorLead agentTool

Run

09 steps

Ready to run

Play runs the whole scenario. Step advances one event at a time so you can read what happens.

Metrics

Wall-clock time0.0 s
Tokens processed0
Estimated cost$0.000
Tool calls
0
Illustrative values. They show proportions between patterns, not benchmarks.

All steps

Normal run

  1. Request arrives. One agent owns the task and holds the whole conversation in a single context.
  2. Thought. The agent reasons about what it is missing. It cannot judge a refund without the order record, so that comes first.
  3. Act: look up the order. The thought ends in one concrete tool call. The loop never plans further ahead than the next action.
  4. Observe. The result is appended to the agent's context as an observation. Order 4417 was delivered on 12 Sep.
  5. Thought. With the order known, the next gap is evidence. The customer says it arrived damaged; the carrier can confirm that.
  6. Act: ask the carrier. A second call, chosen only now. Had the order been too old, the agent would have stopped instead.
  7. Observe. The carrier confirms the damage. The context now holds the request, two thoughts and two observations.
  8. Final thought. Delivered 12 Sep, inside the 30-day window, damage confirmed. Nothing is missing, so the loop ends.
  9. Respond. Refund approved. Two tool calls, in sequence, so wall-clock time is the sum of every step.

Outcome: correct answer. The agent chose each step from what it had just learned. That is cheap and flexible, at the price of running everything in sequence in one growing context.

Failure mode

  1. Request arrives. Identical start to the normal run.
  2. Look up the order. Thought and action, as before.
  3. Observe. Order 4417, delivered 12 Sep. Nothing has gone wrong yet.
  4. Ask the carrier. The agent requests the damage report.
  5. Timeout. The carrier's API is down. After three seconds the call returns an error instead of a report.
  6. Immediate retry. The agent reads the error as a glitch and repeats the identical call at once, with no delay and no change.
  7. Timeout again. Same call, same result. Every failed attempt is another observation, so the context keeps growing.
  8. Retry storm. Three more identical calls follow, each re-sending the whole history. Nothing in the loop limits or varies them.
  9. Budget exhausted. The run stops at its token budget with no answer. The order was found and the policy was clear; one unavailable tool took the task down.

Failure: retry storm. A loop repeats whatever it is not told to stop. Mitigation: cap retries per tool, back off between attempts, and give the agent a fallback such as escalating to a human.

Execution trace

Model workingSending a message

Reference

Problem
The steps needed are not known up front; each one depends on what the previous tool call returned.
Analogy
A detective follows one lead at a time: think, check a fact, think again with what was learned.
Use when
The task needs a handful of tool calls whose order depends on intermediate results, and one context can hold the whole trace.
Avoid when
The steps are fixed and known in advance; a pipeline is cheaper and easier to test. Long runs grow the context with every observation.
Typical failure
Retry storms and loops: the agent repeats a failing action because nothing in its loop limits or varies it.
Also known as
ReAct (Yao et al.)Agent loop (OpenAI Agents SDK)create_react_agent (LangGraph)Agents (Anthropic, related)
Related patterns
Sources

Space play or pause   → next step   ← previous step  R reset   F failure mode