Reason-Plan-ReAct: A Reasoner-Planner Supervising a ReAct Executor for Complex Enterprise Tasks

AI summary

Overview

• Research area: Autonomous LLM agents for enterprise tool-use and multi-step reasoning; multi-agent architectures; context-window management for open-weight models.
• Technical level: Advanced.
• Scope: The paper introduces RP-ReAct (Reasoner Planner-ReAct), a two-role multi-agent architecture that splits high-level planning from low-level tool execution and adds a context-offloading strategy, evaluated on five domains of the ToolQA benchmark with six open-weight reasoning models.

What This Paper Is About

Enterprise agents must coordinate many tools and reason over documents and databases, but single-agent designs force planning and execution into one loop, which destabilises the agent's trajectory. That problem is worsened because data-privacy requirements push companies toward local open-weight models with smaller context windows, which are quickly consumed by large tool outputs. The paper's goal is to decouple strategic planning from execution so that an agent can stay on track, recover from errors, and run reliably on smaller models.

Key Contributions

1. A decoupled multi-agent architecture (RP-ReAct): a Reasoner Planner Agent (RPA) handles all high-level planning, re-planning and error diagnosis, while one or more Proxy-Execution Agents (PEA) translate abstract sub-steps into concrete tool calls using the ReAct (think, act, observe) loop. Tool failure complexity never enters the RPA's context.
2. A context-saving strategy: when a SQL or filtered CSV output exceeds a threshold T, only the first T tokens are injected into the PEA context and the full output is stored in a temporary variable for on-demand analysis via the Python tool.
3. A broad empirical evaluation: five ToolQA domains (Airbnb, Flight, Coffee, Scirex, Yelp) at both easy and hard difficulty, across six open-weight reasoning models.
4. A robustness and generalization analysis: accuracy, standard deviation, Saturation and Combined Performance Score (CPS) across model scales, plus a step-limit experiment (React-100) showing that more steps alone do not help a monolithic ReAct agent.

Main Findings

• Easy tasks favour ReAct: The paper reports that RP-ReAct's planning overhead can disrupt optimal trajectories on easy tasks through redundant actions (such as repeated database loading) or unnecessary verification and re-planning. On easy Airbnb with gpt-oss-120b, RP-ReAct reached 0.89 versus React's 0.73; on easy Yelp with gpt-oss-120b, React reached 0.90 versus RP-ReAct's 0.53; on easy Yelp with Qwen3-14B, React reached 0.71 versus RP-ReAct's 0.61.
• Hard tasks favour RP-ReAct: For hard tasks requiring many sequential steps and diverse tool interactions, the separation of planning from execution prevents trajectory loss. With gpt-oss-120b on hard SciREX, RP-ReAct scored 0.26 versus React's 0.14; on hard Coffee, 0.23 versus 0.11; on hard Airbnb, 0.38 versus 0.32. With gpt-oss-20b on hard Coffee, RP-ReAct reached 0.44 versus React's 0.13.
• Reflexion performs worst overall: The paper states Reflexion shows the worst performance in basically all tasks. For example, hard Yelp with gpt-oss-120b was 0.43 for Reflexion versus 0.63 for React, and easy Airbnb with Qwen3-32B was 0.28 for Reflexion versus 0.85 for React.
• Greater stability across models: RP-ReAct shows lower performance variability across models in the majority of easy and hard tasks. On easy Yelp, standard deviation was 0.18 for RP-ReAct versus 0.32 for React and 0.34 for Reflexion; on easy Airbnb, 0.16 versus 0.33 for React and 0.32 for Reflexion; on hard Yelp, 0.09 versus 0.26 for React.
• Best combined performance trade-off on hard tasks: The Combined Performance Score for RP-ReAct on hard benchmarks was 0.36 (Coffee), 0.33 (Airbnb), 0.32 (Yelp), 0.24 (SciREX) and 0.20 (Flight). ReAct had the higher CPS primarily on easy tasks guided by in-prompt examples, and on one example-guided hard task.
• More steps do not fix ReAct: Re-running the React agent with gpt-oss-20b at a 100-step limit (React-100) — matching RP-ReAct's worst-case of 10 RPA steps and 10 PEA steps per question, up to 100 steps — improved performance by an average of only 4.8 percent. In the remaining cases the agent followed a wrong trajectory, produced an incorrect answer, or hit the new 100-step limit again.
• Smaller models fail regardless of approach: Models under 10B parameters could not solve the tasks consistently. On hard benchmarks no result surpassed the 0.11 threshold. Results for SciREX and Flight were not reported for both easy and hard versions because performance approached 0. The paper attributes failure to premature response (the PEA answering directly instead of delegating) and trajectory deviation (wrong tool parameters or step order, such as filtering a database before loading it).
• Better sample efficiency for tools: Because tool-usage logic is abstracted away from task logic, the PEA needs only one dedicated abstract example per tool operation, whereas ReAct requires multiple complete task examples containing that action.
• Generalization without in-prompt examples: RP-ReAct generalizes better even when domain-specific examples are omitted from the prompt; the paper marks such examples with "P" in its tables.

Methodology in Plain English

The researchers split one hard job into two simpler jobs. The RPA takes the user's request and turns it into a sequence of small, plain-language sub-questions, each wrapped between <|begin_search_query|> and <|end_search_query|> tags. The PEA receives one sub-question at a time, figures out which tool to call, with which parameters and syntax, runs it using the ReAct think-act-observe cycle, and sends the result back inside <|begin_search_result|> and <|end_search_result|> tags. The RPA reads that result and either moves to the next sub-question or, if something failed, diagnoses the cause and plans a correction or a new route.

To stop large tool outputs from flooding the small context windows of open-weight models, the PEA uses a token threshold T = 100. If a SQL query or filtered CSV passes that limit, only the first T tokens enter the context as a preview and the full text is stored in a temporary variable; the PEA tells the RPA that the full output would consume too much context and must be analysed with the Python tool.

The evaluation used the ToolQA benchmark, a set of easy and hard multi-step question-answering tasks across eight domains that requires a toolkit of 13 functions including text retrieval, database queries, code interpretation and mathematical computation. The authors evaluated the easy and hard subsets of five domains: Airbnb, Flight, Coffee, Scirex and Yelp. Baselines were ReAct and Reflexion, using prompts adapted from the original ToolQA work; the RPA used the same prompt and example set across domains, while the PEA adapted its few-shot examples to the domain-specific tools it managed, with a single unified PEA configuration handling all tools.

Six open-weight reasoning models were tested: gpt-oss 20B and 120B, Qwen3 14B and 32B, and DeepSeek-R1-Distill-Qwen-7B and DeepSeek-R1-Distill-Llama-8B. Metrics were Accuracy, Standard Deviation, Saturation (1 minus the gap between maximum and average accuracy across models), and Combined Performance Score (Saturation multiplied by maximum accuracy). Experiments ran on Leonardo HPC with 4x NVIDIA A100 GPU 64GB, 128 GB RAM and a 32-core Intel Xeon Platinum 8358 CPU, with temperature 0.6 and TopP 1.0. The configuration was 1 RPA and 1 PEA. ReAct used 20 steps; Reflexion used 20 steps and at most 3 self-reflections; RP-ReAct used 10 steps.

Why This Matters

Impact on research: The work argues that trajectory instability and context overflow — not raw model capability — are the bottlenecks in complex agent tasks. It offers a measurable framework (accuracy, standard deviation, Saturation, CPS) for evaluating robustness across model scales rather than on a single large or closed model, which the authors note most prior agent work does not do.

Real-world applications:

• Enterprise assistants that coordinate multiple internal systems on behalf of employees, such as document and database querying.
• Locally hosted agents for privacy-sensitive organisations that cannot send data to proprietary APIs and must use open-weight models on constrained hardware.
• Analytical workflows over large tabular data, where the agent inspects samples and generates Python or SQL rather than loading full datasets.
• Multilingual or multi-tool support desks where sub-tasks can be delegated to specialised executor agents.

Industry relevance: The paper targets the enterprise constraint directly — data privacy forcing open-weight deployment, smaller context windows, and lower generalization than proprietary counterparts. Its context-offloading mechanism is presented as a practical safeguard for resource-constrained environments, and the authors conclude the architecture's stability across open-weight models suggests practical viability for the enterprise sector.

Future Directions

• Expand evaluation to other complex reasoning benchmarks, specifically OfficeBench and Mint, and test with an increased number of PEAs.
• Apply post-training optimisation (SFT or RL) specifically to the RPA and PEA to reduce redundant steps and wrong re-planning actions; the reported results reflect the baseline capability without such optimisation.
• Quantify the context management more thoroughly, including the effect of different T thresholds or integrating a token summarization mechanism, since the current analysis is described as a preliminary view of token savings.
• Explore agent-specific temperature tuning, such as lowering the RPA's temperature to 0.0 to prioritise deterministic outputs over creativity, rather than the static 0.6 used here.

Target Audience

Researchers and engineers working on LLM agent architectures, tool-use and multi-step reasoning; enterprise AI teams that must deploy open-weight models on limited hardware for privacy reasons; and practitioners evaluating agent reliability across model scales. Readers should be comfortable with ReAct-style agent loops, benchmark evaluation and metrics such as standard deviation and combined performance scores. Code is available at https://github.com/giargiapower/RP-ReAct.

Note: the paper's acknowledgments credit ISCRA for access to the LEONARDO supercomputer, owned by the EuroHPC Joint Undertaking and hosted by CINECA (Italy), and state that Fabio Ciravegna was partially funded by the ICOS project under European Union HORIZON grant agreement No 101070177.

Authors’ abstract

Despite recent advances, autonomous agents often struggle to solve complex tasks in enterprise domains that require coordinating multiple tools and processing diverse data sources. This struggle is driven by two main limitations. First, single-agent architectures enforce a monolithic plan-execute loop, which directly causes trajectory instability. Second, the requirement to use local open-weight models for data privacy introduces smaller context windows leading to the rapid consumption of context from large tool outputs. To solve this problem we introduce RP-ReAct (Reasoner Planner-ReAct), a novel multi-agent approach that fundamentally decouples strategic planning from low-level execution to achieve superior reliability and efficiency. RP-ReAct consists of a Reasoner Planner Agent (RPA), responsible for planning each sub-step, continuously analysing the execution results using the strong reasoning capabilities of a Large Reasoning Model, and one or multiple Proxy-Execution Agent (PEA) that translates sub-steps into concrete tool interactions using a ReAct approach. Crucially, we incorporate a context-saving strategy within the PEA to mitigate context window overflow by managing large tool outputs via external storage and on-demand access. We evaluate RP-ReAct, on the challenging, multi-domain ToolQA benchmark using a diverse set of six open-weight reasoning models. Our empirical results show that RP-ReAct achieves superior performance and improved generalization ability over state-of-the-art baselines when addressing diverse complex tasks across the evaluated domains. Furthermore we establish the enhanced robustness and stability of our approach across different model scales, paving the way for effective and deployable agentic solutions for enterprises.