ReAct Pattern (Reasoning + Acting)

1. Concept Overview & Systemic Problem

Before the introduction of the ReAct concept (published by researchers from Princeton University and Google Research in 2022), there was a divide in the community regarding two approaches to LLM automation:

1. Chain-of-Thought (Thought-Only): The model writes long chains of reasoning but lacks access to the external world. As a result, the logic of reasoning appears convincing but is based on fabricated facts and outdated data.
2. Act-Only: The model calls APIs or executes bash commands without intermediate self-analysis. This leads to chaotic repetitions, blind parameter exploration, and an inability to solve even simple multi-step tasks.

The ReAct Pattern (Reasoning + Acting) unifies these two forces into a single iterative cycle: the model first verbalizes its thoughts and plans the next step, then executes the target action, analyzes the actual result from the environment (Observation), and only then makes the next decision.

2. Architectural Taxonomy & Mental Model

The classic step of the ReAct cycle consists of three sequential states:

• 1. Thought: The agent analyzes the current state of the task, formulates a hypothesis, and articulates a specific intention: “I need to check if the Redis service is running on port 6379 before running tests.” This stage critically reduces the likelihood of errors in tool arguments.
• 2. Action: The agent formulates a specific action with strict parameters: function name and valid JSON object (e.g., execute_bash(command="systemctl status redis")).
• 3. Observation: The external runtime intercepts the action, executes it on the server or database, and returns raw text output or an error code back to the agent's context.
• 4. Finish / Final Answer: When the agent sees in the last Observation that the goal has been achieved, it stops the cycle and formulates the final response to the user.

3. Technical Pipeline & Internal Mechanics

The lifecycle of a ReAct agent in a software environment:

1. Context & Scratchpad Injection: Interaction rules, descriptions of available tools, and the history of previous iterations of the current session (Scratchpad) are embedded into the system prompt.
2. Inference with Tool Delimiter: The LLM generates tokens for the Thought section. Once the model reaches the tool call, generation is paused by the client, and the call arguments are validated.
3. Execution & Observation Feedback: The orchestrator sends the command to the appropriate subsystem (local terminal, database, or browser), reads the output, limits its length for token economy, and adds the message Observation: ... to the context.
4. Loop Progression & Termination Check: If the agent has achieved its goal or the counter max_iterations = 10 is reached, the cycle is interrupted. Otherwise, the next iteration begins with a new block of Thought.

4. Production Engineering Scenarios

01. Interactive Diagnosis and Repair of Server Infrastructure

• Thought: The service returns a 502 error. First, I will check the Nginx logs for the last 5 minutes.
• Action: read_logs(service="nginx", lines=20)
• Observation: connect() failed (111: Connection refused) while connecting to upstream 127.0.0.1:3000
• Thought: The upstream on port 3000 has crashed. I need to check the status of the Node.js process via PM2.
• Action: execute_cmd(command="pm2 status")
• Observation: app-server: errored (out of memory)
• Thought: The service crashed due to lack of memory. I will restart it with a larger heap limit.

02. Iterative Search in Documentation and API

The agent attempts to call the external Stripe service. At the first step, it receives an invalid_api_key error. Through the Thought block, the agent recalls that a prefix sk_test_ is required for test mode, retrieves the correct environment variable, and successfully creates a payment intent on the second attempt.

03. Step-by-Step Debugging of Unit Tests

The code agent sees a test failure due to a mismatch in the expected value. It formulates a hypothesis, makes a minimal one-line change, reruns the test, sees a green result, and only then reports task completion.

5. Pitfalls, Common Mistakes & Security

• Self-Reinforcing Delusion: If the model makes a faulty conclusion at the first step, it tends to interpret all subsequent Observations in favor of its mistake. Solution: mandatory addition of a critique step (Reflection) after 3 consecutive failed actions.
• Context Bloat from Raw Observations: The command cat huge_file.json returns 50,000 tokens of garbage, pushing out the system prompt. Always limit the size of the returned Observation in runtime (e.g., no more than 2000 characters).
• Calling Non-Existent Tools (Action Hallucination): The model attempts to call a tool that is not on the list. Solution: use the native API Tool Calling instead of raw text parsing.