What Is ReAct Prompting?

What Is ReAct Prompting?

ReAct prompting is a prompt pattern that makes an LLM alternate between reasoning, acting through a tool or API, and reading the observation before choosing the next step. It is a prompt-engineering and agent-design technique used in production traces where one user request expands into multiple tool calls. FutureAGI treats ReAct as an evaluable trajectory: each step can be checked for tool-selection accuracy, grounded observations, reasoning quality, cost, and task completion.

Why It Matters in Production LLM and Agent Systems

ReAct failures rarely look like one bad model answer. They look like a correct-sounding answer produced after the agent queried the wrong API, ignored a tool timeout, reused a stale observation, or kept looping through low-value searches. If ignored, ReAct prompting can turn a small prompt bug into cascading failure: wrong tool selection contaminates reasoning, a bad observation creates hallucination, then the final response appears confident because the model’s intermediate reasoning is hidden from the end user.

Developers feel it when agent traces are hard to debug. SREs see p99 latency and token cost spike when agents take eight steps for a two-step task. Product teams see completion rate drop on edge cases such as ambiguous account lookup or multi-document retrieval. Compliance teams worry because a tool call can fetch sensitive context the final answer does not expose.

The symptoms are concrete: repeated identical tool calls, rising agent.trajectory.step counts, observation strings that contradict the final answer, high tool error rate, and task completion falling only for one prompt version. This matters more in 2026 multi-step pipelines than in single-turn chat because the prompt now controls control flow. Unlike plain chain-of-thought, ReAct does not just ask the model to explain reasoning; it gives the model a loop that can change external state.

How FutureAGI Handles ReAct Prompting

FutureAGI’s approach is to evaluate the trajectory first, then use the agent-opt optimizer surface to edit the prompt against the failing steps. A support agent might use a ReAct prompt to decide whether to call lookup_order, search_policy, or create_refund_case. With the langchain traceAI integration, FutureAGI records each planner span, tool call, and observation with fields such as agent.trajectory.step, tool.name, tool.status_code, and llm.token_count.prompt.

The engineer then runs an eval cohort across the traces. ToolSelectionAccuracy catches cases where the model searched policy before looking up the order. ReasoningQuality and StepEfficiency flag trajectories that explain the right goal but waste steps. TaskCompletion checks whether the refund workflow actually finishes. When failures cluster around one prompt version, the engineer sends those rows to ProTeGi for textual-gradient prompt edits. For competing goals, GEPAOptimizer can search prompt variants across quality, step count, and prompt-token cost, while PromptWizardOptimizer is useful when the ReAct planner and final-answer prompt both need coordinated edits.

The next action is operational: commit the winning prompt through fi.prompt.Prompt, run a regression eval, and alert when ToolSelectionAccuracy drops below 0.90 or p95 trajectory length exceeds five steps. Unlike a manual LangChain prompt tweak, the candidate is tied to the same trace cohort and can be rolled back.

How to Measure or Detect ReAct Prompting

Use a trajectory eval set, not just final answers. Good signals include:

• Tool-selection accuracy: ToolSelectionAccuracy evaluates whether the selected tool matches the expected tool for each step.
• Reasoning quality: ReasoningQuality evaluates the quality of agent reasoning through the full trajectory, not only the final message.
• Step efficiency: StepEfficiency flags unnecessary calls, repeated calls, and loops that raise latency without improving completion.
• Trace fields: watch agent.trajectory.step, tool.name, tool.status_code, and llm.token_count.prompt by prompt version.
• Dashboard and feedback proxies: monitor eval-fail-rate-by-cohort, p95 step count, token-cost-per-trace, thumbs-down rate, and escalation rate.

A minimal check can look like this:

from fi.evals import ToolSelectionAccuracy

tool_eval = ToolSelectionAccuracy()
result = tool_eval.evaluate(
    expected_tool="lookup_order",
    selected_tool="search_policy",
)
print(result)

Common Mistakes

ReAct has a simple text shape, so teams often under-specify it. The expensive mistakes are about control flow, not wording:

• Exposing hidden reasoning verbatim to users. Log trajectories for evaluation; keep the user-facing answer separate.
• Scoring only the final answer. Wrong tools and stale observations often pollute the trajectory before the response looks incorrect.
• Giving tools vague names. Ambiguous tool docs make ToolSelectionAccuracy look like a model issue when the interface is the issue.
• Leaving the loop unbounded. Set step limits, timeout handling, and fallback responses before a ReAct prompt ships.
• Optimizing only successful traces. ProTeGi and GEPAOptimizer need failed trajectories, edge cases, and cost objectives to improve behavior.