Giving an AI agent access to tools raises an engineering question: what should it do with the result?
A tool can return useful evidence, an empty response, or an error. Each outcome may call for a different next step.
That is where ReAct becomes useful.
Reasoning, actions, and feedback
ReAct combines Reasoning and Acting. The original approach interleaves reasoning with actions and observations from the environment. New evidence can change the next action.
- Reason about the next step
- Act through a tool
- Observe the result
- Update the plan
- Continue, finish, or escalate
In an agentic system, this means the sequence of tool calls can develop as the task unfolds. A single tool call, by itself, does not establish a ReAct loop.
The original ReAct research explores this interaction between reasoning and feedback from external environments.
A small application you can explore
My AgenticAI_ReACT application on GitHub demonstrates this loop in a Python terminal chat, using LangGraph and Qwen3 8B through Ollama.
The agent has two simple tools that return predefined error descriptions: code 45 means a request timeout, and code 63 means the service is temporarily unavailable for maintenance. You can try a prompt such as “What does code 45 mean?”
LangGraph routes any model-requested tool calls to a tool-execution node, then sends the results back to the model. When the model responds without another tool call, the graph finishes that turn. An in-memory checkpointer keeps conversation state within the running session.
This is a focused demonstration of tool selection and feedback using fixed lookup responses. The production investigation below illustrates how the same interaction pattern could be extended to real operational data.
Explore the application on GitHub
Imagine a production investigation
A user asks an agent: “Why is the payment service returning errors?”
In this hypothetical example, the agent has read-only access to logs, metrics, and deployment history.
- Check logs. The tool returns repeated connection timeouts.
- Inspect metrics. The failures began around the time of a recent deployment.
- Compare configuration. A connection-limit setting changed in that deployment.
- Test the hypothesis. Check connection-pool saturation and whether unaffected instances use the previous setting.
The timing gives the agent a lead. It still needs evidence before attributing the failure to that configuration change.
Each observation should help the agent choose a more useful next action.
If the evidence supports the hypothesis, the agent can present a recommendation with links to the logs and metrics. If the evidence is inconclusive, it can report what remains uncertain.
The tradeoff: flexibility and variable execution
This approach gives the system room to adapt. It also makes execution harder to predict.
The agent might repeat an unsuccessful query, follow a weak hypothesis, or keep gathering information after it has enough to answer. Extra iterations add latency and cost.
For this investigation, I would define the boundaries in application code:
- A step and time budget to cap the investigation.
- Bounded retries for tool failures and repeated empty results.
- Read-only permissions for diagnosis, with human approval enforced before any production change.
- Execution records for tool inputs, outputs, errors, and the evidence behind the recommendation.
- Explicit stopping conditions for a supported answer, insufficient evidence, or an exhausted budget.
These are engineering choices around the loop. ReAct does not supply them automatically.
Decide where adaptation is useful
I would use a ReAct-style loop when the next useful step depends on information the system has not retrieved yet. For a fixed sequence with known branches, an explicit workflow may be easier to test and operate.
This connects to the question behind choosing an agent framework: how much workflow control should the model have?
Give the agent room to respond to evidence, and make the limits of that freedom part of the architecture.
Keep reading: Explore how retrieval quality shapes the evidence an agent receives in RAG, or how a separate Judge can review an AI answer in LLM-as-a-Judge.