ReAct Framework Agents Think and Act

A model that only reasons guesses from memory, and a model that only acts flails with tools. ReAct framework agents alternate a written Thought, one tool Action, and a harness-written Observation until the answer is grounded.

A Paris coat question runs two passes with one search: an Observation of 12 degrees and raining turns into a coat plus a layer, three degrees under the line.

Why Does This Exist?

A bare model must answer even when its training ended years ago. Ask about today in Paris and it reaches into memory, finds something shaped like weather, and says it with a straight face. Fluent, specific, and unchecked. Handing the same model tools without discipline fails the other way: it fires searches, skims nothing, and stitches scraps into an answer. Acting without thinking is guessing with extra steps, and the extra steps cost tokens.

The ReAct framework is the middle that holds. The model writes a Thought, takes one Action through a tool, reads the Observation back, and only then thinks again. That cycle repeats until the evidence answers the question. A live fact gets a checked answer instead of a memorized one.

This page covers the agentic-ai loop: the three lines, who writes each one, and where it stops. The prompting-focused sibling is the ReAct pattern. The harness that bounds the loop is covered with planning in agents, the memory the loop reads lives in memory systems in agents, and the parallel version lives in multi-agent orchestration.

Basics first: a tool is a function the model may name with arguments. The model never runs code. Your code runs the function and pastes the result back as the Observation. If that split is new, hold it tightly, because the whole safety story rests on it.

Think of It Like This

A detective who alternates theory and legwork

A detective will not solve a case from the office armchair. Pure theory invents a killer with no evidence. Pure legwork searches rooms at random and interviews everyone twice. Both waste the week.

The good detective alternates. A theory names the next check: the suspect left a trace at the warehouse. Legwork tests it: drive over, search the floor. The result updates the theory: muddy size-ten prints, so check nearby sites with fresh mud. Theory, legwork, result, repeat until the evidence closes the case.

Where it stops: footprints never lie about being there, and the lab returns what it measured. Model tools are less honest. A search can return junk, a call can use the wrong argument, and the model can misread both. The loop only helps if outside code checks each call and writes each result down faithfully.

How It Actually Works

Call $S_t$ everything the model sees at step $t$ : the question plus every Thought, Action, and Observation kept so far. Call $T_t$ the Thought: the model's plan in words. Call $A_t$ the Action: one tool name plus its input. Call $O_t$ the Observation: the tool result as text. Call $N$ the step cap: the harness hard limit on passes.

Each pass does the same small job. The harness hands $S_t$ to the model and reads back $T_t$ plus either $A_t$ or a final answer. When an action arrives, only the harness runs the tool, turns the result into $O_t$ , and builds $S_{t+1}$ by appending $T_t$ , $A_t$ , and $O_t$ to $S_t$ . When a final answer arrives, the harness stops. When passes run out against $N$ , the harness ends the run with a fixed message instead of asking the model whether it feels done. The model writes. The harness acts. That split is the whole safety story.

Who writes which line

Two lines belong to the model and one never does. $T_t$ and $A_t$ come from the model, so they can be vague, wrong, or badly formatted. $O_t$ comes from the tool through the harness, so it is the only grounded line. That gives the strictest rule in the framework: stop the model's text at the word Observation and let the harness append the real $O_t$ . A model allowed to write its own Observations invents tool results in the tool's voice, and nothing downstream can tell.

Worked example: a coat in Paris

Question: do I need a coat in Paris today. Fix a checkable rule: rain means a coat, and anything below 15 degrees means a layer. Here $15 - 12 = 3$ , so 12 sits 3 degrees under the layer line.

Pass 1 starts with $S_1$ holding the question. The model writes $T_1$ : need live weather, not memory. It writes $A_1$ : a search with the input Paris weather. The harness runs the search and appends $O_1$ : 12 degrees, raining. Count it: one Thought, one Action, one Observation.

Pass 2 starts with $S_2$ holding all four lines. The model writes $T_2$ : rain, so coat, and 12 is 3 below 15, so add a layer. No new tool is needed, so it writes the final answer: coat plus a layer, since it is 12 degrees and raining. Call $T$ the total pass count. Here $T = 2$ passes with 1 tool call and 4 transcript lines, the same run the diagram draws.

Every pass costs latency, tokens, and one more chance to wander, and you pay it for grounding: each claim traces to an $O_t$ the harness wrote. A single lookup with no follow-up wants a plain tool call, not the loop. The loop assumes tools answer quickly with short parseable text, and it fails when they dump pages of markup or act in the world before failing.

Code

This snippet counts the lines of the Paris run and checks the 3-degree gap. No API calls, no keys. Run it as is:

1transcript: list[str] = [2    "Thought: I need Paris weather.",3    "Action: search('Paris weather')",4    "Observation: 12 degrees, raining.",5    "Thought: Rain means coat; 12 is 3 below 15, so add a layer.",6]7
8print(sum(1 for line in transcript if line.startswith("Action:")))  # -> 19print(len(transcript))  # -> 410print(15 - 12)  # -> 3

Four lines, one action, and the 3-degree gap the second Thought cites. Count your own runs the same way: lines appended per pass, actions executed, and every number in the answer recomputed outside the model.

Watch Out For

Letting the model write its own Observation

The symptom is a final answer quoting a temperature no tool ever returned, with a transcript showing an Observation written in the model's own generation beside its Thought. The cause is a missing stop: without one the model keeps writing past the Action line and roleplays the tool.

Fix it by stopping generation at the word Observation and appending the tool text server-side. Log who wrote each line so the audit is trivial. Never accept an Observation the harness did not write.

Parsing free text with a hopeful pattern

The symptom is the model writing Action search Paris in a new shape each pass while your pattern finds nothing, burning passes on apologies until the step cap or the context limit. You learn about it from the bill.

Fix it by constraining the output shape with a strict schema or function calling, validating every call before executing, truncating tool outputs, and capping passes with a small $N$ . The production gates live with planning in agents.

The Quick Version

ReAct framework agents loop Thought, Action, and Observation: the model plans in words, names one tool call, and reads the tool result before thinking again.
The model never runs code and never writes Observations. The harness runs each tool, appends each result, and ends stuck runs at a step cap.
Each Thought sees the full transcript, so a failed search becomes a revised plan instead of a hallucinated answer.
The Paris run takes 2 passes and 1 tool call: a search returns 12 degrees and raining, and 3 degrees under a 15-degree line means a coat plus a layer.
A single lookup with no follow-up wants a plain tool call, not the loop, since later steps must need earlier results to earn their cost.