The ReAct Loop by Hand

What you will be able to do

• ✓Explain the ReAct pattern - Thought, Action, Observation, Final Answer
• ✓Build a tool registry and a system prompt that teaches the format
• ✓Write the loop that asks the model, runs the requested tool, and feeds the result back
• ✓Explain why the model must never write its own Observation - and stop it with a stop sequence
• ✓Explain what max_steps protects against
• ✓Say why eval() is unsafe, and replace it with a calculator that only does arithmetic

The idea, in plain English

ReAct is short for Reason and Act. The model writes down what it is thinking (Thought) and picks a tool (Action). Your code runs that tool and hands back the result (Observation). Round it goes until the model has what it needs and writes a Final Answer.

This is the heart of the module. Everything before it was preparation - talking to a model, getting structured output, asking for a tool - and everything after adds real tools, memory, planning, and error handling on top. Read the loop closely: the model is never in control of the program. Your for loop is. It calls the model, looks at the text, runs a tool if one was asked for, and appends the result to the conversation.

Two details carry most of the weight. The model must not write its own Observations - otherwise it will happily invent a weather report instead of waiting for yours. And max_steps caps the rounds, so a model that never reaches a Final Answer cannot loop forever.

The loop below was run many times against a local model, and the transcripts shown are real. They show it working - and failing in instructive ways a small model will, which is exactly what the rest of this module fixes.

Worked example: Build a two-tool ReAct loop from scratch.

The four labels

Thought is the model reasoning about what to do next. Action is the tool it wants, with its argument. Observation is the result - written by your code, never by the model. Final Answer is the model saying it is done.

The labels matter because your code reads them. Final Answer: tells the loop to stop; Action: tells it which function to run. Everything else is for you, reading the transcript.

The loop, one pass at a time

Each pass does the same five things. Ask the model with the whole conversation so far. Append its reply as an assistant message. If there is an Action, run the tool through the TOOLS dictionary and append the result as "Observation: ...". If there is a Final Answer, return it. If there is neither, the agent is stuck.

The Observation goes back as a user message. The model has no other way to receive information - the conversation is its only input - which is why every result has to be written into it.

Never let the model write the Observation

Asked to use this format, a model will often write the whole exchange itself: Thought, Action, and then an Observation it made up. We checked the very first reply six times: five of them contained an Observation the model had written itself, before any tool had run.

The prompt asks it not to, and that is not enough. The reliable fix is a stop sequence: options={"stop": ["Observation:"]} tells Ollama to end generation the moment the model starts to write "Observation:". With it, none of six first replies contained one.

There is a second half to the same rule. If a reply contains both an Action and a Final Answer, the original loop checks for Final Answer first - and returns an answer built on a result that never existed, with no tool run at all. Checking for an Action first closes that gap: if the model asked for a tool, the tool runs before anything else.

Watch out: An Observation is only real if your code wrote it. Anything the model writes after "Observation:" is fiction, however plausible.

What the loop cannot fix

The loop is correct; the model is still a small model. Across our runs it sometimes wrote two Actions in one reply (the regex takes the first, and the second is never run), wrote "Action: (no action needed, just a thought)", or answered the maths half from memory instead of calling the calculator.

We ran the umbrella question eight times with the original loop and eight with both fixes. Original: both tools ran 4 times, 3 runs got stuck, 1 answered without the calculator. With the fixes: 5, 1, and 2. The fixes guarantee there are no invented Observations; they do not make an 8-billion-parameter model reliable. Lesson 1.10 handles the stuck cases by feeding the problem back to the model instead of giving up.

max_steps: the safety limit

A model that never writes Final Answer would keep the loop going forever - calling tools, costing time, possibly repeating the same Action. for step in range(max_steps) makes that impossible: after five passes the function returns "Max steps reached without a final answer".

Pick the limit from the task. Two tools and a two-part question need three passes; five leaves room for one detour. A limit is also a signal - if runs regularly hit it, the prompt or the tools need work.

The regex is deliberately simple

r"Action:\s*(\w+)\((.*?)\)" finds a tool name and everything up to the first closing bracket. That covers get_weather(Mumbai) and calculate(12 * 8), and breaks on two things worth knowing.

Nested brackets: calculate(12 * (3 + 4)) stops at the first ")" and passes "12 * (3 + 4" - an error. Keyword arguments: get_weather(city="Mumbai") passes city="Mumbai, and the weather lookup returns "unknown city". Lesson 1.5 taught the keyword form, so match what your prompt asks for - or, as Module 2 does, let structured tool calls replace the regex entirely.

Step-by-step code

Watch out: calculate() uses eval(), which runs whatever string it is given as Python - calculate('__import__("os").getcwd()') returns your real working directory. Fine on your own machine with your own questions; dangerous anywhere a stranger can reach it. safe_calculate above accepts arithmetic and nothing else.

Tip: The print(text) inside the loop is not decoration. Reading the Thoughts go by is how you find out why an agent went the wrong way.

The loop at a glance

TOOLS = {"get_weather": get_weather, "calculate": calculate}

Thought / Action / Observation / Final Answer

re.search(r'Action:\s*(\w+)\((.*?)\)', text)

{"role": "user", "content": f"Observation: {observation}"}

options={"stop": ["Observation:"]}

for step in range(max_steps):

Try it yourself

The code does not change. Swap the content string and the program does something else entirely.

What usually goes wrong

✗ ollama.chat(model="llama3.1", messages=messages)

✓ ollama.chat(model="llama3.1", messages=messages,
            options={"stop": ["Observation:"]})

✗ if "Final Answer:" in text:
    return ...
match = re.search(...)

✓ match = re.search(...)
if match:
    ...run the tool...
    continue
if "Final Answer:" in text:
    return ...

✗ text = response["message"]["content"]
# straight on to the regex

✓ messages.append({"role": "assistant", "content": text})

✗ while True:

✓ for step in range(max_steps):

✗ return str(eval(expression))

✓ return safe_calculate(expression)

Quick check before you move on

1. 1.

   What do the four labels Thought, Action, Observation and Final Answer each represent?

   Show answer
2. 2.

   Why does the loop stop once "Final Answer:" appears?

   Show answer
3. 3.

   What is max_steps protecting against?

   Show answer
4. 4.

   What does options={"stop": ["Observation:"]} do?

   Show answer
5. 5.

   The model writes Action: calculate(12 * (3 + 4)). What does the regex pass to calculate?

   Show answer

Interview questions