Deconstructing ReAct: A Hands-On Guide to Building AI Agents from Scratch

Large language models can answer questions, but they can't check real-time weather, book hotels, or search the web. This capability gap is exactly the core problem AI Agents are designed to solve. In a hands-on video posted on Bilibili, an overseas blogger deconstructed the logic of building an Agent from scratch using the ReAct pattern, and used a weather query case to fully demonstrate the evolution from a "bare LLM" to a "tool-augmented Agent."

What Is the ReAct Pattern

ReAct stands for Reason and Act. According to the blogger's explanation in the video, this is the most core concept in building AI Agents — the LLM handles reasoning about which API to call or what decision to make, the developer executes those decisions, and the results are fed back to the LLM for the next round of reasoning. This loop repeats until the task is complete.

The official LangChain documentation defines it more concisely: "An Agent is just a model calling tools in a loop." You send a request to the model, the model has access to multiple tools and autonomously decides which to call, the developer executes the tool call, and the result is fed back to the model — this cycle continues until a satisfactory result is obtained. The model is the brain, the tools are the hands and feet, and the developer is the bridge connecting the two.

The academic origins of ReAct: The ReAct pattern was first proposed by Shunyu Yao et al. in a 2022 paper published on arXiv titled《ReAct: Synergizing Reasoning and Acting in Language Models》. The paper pointed out that traditional LLMs only perform chain-of-thought reasoning, which is prone to factual hallucination; while acting alone lacks planning capability. ReAct's core innovation is to let the model alternately generate "Thought" and "Action," and receive "Observation" as new context after each action, thereby binding the reasoning trajectory to the real feedback from external tools. This paradigm has been widely absorbed by subsequent AutoGPT, LangChain Agent, and the Function Calling capabilities of various LLMs, and can be regarded as one of the foundational designs of modern AI Agents.

The relationship between Function Calling and ReAct: After OpenAI introduced Function Calling in 2023, LLMs were able to output in structured JSON "which function to call and what parameters to pass," essentially standardizing the "Action" step in ReAct. The tools parameter in the article is the manifestation of this mechanism at the API level.

From Bare LLM to Tool Augmentation: A Weather Query Experiment

Without Tools: The LLM's "Helplessness"

The demonstration in the video starts from the most basic case. The blogger asks the GPT model: "What's the weather like in Hyderabad right now? Should I bring an umbrella?" Without any tools, the LLM gives a typical response — "I can't access real-time weather data, please check a current weather service." This clearly exposes the limitations of pure API calls: the model can only rely on knowledge from its training data and is completely helpless with real-time information.

With Tools Added: The Agent Starts "Doing It Itself"

The blogger then defines a Python function that fetches real-time weather data via the Open Weather API. The key step is: when this function is passed to the LLM as the tools parameter, it transforms from an ordinary function into a "tool" the Agent can call.

After asking the same question again, the LLM's behavior changes fundamentally. It no longer says "I can't do that," but autonomously decides to call the get_current_weather tool, automatically extracts the city parameter as "Hyderabad," executes the tool to fetch data, and finally summarizes the raw data into a human-readable answer: "Hyderabad is currently overcast, about 25.8 degrees, with high humidity and light winds. It's not raining right now, but considering the overcast skies and high humidity..."

The blogger then changes the city to London, and the Agent similarly completes the entire process on its own — recognizing the city change, calling the tool, and returning the result. As the blogger emphasizes in the video: "I didn't do anything, the Agent is doing everything."

Why tool schemas matter: When you hand a Python function to an LLM, what the model sees is not the function body, but the function's name, parameter descriptions, and docstring. This "instruction manual" determines whether the LLM can select it in the right scenario and fill in the parameters correctly. For example, if the docstring of get_current_weather(city: str) states "fetch the real-time weather for the specified city," the model can map "what's the weather like in Hyderabad" to city="Hyderabad". Therefore, writing good tool descriptions, avoiding overlapping functionality, and naming parameters semantically are key engineering details for whether an Agent can work stably — and also the most common pitfalls in actual development.

The Essence of Tools

It's worth noting that the blogger specifically points out: "A tool is essentially just an ordinary Python function, nothing special." It can call APIs, perform calculations, operate databases — anything you can implement in Python can be wrapped as a tool and handed to the Agent to call.

The Internal Mechanics of the ReAct Loop

The blogger uses a flowchart to deconstruct the complete operating logic of the ReAct loop.

When a user sends a prompt, the LLM first judges: can this question be answered directly? If so, it outputs the result directly and the process ends. If not, the LLM reviews what tools it has available and then decides which one to call.

Taking the weather tool as an example: the Agent decides to call the tool, the developer executes the function to fetch Hyderabad's weather data, and the output is returned to the LLM. The LLM then verifies whether this output is sufficient to answer the user's original question. If it is, it summarizes and outputs the final answer; if not, it calls the tool again, produces new output, and verifies again — this "reason-act-observe" loop continues until the LLM determines the task is complete.

The context bloat problem of Observation: The results returned by each round of tool calls are appended to the conversation history as input for the next round of reasoning. When a tool returns large chunks of raw data (such as full-page web HTML or long JSON), the context expands rapidly, which both drives up token costs and can dilute key information, leading to misjudgments by the LLM. Common mitigation measures include: trimming and summarizing results inside the tool, keeping only the most recent several rounds of Observation, or introducing a separate "compression" step. These optimizations are not obvious in the single-round weather scenario demonstrated in the article, but they are almost mandatory configurations in real multi-round Agents such as Google search and database queries.

Multi-Tool Scenarios and State Management

In real-world scenarios, an Agent usually needs multiple tools working together. The blogger lists four typical tools in the video: weather query, hotel booking, Google search, and image generation.

When the LLM faces multiple tools, it routes based on the nature of the user's question: search-type questions go to the Google search tool, image needs go to the image generation tool, and booking needs go to the hotel booking tool. The call results of each tool are returned to the LLM.

Here a key concept is introduced — State. When an Agent calls multiple APIs simultaneously, it needs to track the state and output of each call, and only after synthesizing all results can it generate the final integrated answer. The blogger emphasizes: the LLM plays the role of the "brain" here — deciding which tool to call, how to integrate the multiple outputs, and finally generating a unified answer.

A Pitfall Developers Must Watch Out For: Infinite Loops

The ReAct loop is not risk-free. The blogger specifically warns in the video: when the LLM repeatedly calls the same tool but never gets a satisfactory result, it may fall into an infinite loop and may even never exit.

The countermeasure is to set a call limit. Developers need to preset the maximum number of calls for the same tool — say 5 or 10. The blogger's reasoning is very practical: "If calling the same tool 10 times doesn't produce output, the 11th time won't be any different."

Why Build by Hand Before Reaching for Frameworks

At the end of the video, the blogger clarifies his teaching philosophy: "I don't want to teach Agents directly in the LangChain framework. I want you to first understand what's happening internally, step by step, and then adapt to the framework."

This approach is worth learning from. Frameworks like LangChain can indeed greatly simplify Agent development, but if developers don't understand the underlying logic of the ReAct loop — how the LLM makes decisions, how tools are executed, how state is managed, how the loop terminates — they will have no way to troubleshoot when problems arise with the framework. Starting from building a weather Agent by hand, gradually understanding the role of each step including prompt, tools, tool call, observation, and state, and then migrating to a framework — that is the path to truly mastering Agent development capability.

The essence of the ReAct pattern can be summarized in one sentence: let the LLM do what it's best at (reasoning and decision-making), let code do what the LLM can't do (execution and action), and let the two collaborate in a loop until the task is complete.

Hand-built vs. framework trade-offs: Implementing the ReAct loop from scratch requires only a few dozen lines of code — maintain a message list, call the LLM in a loop, execute tool_calls locally when encountered and splice the results back into the messages, until the model returns plain text. Frameworks like LangChain, LlamaIndex, and AutoGen provide tool registration, memory persistence, multi-Agent orchestration, and observability on top of this, at the cost of more abstraction layers and harder-to-trace stacks when errors occur. The industry's common experience is: first run the minimal closed loop with bare code to understand what the data looks like at each step, then decide whether to introduce a framework based on project complexity; for scenarios requiring human-machine collaboration, parallel multi-tool execution, or production-grade monitoring, the benefits of a framework will clearly outweigh its learning cost.

One-line Summary

Using a weather query case to deconstruct the ReAct pattern, clarifying the complete mechanism of LLM decision-making, tool execution, and loop termination.

Paragraph Summary

The article uses an overseas blogger's hands-on video as a thread to systematically deconstruct the core pattern of AI Agents, ReAct (Reason and Act). The essence of ReAct is: the LLM is responsible for judging whether tools need to be called and which tool to call, the developer is responsible for executing the tools and returning the results to the model, and this cycles until the task is complete. Through a weather query experiment, the article contrasts the difference between a "bare LLM" and a "tool-augmented Agent" — the former can only say "I can't check that," while the latter can autonomously extract city parameters, call APIs, and summarize a human-readable answer. The article also explains multi-tool routing, state management, infinite loop risks, and setting call limits, and emphasizes the learning path of first understanding the underlying mechanism by building by hand and then migrating to frameworks like LangChain.