ReAct Framework Prompt Builder

ReAct framework prompt builder

ReAct — short for Reasoning and Acting — is the dominant pattern for tool-using LLM agents. Rather than answering in one shot, the model alternates between thinking out loud and calling tools, grounding each step in real results. This builder assembles the system prompt that defines that loop: the turn format, the tools the agent may call, an iteration ceiling, and the signal that ends the loop with a final answer.

How it works

The generated prompt declares a strict turn structure: Thought (private reasoning), Action (a tool call written as tool_name[input]), and Observation (the result you feed back). The model repeats this cycle until it has enough to respond, at which point it emits Final Answer: in the format you chose. Your tool list is rendered as a name-and-description block so the model knows exactly what is callable and what each returns. The max iterations value is stated explicitly so the model knows to converge or report that it could not finish.

What a generated ReAct prompt looks like

For a research agent with two tools and a maximum of six iterations, the builder produces a structure along these lines:

You are an agent that reasons step by step before taking actions.

Available tools:
- search[query]: Search the web and return the top 5 snippets.
- calculator[expression]: Evaluate a mathematical expression and return the result.

Format:
Thought: [your reasoning about what to do next]
Action: tool_name[input]
Observation: [the tool result, which you will receive]
... repeat up to 6 times ...
Final Answer: [your complete answer in plain text]

Task: {user_task}

Your runtime parses each Action, calls the real tool, and injects the result as the next Observation before sending the whole conversation back to the model.

Why the iteration cap is essential

Without an upper limit, an agent stuck on an unsolvable sub-task or caught in a reasoning loop will continue calling tools indefinitely, accumulating tokens and cost. The cap forces the model to either reach a conclusion within the budget or emit a Final Answer that honestly states it could not finish — both better outcomes than an infinite loop. A cap of 5 to 8 iterations is typical for focused tasks; complex multi-step research might use 10 to 15.

Tips for writing effective tool descriptions

• Describe what the tool returns, not just what it takes. "search[query] → returns up to 5 web snippets as plain text" is more useful than "searches the web" because the model uses the return description to plan its next Thought.
• Be specific about failure modes. If a tool can return an empty result or an error string, say so. Models reason better around known failure cases than surprises.
• Keep the tool set small and non-overlapping. Three or four well-scoped tools outperform a dozen overlapping ones; the model picks more reliably from a short menu with clear boundaries.

Matching the prompt to your runtime

The prompt this builder produces is a scaffold, not a plug-and-play solution. Your code must:

1. Detect when the model has emitted an Action line and extract the tool name and input.
2. Execute the real tool and capture its output.
3. Append the Observation to the conversation and send the next turn.
4. Detect Final Answer: to know when to stop the loop.
5. Enforce the iteration cap by cutting off the loop if it has not terminated by step N.

A fixed Final Answer: prefix makes step 4 a trivial string match and the response easy to extract programmatically.